Steen Suder <sfs_news_spam@suder.dk> wrote:
>Jeg sidder og roder med scripts til kontrol af en stak HP switche.
>
>De kan umiddelbart kun snakke SNMP v. <= 2c. Skal man virkeligt op i
>SNMP v. 3, før man kan få en smule sikkerhed i form af krypteret
>brugernavn, password etc.?
Ja. Men der er et par tricks man kan gøre.
- Sørge for at styre adgang til SNMP fra trusted hosts
- Isolering af management-adresser på vlan, loop-backs
- Sørge for at filtrere SNMP mod management-adresser med ACL/VACL
- Forhindre spoofing
De første punkter handler om at styre hvem der må sende SNMP til
enhederne ved filtre på boksene og/eller på router-interfaces, VLAN
access-lists eller hvad man nu kan finde på af sjove ting.
Det sidste handler om at SNMP dybest set er let at spoofe. Så når du
kontrollerer adgangen på IP-adresser er du også nødt til at sikre at
du kan have tillid til dem.
Og så er vi ude i "sjove" ting som Unicast Reverse Path Forwarding,
DHCP snooping, Dynamic ARP inspection, IP Source Guard - eller hvad nu
andre producenter end Cisco kalder dem ..
>Som jeg ser det, er den eneste mulighed med v. 2c at man sætter
>communityname til et non-standardnavn... men det tager jo kun et par ms
>at sniffe dét.
>
>VLAN er ikke muligt i det pågældende setup.
>
>Skal jeg bare "nøjes" med v. 2c?
Man bør overveje ret seriøst om det er klogt at enable SNMP
WRITE/CREATE på boksene, hvis ikke man kan kontrollere adgangen. Men
det er naturligvis op til en konkret risikovurdering. Hvilken skade
kan en angriber gøre med en SNMP kommando kontra de administrative
fordele man opnår med SNMP.
Hvis det er noget med automatiseringer så kan man også nå et stykke
vej med f.eks. telnet-scripts. F.eks. perl med net::telnet eller
expect hvis det skal være rigtig fint.
Og hvis det er noget med alarmer, så kan boksen godt sende SNMP traps
uden at have SNMP W/C enabled.
--
Lars Kim Lund
http://www.net-faq.dk/