Hálózat védelem biztonság www.andrews.hu Zámbó Marcell <zambo.marcell@andrews.hu> Andrews IT Engineering Kft.
Protokollok...
Helyes szemlélet... paranoia v. egészséges félelemérzet: ki vállhat támadás áldozatává (miért pont én...) mit veszíthetünk a támadással (befektetett munka, presztizsünk, stb) fail open vs fail safe megközelítés csak a szükséges szolgáltatások fussanak, csak a szükséges helyekről legyen elérhető minden rendszerelem maximalisan annyi erőforrással(joggal) rendelkezik szegmentálás feladatkörök szerint
Veszélyforrások, támadások okai, támadási potenciál felkészületlen hobby támadó (script kiddie) netről letölt valamit, kipróbálja, nincs tisztába vele felkészült, de nem rosszindulatú támadó szakmai kíváncsiság, nem a kár okozás a cél felkészült és rosszindulatú támadó károkozás, haszonszerzés, világuralom :) worm/virus/spam konkurencia, ipari kémkedés a jó, a rossz és a csúf katonai/kormányzati támadások szinte mindenre képesek...
Támadási formák hagyományos megoldások (social engineering) erőmegoldások (brute force) szoftverhibát kihasználó támadások (exploit) túlterheléses támadások DoS (Deny of Service) pl: MikrotikOS =< 3.2 SNMP bug -> DoS DDos (Distributed Deny of Service) hálózati támadások (további slide-ok)
Hálózati biztonsági problémák hallgatózás (sniffing V snooping) aktív szolgáltatások keresése (portscan) ethernet címek hamisítása (arp spoofing) IP címek hamisítása (IP spoofing) hálózati névhamisítás (DNS spoofing) vak támadás (blind spoofing) kapcsolat lopás (session hijacking) fragment attack hibás összeszerelés, szűrés megkerülése
Letapogatás...
Hallgatózás
ARP hamisítás
IP hamisítás
Vak támadás
Kapcsolat eltérítés
Védelmi stratégia, katasztrófa terv Mi ellen akarunk/nem akarunk védekezni többe kerül a védekezés, mint az okozható kár Előre gondolkodni, (jogi) következmények katasztrófa terv (kipróbálva a gyakorlatban) cselekvési terv elérhetőségek tartakékok (helyszin, vas...) szerződésbe foglalni az informatikai vismajor fogalmát (mikor, mennyi időre függeszthető fel v. korlátozható a szolgáltatás v. az egyes előfizető...)
Védekezés formái helyes beállítás, használt rendszer ismerete karbantartás, felügyelet (mentés, ellenőrzés) naplózás (biztonságos log gyűjtés/elemzés) VLAN, switch-elt hálózatok miért nem biztonsági eszközök? erős azonosítás, titkosítás+hitelesítés = VPN IDS/IPS, biztonsági scanner-ek hálózati szegmentáció, tűzfalak
Tűzfal generációk I. csomagszűrő (packet filter) előnye: olcsó, gyors hátránya: protokollról nem tud semmit, megtéveszthető, sok szabály szükséges állapottartó csomagszűrő (stateful pf.) előnye: olcsó, gyors, ismeri a protokollt, részlegesen protokoll szinten is be tud avatkozni hátránya: nagy állapottér, megtéveszthető (pl semmi garancia nincs arra, hogy a tcp/80 az http protokoll lesz ) ilyen a MikrotikOS (aka Linux) is
Tűzfal generációk II. protokoll szűrő (application level firewall) előnye: finoman hangolható, skálázható hátránya: nem gyors, minden gw-ben implementálni kell bizonyos funkciókat, rugalmatlan, az állapottér nem szinkronizálható HA tagok között moduláris protokoll szűrő (modular application level firewall) előnye: mély elemzés, rugalmas, skálázható hátránya: az állapottér nem szinkronizálható HA tagok között
Hálózati szegmentáció tűzfallal
Határvédelmi terv - Security policy A terv leírja a rendszer helyes működését Részei: lábak tulajdonságai kiemelt hálózatok, rendszerek engedélyezett hálózati forgalom protokollszűrési elvárások különleges elvárások
Forgalmi táblázat
Ideális csomagszűrő felépítése input,forward,output minden output valahol input volt... spoof protection netmask-ra figyelni kell állapottartó képességek, stateful naplózás, zajszűrés mi az amit szűrni/engedni kell (és miért) ICMP szűrése: echo-(request reply) time-exceeded destination-unreachable source-quench terelés hálózatok szerint, fastruktúra (from-to) gyakrabban szereplő szabályokat előre
Spoof protection lokális forgalmak engedélyezése [in out]-interface=local (IP ellenőrzéssel) mindenki csak a saját hálózatából jöhet in-interface=landev src-address-list=!lannet action=drop in-interface=inet src-address-list=lannet action=drop in-interface=!local src-address-list=locals... fenntartott címtartományok szűrése inet felől
Állapottartó képesség connection-state= established related invalid helye a szabályrendszerben: rögtön a spoof és egyéb tiltó szabályok után conntrack problémái nem végtelen a mérete
Naplózás, zajszűrés zajszűrés papagáj protokollok (bcast, mcast és barátaik) egyéb tiltjuk, de nem érdekel forgalmak spoof után, state előtt naplózás action=log log-prefix= rizsa limit távoli naplózás, logelemzés, riasztás
Mit kell szűrni/engedélyeni? IP4, 6?, ESP, AH, GRE, ICMP, UDP, TCP ICMP engedélyezni: ping (echo-request echo-reply) hálózati hibákat jelzők: time-exceeded destination-unreachable source-quench tiltani: a többit :) TCP engedélyezett forgalomból kiszűrni: priv forrás portok (1024 alatti portok) nem szabályos flag kombinációkat
Terelés hálózatok szerint, fastruktúra forgalom felbontása irányok szerint src-address=lan dst-address=inet jump=lan-inet src-address=inet dst-address=lan jump=inet-lan tovább bontható egyéb szempontok szerint több szintű alág a fán, pl protokollok szerint... átláthatóbb szabályrendszer könnyebb hibakeresés, bővíthetőség gyorsabb feldolgozás, kevesebb erőforrás igény
további információk: http://www.andrews.hu/