Hei,
Denne henvendelsen har ikke noe direkte med NAV ? gj?re, men jeg tror ikke den er helt uttafor heller...
Saken:
Vi ?nsker ? f? bedre kontroll p? personer som kopler opp b?rbart utstyr via tr?dfaste punkter, der det m?tte passe, i nettet v?rt.
Slik det er n? s? gj?r folk f?lgende:
- Kopler seg p? nettet via tilgjengelige aktiviserte (av IT) RJ45 punkter. De f?r ip adresse fra DHCP og that's it.
- Napper ut allerede oppkoplede PC'er og surfer ivei.
De siste m?neders orme-trojan-virus b?lger har f?tt oss til ? tenke bittelittegranne mer restriktivt...
..Og da dukker VMPS opp...
Sp?rsm?l:
- Er det noen som gj?r noe glupt i denne sammenheng, som ikke n?dvendigvis har med VMPS ? gj?re?
Se for?vrig disse linkene:
http://www.uwm.edu/~jeff/doc/vmps/
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration...
mvh chr
On Fri, 24 Oct 2003, Christian Ramstad wrote:
Sp?rsm?l:
- Er det noen som gj?r noe glupt i denne sammenheng, som ikke
n?dvendigvis har med VMPS ? gj?re?
Vi gj?r ikke VMPS, har h?rt om det men aldri vurdert det skikkelig. Det vil vel kreve Cisco over hele linja? Og en svakhet er muligens forfalskning av mac-adresser? Ellers en noks? snerten sak.
Uansett, det sp?rs hva du ?nsker ? oppn?. V?r tiln?rming er:
* Vi ?nsker av hensyn til abuse-arbeid ? kunne vite hvem som st?r bak en gitt ip-adresse til en gitt tid. NAV gir oss maskinsporing, men det hjelper oss ikke i "open jack" tilfeller, alts? i fellesareal der b?rbare kommer og g?r. Det hjelper oss heller ikke tr?dl?st.
* Vi bruker VPN/radius som autentifisering over tr?dl?st, men dette har en del ulemper. Vi ser p? web/ssl-basert autentifisering (authentication proxy). Brukeren m? alts? opp med en web-browser og skrive inn bruker/pwd f?r han kommer videre.
I forhold til welchia og andre onde ormer s? har vi laget et automatisk sperrekonsept som bruker snmp write og sperrer svitsjeporter i nettet. ?rsaken til sperren kan v?re ulike kilder, men vi ser bl.a. p? netflow data og sperrer de som har et unaturlig volum med destinasjonsadresser mot port 135. Sperreprogrammet bruker NAV sin maskinsporing og sperrer svitsjeporten. Videre tilbyr vi lokale IT-ansvarlige via NAV begrenset ? selv aktivisere en slik sperret maskin (de skal f?rst rydde opp, om de ikke gj?r det vil vi uansett sperre igjen automagisk).
Dette har v?rt en suksess, men har ogs? en del problemer, og da er vi tilbake til "open jack" tilfeller. N?r en infisert laptop kommer innom s? sperrer vi denne p? svitsjeporten. Vedkommende merker det og flytter seg til et nytt punkt. Vi sperrer da dette punktet... For ? b?te p? dette s?rger vi for ? ?pne stien etter en slik vandrende infisert maskin. Uansett, vi sperrer til syvende og sist et punkt som noen andre uskyldige ?nsker ? bruke senere...
En sperre basert p? mac-adresse hadde da v?rt ? foretrekke. Dette kan vel l?ses p? ulikt vis. Det er mulig ? ha en unntaksliste i dhcp-serveren og nekte ip-adresse. Jeg vet HiVe sperrer basert p? mac-sperre i en sentral cat5500 hos dem (set cam static filter). Man kan vel ogs? lage statisk arp-entry p? ruter og sette ip til noe ubrukelig/noe som sperres (har ikke testet)?
Videre m? man fors?ke ? kommunisere ut sperren til brukeren p? et eller annet vis. Det er jo fint om brukeren f?r et hint om hvorfor ting ikke virker. Der mener jeg vi n? har fikset noe windows popup greier, John Magne kan svare bedre.
S? ja - vi jobber med problemstillingen, men har ikke l?st alle aspekter.
mvh - Vidar