Jak zavřít porty na firewallu

[Miroslav Šilhavý]

Ach jo, mit elementarni znalosti je proste dulezite. Vzdy a vsude. Mimochodem na konfiguraci firewallu vyslo jen na rootu nekolik clanku, staci pohledat. A pak se teprve ptat!

To je otázka názoru. Windows měly s firewallem pěkný průšvih do WinXP SP1. Od té doby zavedli ve výchozím stavu firewall zavřený i na serverech a poskytli rozhraní pro instalační programy, jak mají vkládat své výjimky. A funguje to víceméně bez zásahu a dostatečně bezpečně i pro duchem nepřímného admina. Linux je ale rozvrkočený, každý vendor programuje jinak, každá distribuce má jiné zásaday. To, že např. firewall nefunguje a není konfigurován automaticky, je podle mě velká slabina linuxu. Druhá obrovská slabina je, že nelze nastartovat kernel s implicitním dropem. Když selže script, který se má starat o firewall, nastartuje systém bez něj - to nelze nazvat jinak, než bezpečnostním úletem celé architektury.

[Reklama]

[scientific]

ZAJDAN:

Toho jsem si plně vědom, proto se také pídím po tom, jak toho docílit. Jen mi přijde, že někteří se hodně diví, proč to chci udělat. Krom toho opakovaně jsem zmínil, že weby mi na serveru neběží a když už, tak ne pro veřejný přístup.

phpkral:

Považuji za naprosto jasné, že port není zdrojem vysokého trafficu, ale služba. To ale nemění nic na tom, že zavřením portů které nechci používat, například pormapper 111 UDP budu mít od vysokého trafficu pokoj. Ale chápu, že Vám to přijde jako hodně šílené řešení, že tak by se to dělat nemělo, ale mě je to fuk, nehodlám se živit jako linux admin, ani nemám budget pro najmutí linux admina a správu serveru, jen chci, aby věci co potřebuji "nějak" běžely a já nemusel řešit, že mi píše DC a CSIRT. CentOS bez zajištění bezpečnosti je použitelný? Jestli to dobře chápu, tak u každého CentOS je jen otázka času, než někdo hackne server útokem brute force útokem. Nikdy jsem se nevyjádřil, že očekávám, že se na linuxu nemusí nikdy nic konfigurovat, jen, že doufám, že u fail2ban bude v pořádku a použitelná defaultní konfigurace.

Miroslav Šilhavý:

No něco mi říká, že Debian by určitě bez předinstalované fail2ban určitě nevyšel, právě vzhledem k zásadám distribuce.

Obecně:

Z této vlny odpovědí jsem se nedozvěděl nic nového. Pořád to chápu tak, že co mám v plánu udělat je v pořádku. Tedy zavřít všechny porty a na následujících řádkách povolit jen ty porty, které mé služby potřebují. Nehodlám řešit hloubkovou analýzu a tím, že zaříznu veškerou komunikaci si prostě pomůžu.

1. Zavřít všechny síťové porty
2. Nainstalovat fail2ban
3. Možná ještě zkusím změnit defaultní port pro SSH

[František Ryšánek]

Fail2ban si IMO zobe data z logu SSH, Cyrus IMAP/POP a patrně spousty dalších věcí (běžné varianty ftpd...)
Zbaví vás otravných robotických útoků hrubou silou, kdy zombie botnet zkouší různá hesla (pomalý slovníkový útok + k tomu pár kombinací čísílek apod.) Je to užitečné v situacích kdy hrozí u lokálních uživatelů slabá hesla, a přitom potřebujete nechat konkrétní službu otevřenou z celého světa. Pokud máte na stroji účet jenom sám, a máte silné heslo, tak už fail2ban velkou výhodu nepřinese...
Přesun SSH na jiný port není špatný nápad, vyloučíte tím otrapy kteří zkouší známé starší díry v SSH (zas tolik jich není) a nedají si tu práci, najít SSH na nestandardním portu.

Nevím o distribuci, kde by byl fail2ban nainstalovaný v základu. Ne že bych to zkoumal. V Debianu kde jsem ho chtěl, musel jsem si ho sám doinstalovat. Tušímže stačilo ze standardního balíčku.

Potřebujete především zabránit napadení počítače zvenčí. Tzn. zafiltrovat především input.
Jak se Vám někdo dostane dovnitř, tak už je docela krátká cesta k tomu, aby se dostal k rootovským právům, a pak Vám nějakých pár pravidel v iptables stejně nepomůže.
Ale v zásadě Vám jistě nic nebrání dát si "-P drop" i na output a povolit si směrem ven jenom služby co fakt potřebujete k užitečnému provozu. Zbavíte se tím zneužití jednotlivých služeb jako "reflektorů" v případech, kdy útočník nezískal systém plně pod svou kontrolu. Patrně bych relace směrem ven filtroval podle cílového portu, tzn. na jaké porty to chodí ven. Z lokálu ven se totiž všechna spojení otvírají se zdrojovým portem dynamickým, 1024 a výš... to neofiltrujete. Jako první věc bych povolil asi DNS - tzn. především UDP na port 53. (Zrovna to DNS možná používá 53 i jako lokální/zdrojový port, nejsem si jistý.) Hloupé je, že i tak ten filtr v outputu bude dost široký - a každá díra, kterou otevřete, bude použitelná pro spáchání DoS na někoho dalšího na dotyčnou službu.

Nakonec souhlasím s předřečníky, že je třeba se zaměřit na specifické zabezpečení služeb, které potřebujete nechat otevřené do světa. Aby neměly v konfiguraci trapné přehmaty (známé díry).

Loopback device není nějakým "principem" těch pár příkazů co jsem poslal. Je to IP rozhraní, které se používá pro lokální IP komunikaci v rámci jediného stroje. (Pro software, který není natolik pokročilý, aby pro lokální komunikaci použil lokální rouru / filesystem socket, nebo nějaké alternativní mechanismy.) Nemá valného smyslu, filtrovat si provoz v rámci jediného stroje.

Těch pár řádek co jsem poslal... prostě jsem zkopíroval holý základ ze své starší tvorby. A naučil jsem se to před lety z nějakých tutoriálů od Rustyho Russela, které byly původně pro IPchains (ještě před netfilterem/iptables). Popravdě takhle na jednom stroji to je pohoda. Trochu se to zkomplikuje, když má ten stroj forwardovat traffic mezi dvěma sítěmi, případně NATovat atd. A co teprve když Vám roste počet rozhraní. A proč syrové IPtables? Snažím se vidět přesně co dělám. Postupem času zjišťuju, že je to asi porucha ze stejného soudku jako perpeťáctví, protože člověk nemůže umět všechno... Prostě jsem se to kdysi naučil, tak to používám. IPtables nejsou složité. Osobně mi přijdou složitější na pochopení různé "zjednodušující" uživatelsky přítulné nadstavby :-( protože nevím, co přesně dělají. Dokud se nepodívám přes iptables -L .

[scientific]

Wau, si vylepšujete karmu, fakt mi až překvapivě skvěle pomáháte, moc děkuji.

Takže fail2ban ani nemá význam instalovat, chápu, není tak důležitý, jak si uživatel, co mi to napsal myslel, akorát mě popletl. No pravidelnou aktualizací se ty známe přehmaty (díry) eliminují, nebo se pletu? Já fakt nepoužívám moc služeb, fakt jen SNMP, SSH, HTTP, HTTPS nic víc mě nenapadá, tam doufám známé díry ve stable verzích nejsou. Dobře, souhlasím se změnou z firewalld -> iptables.

Každá služba má svůj síťový port a běží na určitém protokolu TCP/UDP, případně na obou. Pokud chci otevřít port např 80 a nemohu na internetu najít, jestli běží na TCP nebo UDP, mohu pro jistotu otevřít raději oba a ono si to už nějak poradí?

Jestli to dobře chápu, měl by můj iptables konfigurační soubor vypadat nějak takhle, určitě tam mám nějaké chyby?:

iptables -P INPUT DROP # zahazovat pakety vstupující do mého serveru libovolným portem
iptables -P OUTPUT DROP # zahazovat pakety vystupujících z mého serveru libovolným portem
##### Nějaké standardní nezbytnosti, většině z nich ani nerozumím a rozumět nechci
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
##### Povolení ICMP packetu pro ping
INPUT -p icmp --icmp-type ping -j ACCEP
##### cokoliv na localhostu bude fungovat, například můj web, který chci vidět jen já ze svého serveru
-A INPUT -i lo -j ACCEPT
##### pouze OUTPUT, jelikož můj web, který tam běží je určen pouze pro prohlížení na localhostu, asi běží na TCP i UDP, zcela jistě OUTPUT, příkazy směrem ze serveru do jiných serverů
-A OUTPUT -p udp --dport 80 -j ACCEPT 
-A OUTPUT -p tcp --dport 80 -j ACCEPT
-A OUTPUT -p udp --dport 443-j ACCEPT 
-A OUTPUT -p tcp --dport 443-j ACCEPT
##### SNMP démon pro monitorovací aplikaci, která je na jiném serveru, asi OUTPUT
-A OUTPUT -p udp --dport 161 -j ACCEPT 
-A OUTPUT -p tcp --dport 161 -j ACCEPT
##### SSH démon, asi běží na TCP i UDP, zcela jistě INPUT, příkazy směrem do serveru
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -p udp --dport 22 -j ACCEPT
##### Done. Snad jsem na nic nezapomněl, ale to poznám podle toho zda mi nějaká služba přestane fungovat. :-D

[phpkral]

tak dlouhe prispevky nikdo cist nebude ... .

[Reklama]

[uf]

iptables ...

Ne, obávám se, že toto fungovat nebude.


> Každá služba má svůj síťový port a běží na určitém protokolu TCP/UDP, případně na obou. Pokud chci otevřít port
> např 80 a nemohu na internetu najít, jestli běží na TCP nebo UDP, mohu pro jistotu otevřít raději oba a ono si to už
> nějak poradí?

To si sice poradí, ale už zas otvíráš něco, co není potřeba.


> ##### Nějaké standardní nezbytnosti, většině z nich ani nerozumím a rozumět nechci

To je chyba.


> ##### Povolení ICMP packetu pro ping
> INPUT -p icmp --icmp-type ping -j ACCEP

Když nepovolíš odchod odpovědi, stejně ti ping fungovat nebude.


>##### cokoliv na localhostu bude fungovat, například můj web, který chci vidět jen já ze svého serveru
>-A INPUT -i lo -j ACCEPT

Zas: bez povolení odpovědí nemá smysl.


> ##### pouze OUTPUT, jelikož můj web, který tam běží je určen pouze pro prohlížení na localhostu, asi běží na
> TCP i UDP, zcela jistě OUTPUT, příkazy směrem ze serveru do jiných serverů
>-A OUTPUT -p udp --dport 80 -j ACCEPT 
>-A OUTPUT -p tcp --dport 80 -j ACCEPT
>...

Špatně. Odchozí paket se vrací do portu (tzn. je pro něj --dport) port klientského počítače, ze kterého přišla žádost. Port 80 je v tomto případě zdrojový.
Web používá TCP, ne UDP.
Z obdobných důvodů ti nepojedou ani tvé další služby.

[scientific]

Uf:

Děkuji ti za další nové informace, my ten seznam pravidel snad dáme do kupy. :-)

> ##### Povolení ICMP packetu pro ping
> INPUT -p icmp --icmp-type ping -j ACCEP
Když nepovolíš odchod odpovědi, stejně ti ping fungovat nebude.

Správně by to mělo být tedy, mohlo mi dojít, že musím povolit o odpověď na ten ICMP request.. To je přesně to, když máte vysokou školu IT, ale v praxi Vám to prostě hned nedojde.
iptables -A INPUT -p icmp --icmp-type ping -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type ping -j ACCEPT

>##### cokoliv na localhostu bude fungovat, například můj web, který chci vidět jen já ze svého serveru
>iptables -A INPUT -i lo -j ACCEPT

Zas: bez povolení odpovědí nemá smysl.

Takže loopback odešle požadevek na http a ta mu ho zase vrátí, chápu. Takže správně by to bylo zase:
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -i lo -j ACCEPT

> ##### pouze OUTPUT, jelikož můj web, který tam běží je určen pouze pro prohlížení na localhostu, asi běží na
> TCP i UDP, zcela jistě OUTPUT, příkazy směrem ze serveru do jiných serverů
>-A OUTPUT -p udp --dport 80 -j ACCEPT
>-A OUTPUT -p tcp --dport 80 -j ACCEPT
>...

Špatně.tzn. je  Odchozí paket se vrací do portu (pro něj --dport) port klientského počítače, ze kterého přišla žádost. Port 80 je v tomto případě zdrojový.
Web používá TCP, ne UDP.
Z obdobných důvodů ti nepojedou ani tvé další služby.

Zmátla mě wikipedie, na stránce https://cs.wikipedia.org/wiki/Seznam_%C4%8D%C3%ADsel_port%C5%AF_TCP_a_UDP se v tabulce píše, že http používá oboje, tcp i udp. Teď to chápu, že na všech pravidlech pro output musí být místo cílového portu specifikovaná zdrojový port.
iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT

Tedy takhle je to už správně?:
##### zahazovat libovolné pakety vstupující do/z mého serveru libovolným portem
iptables -P INPUT DROP
iptables -P OUTPUT DROP
##### Nějaké standardní nezbytnosti, které nechápu k čemu slouží
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
##### Povolení ICMP packetu pro ping
iptables -A INPUT -p icmp --icmp-type ping -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type ping -j ACCEPT
##### cokoliv na localhostu bude fungovat, například můj web, který chci vidět jen já ze svého serveru
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -i lo -j ACCEPT
##### mám web, který je určen jen pro localhost, ale chci mít možnost prohlížet si jiné weby z jiných serverů
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT
iptables -A INPUT -p udp --dport 443-j ACCEPT
iptables -A INPUT -p tcp --dport 443-j ACCEPT
iptables -A OUTPUT -p udp --sport 443-j ACCEPT
iptables -A OUTPUT -p tcp --sport 443-j ACCEPT
##### SNMP démon pro monitorovací aplikaci
iptables -A INPUT -p udp --dport 161 -j ACCEPT
iptables -A INPUT -p tcp --dport 161 -j ACCEPT
iptables -A OUTPUT -p udp --sport 161 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 161 -j ACCEPT
##### SSH démon, asi běží na TCP i UDP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p udp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
iptables -A OUTPUT -p udp --sport 22 -j ACCEPT

[V.]

A) Tazatel stejně dojede na to, že se stará o něco, čemu nechce rozumět.

B) Web může běžet i na udp, well known porty pro web obsahují tcp i udp. Výhoda udp je v tom, že u asymetrického routingu to firewally méně pravděpodobně zahodí než u tcp. Ale pravda, best practice je mít web na tcp.

C) Hodí se vědět co chci a pak se ptát, zda mnou zvolený postup je to nejlepší. Když chci poskytovat nějaké služby a zvolím nějakou distribuci, tak zřejmě vyberu možnosti (rozsah) instalace. Pak musím doinstalovat to, co potřebuji pro to, abych mohl optimálně dlouhodobě spravovat svůj server, tj. dělat efektivně svou práci.

D) Pokud jsem začátečník, doporučuji si evidovat co jsem vše udělal, abych mohl později porovnávat nalezená zjištění se svými kroky, identifikovat jak se mění stav a chování aplikace i uživatelů. Aneb občas budou mé kroky mít i vedlejší efekt, je fajn, když o tom budu aspoň tušit.