Tűzfal vagy átjáróház?

Linux

Anélkül, hogy sokkolni akarnék bárkit (vagy mégis...) leírom, hogyan lehet átjáróház a tűzfal. Meg azt is, mit tehetsz ellene...

A csomagszűrő tűzfal egy jó dolog. Ami a Linuxban van szintén. Teszi a dolgát és szűri a forgalmat. De vannak komoly korlátai, amiről jó ha tudsz. A legfontosabb korlát, hogy nem, vagy csak minimálisan képes a protokollt felismerni.

Miért és hol gond ez?

Egy egyszerű példánál maradva, tételezzük fel, hogy a belső hálózatod számára meg szeretnéd engedni a böngészést. Ehhez a tűzfalon kinyitod a 80 (HTTP) és 443 (HTTPS) TCP portokat kifelé. Tegyük fel nagyon gondos vagy és csak a proxy szervert engeded ki, mindenki azon keresztül böngészik. Más forgalmat a tűzfalon nem engedsz át. Ez biztonságosnak hangzik, ugye?

Akkor hol a hiba?

A hiba ott van, hogy a tűzfal is és a proxy is a HTTPS forgalmat csak "továbbítja", mivel az egy kódolt (SSL) csatorna. Tehát semmit nem tud arról, milyen forgalom megy át. Erre a proxy "CONNECT" technikáját használják a kliensek. Ha proxy sincs, akkor pedig direktben érhetőek el a 443-as porton futó szolgáltatások, ami ugye a biztonságos web, a HTTPS.

Hogyan lehet ezzel visszaélni?

Az a baj, hogy ez pofon egyszerű: mindössze egy SSH szerver és egy SSH kliens kell hozzá. Az SSH szerver lehet bárhol, a lényeg, hogy annak korlátlan netkapcsolata legyen és a 443-as TCP porton fusson az SSH. Ezt könnyű létrehozni (10 perc alatt regisztrálhat bárki kb. 4 EUR-ért virtuális szervert publikus IP-vel és Linux rendszerrel ha nincs még, ahol meg lehet csinálni).

A kliens oldalon (a védett hálózatban bármely operációs rendszer jó, nem csak a Linux) kell egy SSH kliensprogram. Ez sem gond, nem kell hozzá semmi extra. Innen két megoldás mutatkozik. A durvább teljes IP forgalmat tud átvinni bármely(!) irányban, tehát kintről befelé is. A szerencse itt az, hogy ehhez rendszergazdai (root) jog kell a kliensen. Ennek hiányában "csak" egyes TCP portokat tud beengedni valaki (már ha az kevésbé gond). Kifelé azonban minden extra jog nélkül BÁRMIT. És csak az alábbi parancs kell hozzá:

ssh -ND 1080 -p 443 külső-szerver

Ha proxy nehezíti a feladatot, akkor Linux alatt a corkscrew gyorsan megoldja:

ssh -ND 1080 -p 443 -o 'ProxyCommand corkscrew proxy-címe proxy-portja %h %p' külső-szerver

Innen már csak a megfelelő alkalmazást (pl. böngésző) kell beállítani, hogy a localhost címen a 1080-as porton SOCKS5 proxyt használjon. Ezt szinte minden program ismeri. Az ajtó nyitva áll.

És ez csak egy példa volt. Van még pár hasonló.

Mit tehetsz ellene?

A megoldás kézenfekvő, de cseppet sem egyszerű. Olyan proxy vagy tűzfal megoldás kell, ami nem csak a portot nyitja, hanem érti a protokollt is. A fenti példánál maradva egyrészt az SSL-t, másrészt a HTTP-t (ezen kettő kombinációja a HTTPS). Igen, ez azt jelenti, hogy ki kell bontani a titkosított kapcsolatot, de jelen pillanatban ez az "ára" annak, hogy a hálózatot valóban megvédd. Ha ezt teszed, az SSH nem jut át, mert az SSL mögött nem HTTP van, így a tűzfal blokkolja.

Van ilyen proxy vagy tűzfal?

A jó hír az, hogy IGEN. Linuxra is. Az egyik a Squid új verziója, a másik a Zorp-GPL tűzfal. Ez utóbbi is nyílt forrású. Ha még nem hallottál róla, akkor érdemes megnézned. A telepítése és helyes beállítása viszont cseppet sem egyszerű. Ezért meghívtuk az egyik legjobb Zorp szakembert, hogy tanítsa meg ezt neked.

A Linux Akadémia május 29., csütörtöki ingyenes, online képzésen Pfeiffer Szilárd tanítja meg neked, hogyan telepítsd és állítsd be a Zorp-GPL tűzfalat.

Szilárd a Zorpot fejlesztő csapat tagja. Kevesen vannak, akik nála jobban ismerik és értik a működését.

A 100%-ban gyakorlati képzésen a legjobbtól tanulod meg egy olyan modern tűzfal elkészítését, mely nagyságrendekkel nagyobb biztonságot nyújt.

Az ingyenes, online képzésre a Linux Akadémia weboldalán tudsz jelentkezni.

( ssikiss | 2014. 05. 27., k – 09:36 )

A zorp ingyenes verzió (nagyon) régen nem tudott https proxy-t, a honlapon található összehasonlító doksi alapján a gpl verzió "részben" tudja az ssl elemzést. Ez pontosan mit jelent? Összehasonlítva a squid képességeivel mi a helyzet?

ssl kapcsolat végződtethető zorp-szerver oldalon, új ssl kapcsolat kiépíthető zorp-kliens oldalon. Annak függvényéban, hogy mit állít szerver oldalon az ssl certet felmutató szerver, milyen az szabályozható mi legyen a kliens oldalon. Az így kibontott protokoll pedig tovább elemezhető az adott (http, smtp, stb.) proxynak megfelelően.

c

Egy hirdetes nem attol lesz hirdetes, hogy fizetett. Inkabb visszakerdezek: ez mitol szakmai hir? Egy oldalnyi szetszort anekdotazas ezereves problemakrol, meg ssh parancsok, aztan a vegere befittyen egy link, hogy gyertek a Zorp kepzesunkre. Ebben semmi hirertek nincs, onreklamozas annal tobb. Es egeszen veletlenul a prezentalo pont az a BalaBit, akik a Zorp-ot ertekesitik, meg a support-ot hozza. Pl. a havi keret utan mindossze 100EUR/oraert foglalkoznak veled, hat nem csodalatosan joarcok meg mindig? :)

De az (x) a fizetett hirdetéseket szokta volt jelölni.
Amit te anekdotázásnak nevezel, azzal kapcsolatban épp a napokban volt egy kis párbeszédünk egy itteni, nagyon hozzáértővel, annyira nem tudnak róla az emberek, hogy milyen könnyű megkerülni a tűzfalakat. És így sokan tényleg azt képzelik, hogy egy proxy elég a biztonsághoz.

fogalmam sincs, hogy lehetne tisztességesen megvédeni egy hálózatot

Ha boldog-boldogtalan számára bármit meg akarsz engedni (pl. az "okos" telefonjaikkal felcsatlakozhassanak a netre, és bármilyen random szart futtathassanak rajta), akkor sehogy se. A "nekem csak feketelistám van, minden más mehet" sajnos nem eredményez megvédett hálózatot. A fehérlistás megoldás pedig szinte mindenhol működésképtelen a hozzá szükséges energiamennyiség miatt. Ennyi, meg egy bambi.

Azért ennyire nem rossz a helyzet...
A Microsoft sokat publikál a saját belső IT megoldásairól.
Ennek célja, hogy segítse a tapasztalatokkal az Ügyfeleket.
Természetesen nem állítom, hogy az MSIT által alkalmazott módszerek minden méretben optimálisak, de tanulni, azt lehet belőlük.

Ajánlott kezdőlap (nem csak network security témában!): Microsoft IT Showcase: How Microsoft Does IT

A témához:
Microsoft Builds a Seamless Wireless Network Experience for Employees and Visitors Alike
Security Monitoring on the Microsoft Enterprise Network

Üdv,
Marci
A Microsoftnál dolgozom.

vl kifejtette, hogy szinte lehetetlen egy hálózatot megvédeni. Erre linkeltem két cikket, ami arról szól, hogy a Microsoft hogyan csinálja ezt.

Üdv,
Marci

UI: A munkahelyemet azért jelölöm meg, hogy olyan kérdésekben, ahol számít, hogy Microsoftos mondja vagy másvalaki, ott legyen egyértelműen azonosítható, hogy Microsoftosként mondom. Így elkerülhető például, hogy valaki azt gondolja, hogy a Microsoft függetlennek látszó megnyilatkozásokba csomagolja üzeneteit.

Őszintén szólva még mindig érthetetlen miért cseppentettél pont ide egy adag linket. Ha leírod azt a példát ott fent, amiben az van hogyan lehet megakadályozni M$ termékekkel pont ugyanezt a tűzfalmegkerülési esetet, akkor nagyjából OK. De így.

Pl. engem, akit ez csak hobbi szinten mint érdekesség érint, különösen zavarhat egy ilyen direkt reklám tőletek. Ez pont a másik oldal, aki rátok valszeg egyáltalán nem kíváncsi. Ez esetben csak elmormolom magamban, hogy „Ez egy gyökér” röhögök egyet, és továbblépek.
Én pl. azt jelzem az aláírásomban, hogy szoktam foglalkozni grafikával. De sosem merült fel bennem egy hasonló témánál az odaröffentek egyet, hogy ezt így csinálom itt és itt.
☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

Meglátásom szerint nem a BalaBit tanfolyamáról szól a hír. Vagy valamit én olvastam benne rosszul...
Az pedig, hogy egy GPL-es, nyílt forrású szoftvernek van kereskedelmi változata is, nem csökkenti a nyílt forrású értékét. Szerintem.
És az sem csökkenti az információ értékét mások számára, hogy te már ezzel tisztában vagy. Amikor az SSH képzésen ezt megmutattam, dőltek a döbbent kérdések, hogy hogyan kell védekezni ellene.

--
Slapic

Man in the middle nélkül is lehet egyébként?
Mert én egyetlen megoldásról hallottam: a proxy ismeri a protokollt és a benne lévő tanúsítvánnyal dekódolja a forgalmakat. (pontosan hogyan, azt persze nem tudom, de lényeg, hogy a proxy-n lévő tanúsítványt fel kell venni a kliensekre megbízhatóként, anélkül nem jut ki a netre)

Ez ennel bonyolultabb. Az SSL egy csomo cipher suite-ot tamogat, van ahol a session key a public key-el titkositva kozlekedik, ott eleg a privat kulcs a forgalom visszafejtesehez (ilyenek pl. a "sima" RSA-s cipher suite-ok), meg van ahol a forward secrecy tervezesi kriterium volt (pl. ECDHE-*), ott ertelemszeruen nem fog menni.

Meglátásom szerint nem a BalaBit tanfolyamáról szól a hír.

Meseld el, milyen szogbol nezed, hogy szamodra nem arrol szol a reklamhir. Tovabba erdekelne az is, hogy szerinted akkor mirol szol a "hir", ha nem a tanfolyasrol. En akarmerrol nezem, pontosan arrol szol. Felvetettel egy problemat, amire szerinted letezik egy megoldas, es veletlenul pont tudsz is egy tanfolyamrol, ami pont errol a megoldasrol szol. Ennyi van az irasban, semmi mas.

Vagy valamit én olvastam benne rosszul...

Nem olvastad. Irtad :)

Az pedig, hogy egy GPL-es, nyílt forrású szoftvernek van kereskedelmi változata is, nem csökkenti a nyílt forrású értékét. Szerintem.

Segitek: a modszert ugy hivjak, hogy beetetes :)

A sok lúzert Torvalds beeteti a Linuxszal, pedig csak a világuralom a célja. Majd jól meglepődik mindenki, amikor egyszercsak megváltozik a lcenc és napi 1$-t kell fizetni minden Linux kernel sor után :-)
A többi GPL-es cuccal is így fognak járni, csak még nem tudják, mert még egy sem olvasta el a GPL-t :-)
Az iskolákban is csak a beetetés zajlik, idővel az ott szerzett tudás után is jogdíjat kell majd fizetni :-)
--
Slapic

A GPL miatt az ingyenes kiadás megmarad, még ha nem is fejlesztik tovább. Ismerek pár kisebb irodát, ahol régóta jól elvannak az ingyenes kiadással és a képzést is hasznosnak találják. Nyilván aki ezt használja, az el tudja dönteni, hogy elég neki a GPL-es változat, vagy a fizetősre vált, esetleg más alternatíva után néz.
Akkor hol itt a beetetés?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

A beetetes nem attol beetetes, mert a beeteto megszunteti az ingyenes termeket, hanem mert a beetetett kinovi azt. Ennyi erovel az aruhazi kostolo sem beetetes, hiszen te dontod el, hogy megveszed-e a fizetos termeket, vagy csak csipegetsz. Tokmindegy, hogy GPL, vagy nem, kitorolheted a GPL-lel a segged, ha support-ra van szukseged, marpedig hacsak nem gittegyletet uzemeltetsz, akkor elobb-utobb szukseg lesz ra. Nem tudom, hogy hany csillio ellenpelda kell meg nektek (pedig az utobbi idoben eleg sok van), hogy rajojjetek, a forraskod nem egy magikus szer, ami valami csodalatos modon magatol megoldja minden problematokat.

De felolem jatszhatod meg a hulyet a vegtelensegig, hidegen hagy. Hol a beetetes, Lachazan bazz, hol lenne. Meg dzsi-pi-el.

Nyilván az a 3-4 hely nem mérvadó, amit ismerek, de ott bőven elég az opensource változat, fel sem merült a fizetős szükségessége. Support sem igazán kell, mert egyszer megcsinálták nekik, ledokumentálták nekik és a szükséges kisebb módosításokat már önállóan is képesek elvégezni.
A GPL-t csak arra hoztam fel, hogy az opensource változat valószínűleg nem fog eltűnni egyik napról a másikra.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Nekem is tapasztalatom, hogy ami alapvetőnek tűnik, az sokszor ismeretlen. Sokan nem ismerték a screent, port forwardot ssh-val, stunnel, ilyesmik. Le kell vetni az előítéleteket. Egyébként a Suricatanak több értelme van már imho, mint egy Zorpnak, főleg, ha konfigolni akarod. Az IPS rész, a gyorsítókártyák, fpgak támogatása is benne van, stb. Luxemburgban volt tavaly ősszel a "summit" a fejlesztést támogató alapítványnak, meg volt ott szignatúrák írása packet dumpok alapján stb. Volt ott pár "veszélyes" arc. A szignatúrást részt bírtam, a telepítés nyilván nem egy nagy trúváj, de amikor a paket dumpból ki lehetett hámozni mindeféle kínai cuccot, és arra írni szignatúrát, na, az már durván jó volt. Feldobta a napot :) Szóval ez az amit már Zorppal nem csinálsz meg. Imádtam, szeretem a céget, syslog-ng rulez, de a Zorpból nagyon hiányzik az IPS rész, amivel össze lehet kötni az egészet. Suricata meg olyan tualjdonságokkal rendelkezik, amivel sok más cucc nem (pl Snort).

Tegnap néztem, a videót viszont érdekelne, hogy milyen teljesítménnyel bír. Nekünk jelenleg a bejövő/kimenő forgalom durván 1.5Gbit és olyan 130e packet/sec, persze ha jön valami ddos akkor több. A teljesen belső forgalom durván 3gbit, és 500e packet/sec. Ezek milyen vast kellene hadrendbe állítani főleg ha NFQ-val szeretném hajtani?

Fedora 20, Thinkpad x220

Ago, te szeretnéd tartani? :-)
Amúgy egy általános szerver/hálózat védelem (külső támadásokkal szemben) képzés lesz, a Suricata csak egy része lesz. Egy átfogó képet és tudást adok annak, aki eljön arra, hogyan csináljon tűzfalat egyszerűen. SOHO vackok helyett...

--
Slapic

Nem, konkrétan amit mondtam EH-n is, hogy videókat gyártok most, amiben van ilyen téma is. A teljes linux securityben :) de legalább mindenkinek lehet választani, meg inspiráló, hogy mindenben a hallgatókat szolgáljuk ki. Én mondjuk angol piacra is tolni akarom, a hangsávok utólagos kezelése már részletkérdés.

Ez úgy hangzik, mintha szerinted a tűzfal és az IDS/IPS csereszabatos megoldás lenne. Holott sokkal inkább egymás kiegészítői lehetnének - ha ez valós cél lenne bárhol is.

Sok olyan igen nagy költségvetésű céget ismerek, ahol állítólag fontos a security... vesznek is mindenféle drága dobozokat, aztán pipa. :)

--
zrubi.hu

Hát az iptables + Suricata többet tud imho, mint az iptables + Zorp. A Zorp kitünően enforceolja a http forgalomra a http forgalmat, de a Suricatanak pl nem portot adsz meg ,hanem azt, hogy http forgalom és arra ez meg ez vonatkozik. És még pár más dolog. A Suricata ezen felül elég sokat tud - pl a http forgalomból lementeni a futtatható állományokat stb. -, és konkrétan a policy enforcementre is jó. Ezen felül még szűr. A hagyományos sima protokoll szűrő tűzfalaknak vége. IMHO. Időpzarlás. A protokoll szűrő + ips/ids + alkalmazás kontrollos tűzfalaknak van értelme a mai környezetben.
Nem tudom mennyi időt töltöttél el céges környezetben, meg mennyit securityval, van persze akik dobozt vesznek, de itt nem a pipa szokott lenni szerencsés esetben a választás alapja. Egyébként nem csereszabatos, de a Suricata pl már tartalmazza a tűzfalnak a nem layer2-es szűrő részét.

A hagyományos sima protokoll szűrő tűzfalaknak vége

Elég rég óta dolgozom a security területen, de nem tudom pontosan melyikekre is gondolsz...
Komolyan. A legtöbb kereskedelmi tűzfal (Cisco, Checkpoint, stb) csak egy sima csomagszűrő + sok marketing.

'sima protokollszűrő' - azaz alkalmazás szintű tűzfal nem sok van a piacon, GLP-es pedig csak elvétve. Ezekkel szinte mindent meg lehet tenni, amit egy adott protokolon belül lehetséges. Olyan dolgokat lehet(ne) megtenni, amit egy átlag tűzfalas el sem tud képzelni. De a gyakorlatban sajnos igen kevés helyen találkozom ilyennel. (Az okait persze ismerem)

Szóval komolyan érdekelne mire gondolsz amikor 'sima protokollszűrőt' emlegetsz.

--
zrubi.hu

:) Azért van néhány. Pl F5, Palo Alto , de egyébként mindig mosolygok amikor az IPS/Deep Inspection whatever hívők és a Proxy hívők egymásnak esnek. Valójában szerintem nincs királyi út a hibrid megközelítés a nyerő. Azaz protokoll enforcement és szignatúra alapú (vagy mostanában inkább már tulajdonság) ellenőrzés együtt.

És akkor ebből hogyan is jött ki, hogy az csak egy csomagszűrő?

"De közelébe sincs ahhoz, amit egy Zorp-pal meg lehet oldani."
Nézzük pld. a Zorp GTP szűrésével/vizsgálatával kapcsolatos képességeit. Nulla? Mondhatom akkor, hogy a Zorp a közelében sincs annak, amit egy Checkpointtal meg lehet oldani? Az én szempontomból lehet, hogy pont annyira igaz, mint a te szempontodból a fenti.
De ettől mégsem lesz általánosan igaz.
--
zsebHUP-ot használok!

Én a "Checkpoint egy csomagszűrő" posztod tekintem felvetett témának (a Zorp többet tud kijelentéssel megspékelve), ha ebbe szerinted nem kapcsolódik bele a GTP képessége, akkor oké. :)
Van olyan terület, ahol a Zorp többet tud, van olyan, ahol a Checkpoint. Úgy általában szerintem nem lehet kimondani, hogy egyik jobb, mint a másik, mert a kérdés rögtön az lesz, hogy mire. :)
--
zsebHUP-ot használok!

hagyjuk. Igazad van. Nekem meg időm lesz így :)
egyébként a protokoll és alkalmazás szűrés már két külön fogalom lett imho. Az utánunk következő valamely felhasználóval értek egyet, hogy a több sávos megközelítés a nyerő. Van alapvető layer2-es szűrés, majd azután DPI/whatever, abban IPS és végül bizonyos protokolloknál meg, amiben jöhet jó sok minden - pl http-n utazva - még valami proxy alapú szűrés - vírus, bármi más - ami kiszűri amit nem lehet másként. És a rétegeken egyre kevesebb jut át, az erőforrások kezelése pedig jobb lesz így.

( manfreed (nem ellenőrzött) | 2014. 05. 27., k – 10:58 )

Mi a helyzet a websockettel?

( bra | 2014. 05. 27., k – 13:22 )

Business as usual, párbeszéd a "security guy"-jal:
"Olyan proxy vagy tűzfal megoldás kell, ami nem csak a portot nyitja, hanem érti a protokollt is."
"Ha ezt teszed, az SSH nem jut át, mert az SSL mögött nem HTTP van, így a tűzfal blokkolja."
Vagy nem, mert akkor HTTP-be csomagoljuk az SSH-t.
"Jó, de HTTP-n tudjuk szűrni, hogy csak a legfontosabb site-okat tudd nézni, például az indexet, meg a fészbúkot"
OK, akkor a facebook HTTP API-jával fogok SSH proxyt csinálni.
"Jó, de ezt más nem tudja megtenni, mert nem ért hozzá"
Viszlát.
--
zsebHUP-ot használok!

( turul16 v | 2014. 05. 27., k – 23:16 )

Akarsz-e ellene tenni?

NEM!
Ha meg megis kene, akkor kihozom a tap kabelt.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( sh4d0w808 | 2014. 05. 28., sze – 11:37 )

sub

-------------------------
Trust is a weakness...

( gee v | 2014. 05. 28., sze – 22:19 )

Szerintem ez érdekes, és nem kell ellene beszélni akkor sem, ha reklám.

Engem mondjuk nem érint, mert eddig minden cégnél, ahol tűzfallal dolgoztam, ott az volt a mondás, hogy bentről bármi kimehet (mondjuk az smtp kivételével, de az is csak a botnetek által küldött spam ellen), és az alkalmazottak meg VPN-nel bejöhetnek a belső hálóra.

Szóval nincs szükségük se bentről, se kintről megkerülni a tűzfalat. Épp ezért ezt akadályozni sem kell.