SNMP v3 public netre

Fórumok

Eddig ahol SNMP volt ott 1 vagy 2 volt, belső mgmt hálón, úgyhogy igazából "mindegy". Most viszont lenne igény kintről monitorozni eszközt.

Van az SNMP 3 annyira biztonságos, hogy rendes auth és private pass-szal ki lehet rakni direktben netre? (Konkrétan: Mikrotik router)

Hozzászólások

v3 már elvileg DTLS, mindenféle security fittyfenével, így elviekben alkalmas arra, hogy neten lógjon. Ezen felül pedig jön a megérzés része, nekem pl. elsőre az ugrott be, hogy csak széttűzfalazva, adott IP-ről engedélyezve kizárólag.

Ez utóbbit persze lehet, hogy csupán a rossz tapasztalatok mondatják velem (snmp walk-ba belefagyó eszközök sora).

Illetve az implementációs részről se feledkezzünk meg: bejáratott dolog az snmp, de benned is felmerült azonnal a kérdés, hogy valóban jó ötlet netre kirakni? Mennyire kitesztelt dolog a vad neten figyelő snmp szerver? :)

Szóval hivatalosan: elvileg erre van az SNMPv3, megérzés alapján pedig kizárólag tűzfalazva :D

// Happy debugging, suckers
#define true (rand() > 10)

Szerkesztve: 2024. 09. 25., sze – 17:46

A wikijuk alapjan nem tud transport mode-ot, szoval a DTLS nem jatszik, marad az USM. A meglevo algoritmusok nem szamitanak biztonsagosnak hosszu (tobb eves) tavon, de azert a brute-force toreshez massziv szamitasi kapacitas kell. VPN tunnel nem jatszik?

Szerkesztve: 2024. 09. 25., sze – 17:52

Authentikációval, SHA-256 -al szerintem teljesen oké, még akár tűzfal nélkül is - de ha van az még jobb, így random portscan sem fogja piszkálni.

Használok ilyet publikus neten keresztül (szintén ip szűréssel), read-only monitorozásra, még soha nem volt gond vele.

Mindenképp filterezve lesz hogy egyáltalán honnan elérhető... Azonban ahogy néztem úgy tűnt, hogy ha az auth password nem jó, akkor nem is válaszol neked semmit, ergo sima timeout-ot kapsz, mintha nem is lenne ott semmi. Szóval így úgy tűnik brute-force és UDP flood ellen is rendben van.

"Sose a gép a hülye."

Nem feltétlenül. Sajnos Wireguard-dal is ugyanez a helyzet, elvileg nem válaszol UDP-n, ha nem jó az autentikáció. Ettől függetlenül portscannel rá lehet jönni, hogy ott figyel a porton. (Értelemszerűen arról az esetről beszélek, ha nincs source IP-re _is_ szűrve.)

Ha ugyanis nem magán a routeren/tűzfalon fut, hanem egy mögötte levő gépen (akár dockerben vagy VM-en a DMZ gépen) akkor 1-el több hop kell a backend eléréséhez a router mögött. Vagyis TTL-korlátozós scanneléssel el lehet dönteni, hogy nyitva van-e a portja a tűzfalon, vagy nincs. Ha nem egyforma a külső és belső háló MTU-ja, akkor asszem DF bitekkel is lehet hasonló trükkös portscannelést csinálni és biztos van még pár másik módszer, amiről nem tudok. Ha nem standard porton van, akkor valószínűleg az nem fog kiderülni, hogy mi van ott, de ettől még elkezdhetnek random próbálkozni rajta. Nyilván lehet a tűzfalon játszogatni a különféle outbound ICMP response tiltásokkal, de elég macerás, hogy akaratlanul ne ronts el vele valami lényeges funkciót (pl path mtu discovery-t).

Régóta vágyok én, az androidok mezonkincsére már!