Tak tohle je myslím *hodně* tradiční dotaz :-)
1) TCP wrappers
Činnost "
tcp wrappers" se odehrává v user space. Všimněte si "signálového řetězce" inetd (nebo xinetd) -> tcpd -> užitečná bezelstná "službička". Původně tím "obalem" byl stand-alone program
tcpd, spouštěný superdémonem
inetd.
Inetd je označován za "superdémona" ne snad proto, že by byl mocný a zlý - spíš proto, že poslouchá klidně na velkém počtu různých nakonfigurovaných portů (TCP nebo UDP) a přijímá příchozí relace "na účet" menších specializovaných službiček (které už neběží trvale). Popravdě není úplně na místě, mluvit o "službičkách" v pravém slova smyslu, protože se jedná spíš o klasické lokální programy. Inetd službičku napřed nastartuje, předá jí socket v podobě otevřených deskriptorů stdin, stdout a stderr - takže jednotlivá službička nemusí nic vědět o síťování, odvede svou práci na stdin/stdout a skončí. Tzn. službička sama nepotřebuje fungovat jako skutečný
démon (fork a odpojení od terminálu, práce s
BSD sockets).
Podobně tcpd je také spouštěn až "on demand" - ale zjevně rozumí BSD socketům do té míry, že si umí zjistit adresu, odkud relace přišla.
Čili TCP relace se musí napřed navázat (něco analogického pro udp), což schytá ještě bez filtru inetd. Inetd sám do otevřeného socketu nic nezahlásí. Otevřený socket je předán prográmku tcpd, ten rozhodne zda relace splňuje či nesplňuje pravidla, a nakonec ho možná předá užitečnému komunikačnímu prográmku. Nebo ho prostě jenom zavře.
Čili každopádně proběhne v případě TCP kompletní 3-way handshake (SYN/SYN+ACK/ACK). Pokud tcpd "přikývne", ozve se klientovi "službička". Pokud tcpd zavrtí hlavou, socket se beze slova zase košer zavře (FIN/FIN+ACK, nebo snad RST).
Pokud to zkusíte telnetem, neúspěch vypadá tak, že telnet nahlásí "connected" a vzápětí "disconnected".
Drobnou variantou výše popsaného schématu je, že wrapper není stand-alone program, ale knihovna. Jmenuje se libwrap a vlastně je odjakživa součástí tcpd. Mnozí skuteční stand-alone démoni mají přilinkovánu libwrap přímo. Démon běží trvale, osobně naslouchá na TCP/UDP portu a po knihovně libwrap chce pouze palec nahoru nebo dolů, pro každou příchozí relaci. Z hlediska správce je na tom příjemné, že "access list" je nadále uložen v důvěrně známých system-wide souborech /etc/hosts.allow a hosts.deny. Také se tím ušetří režie spouštění několika procesů, což na zatíženém serveru může hrát značnou roli (zvyšuje to průchodnost).
Vlastně bych řekl, že libwrap linkují i modernější varianty démona inetd = ve skutečnosti nespouštějí stand-alone tcpd.
2) firewall
Bavíme se předpokládám v užším slova smyslu o paketovém firewallu v operačním systému... nebo o předřadném firewallu na dalším stroji. Ať už se bavíme o klasickém linuxovém
netfilteru (ovládaném přes iptables nebo nftables) nebo o tradičním BSDčkovém
berkeley packet filteru, jedná se o mechanismy, které žijí v kernelu a zacházejí s jednotlivými pakety. Fakt je, že kernelové packet-level firewally umí rozlišit směr navázání spojení (znají např. SYN flag u TCP), zvládají stateful inspection, existují helpery pro "obtížnější" protokoly vyšších vrstev (které by jinak neprocházely NATem apod.), pokročilejší paketové firewally umí obecně inspekci vyšších vrstev, umí rate-limit na počet paketů určitého typu (nepřímo rate-limit na počet příchozích spojení) apod. Samotný interní formát "předpisu sad filtrovacích pravidel" a styl jeho zpracování se u různých filtrovacích frameworků dost liší... nezabíhejme ale do detailů. Jako klíčové vlastnosti bych zde uvedl, že to pracuje "po jednotlivých paketech" a že to žije v kernelu, hodně blízko hardwaru, který DMAčkem příchozí pakety do kernelu hrne.
Pokud otestujete přístup telnetem z "ofiltrované" adresy, jsou dva možné výsledky: buď to dlouho trvá a pak se telnet timeoutuje, nebo dostanete obratem od svého IP stacku odpověď "spojení odmítnuto" (přišel zpátky paket
ICMP destination unreachable). Záleží na konfiguraci pravidla ve firewallu. Správce firewallu se může rozhodnout, zda nechá příchozího vychladnout v nejistotě (náhodný kolemjdoucí opruzující útočník si nic jiného nezaslouží), nebo ho obratem zdvořile odmítne.
Shrnutí a polozávěr:
Takže TCP wrapper žije v user space, ve své klasické podobě spouští na každé příchozí spojení 2 další procesy, relace je každopádně navázána, proběhne nějaká komunikace, snad i nějaké to kopírování dat mezi kernel space a user space (a související context switching).
Naproti tomu paketový firewall žije v kernelu a nežádoucí pakety kostí krátce poté, co se pomocí DMA objeví v RAMce. Žádný context switching do user space.
Odpovězte si sám, co z toho má menší "attack surface" a co má nižší režii = co se bude chovat líp v podmínkách DoS útoku na bázi zahlcení vysokým počtem příchozích spojení.
Pokud nehrozí zrovna divoký internet, je jistě na zvážení, zda není přínosnější relativně jednoduchá konfigurace TCP wrappers oproti paketovému firewallu.
Mimochodem, když jsme u toho... v konfiguraci síťových démonů se dá také říct, na kterých IP adresách má démon vůbec naslouchat. Trochu mi vrtá hlavou, jestli není z hlediska režie nakonec účinnější, nechat to na kernelovém packet-level filtru, pokud použijete jenom minimální sadu pravidel systémem "least privilege" = povolit pár jednotlivostí a zbytek paušálně zahazovat.
2 Odpovědí
990 Zhlédnutí