Fórum Root.cz
Hlavní témata => Server => Téma založeno: scientific 09. 03. 2018, 18:54:54
-
Hezký večer,
prosím si od Vás radu, jak vypnout všechny porty na firewallu. Vždycky mi server někdo hackne a generuje velký traffic a co hůř do transitu, nedávno portmaper.
Tak sem se naštval a řekl sem si, že prostě zakážu komunikaci na všech portech a postupně budu případně povolovat jen ty porty, které mám v plánu používat.
Chvilku sem se snažil googlit, ale moc mi google nepomohl, našel sem nějaký návod pro iptables, jenže já na CentOSu nemám iptables, ale "firewalld".
Děkuji za rady, jak na to.
-
Napadlo mě něco jako:
firewall-cmd --zone=public --del-port=0-65535/udp --permanent
firewall-cmd --zone=public --del-port=0-65535/tcp --permanent
Omlouvám se za doublepost, nemám tu ikonku na editaci prvního postu, ale nevím či by to fungovalo takhle určené rozsahem.
-
Kdyz ti server vzdycky nekdo hackne, pak by zrejme stalo za to zjistit, jak konkretne se na tvuj server dostane. Firewall sam o sobe to nevyresi...
btw, "firewalld" je jenom takovej front/end pro iptables. Ja osobne nez abych pouzival neco takoveho, radsi si napisu vsechny pravidla sam. A nekde na zacatku tech pravidel je neco jako:
iptables -P INPUT DROP (taky pro OUTPUT a FORWARD)
Tim zavru vsechno, a povoluju jenom to co potrebuju (mam pristup na konzoli pres KVM, takze ze zacatku mi nevadi ze ustrihnu taky SSH, povolim to pozdeji)...
-
Nenapsal jste na jakém systému, a jestli chcete blokovat jen příchozí, nebo i odchozí provoz.
Pokud chcete mít systém bezpečný, je potřeba provádět mnoho opatření, ne jen zavírat porty.
Pokud se jedná např. o webový server, je vhodné ho mít puštěný za reverzní proxy.
Reverzní proxy je vhodné mít zcela oddělenou. Je dobré mít blokované i vešekrá spojení směrem ven (je to sice nepohodlné na správu, ale vyplatí se to).
V linuxu zapnout SELinux, na FreeBSD MAC.
Pokud máte webový server na ostro na internetu, nejlépe na něm běžíte PHP a zároveň poštovní server a možná ještě další služby, je to nejlepší cesta k průšvihům.
Pokud jde o firewall, měl by existovat ještě jeden předřazený. Softwarový firewall na samotném serveru je až last resort ochrana.
-
Rhinox: No to nevím iptables vůbec nemám nainstalovaný, ale to co mi radíš mi přijde logické, takhle funguje většina accesslistů apod, ACL se v tom mém firewallu asi říká zóna. Už asi tuším jak na to. Prostě tam dám na začátek ořezané pravidlo bez specifického portu.
Miroslav: Psal jsem, že CentOS, no asi příchozí i odchozí, proč by to mělo být otevřené, když ty porty prostě nebudu používat. Reverzní proxy neznám, znám jen reverzní DNS, občas na serveru mám jednoduché webové aplikace no, přečtu si nekde něco o reverzní proxy, ale už mi to někdo také říkal, tohle, asi na tom něco bude. :-D Však já se bavím o SW firewallu uvnitř linuxové distribuce. A ano, věřím, že většinou byl server hacknutý přes web server, teď už dávám deny from all a povolím si jen svou IP, většinou co mám na webserveru, tak nepotřebuji veřejně, jen pro sebe.
Oběma děkuji za rady a nové zkušenosti.
-
Rhinox: No to nevím iptables vůbec nemám nainstalovaný, ale to co mi radíš mi přijde logické, takhle funguje většina accesslistů apod, ACL se v tom mém firewallu asi říká zóna. Už asi tuším jak na to. Prostě tam dám na začátek ořezané pravidlo bez specifického portu.
To nejsou iptables, ale netfilter ... iptables je jen tool na konfiguraci netfilteru, a tu muzes delat i dalsima toolama. A jak bylo receno, nez pouzivat vsemozny zamlzovadla a zastiradla u kterych vlastne nevis co z toho vyleze, je lepsi si ty pravidla nastavovat primo.
Miroslav: Psal jsem, že CentOS, no asi příchozí i odchozí, proč by to mělo být otevřené, když ty porty prostě nebudu používat. Reverzní proxy neznám, znám jen reverzní DNS, občas na serveru mám jednoduché webové aplikace no, přečtu si nekde něco o reverzní proxy, ale už mi to někdo také říkal, tohle, asi na tom něco bude. :-D Však já se bavím o SW firewallu uvnitř linuxové distribuce. A ano, věřím, že většinou byl server hacknutý přes web server, teď už dávám deny from all a povolím si jen svou IP, většinou co mám na webserveru, tak nepotřebuji veřejně, jen pro sebe.
Oběma děkuji za rady a nové zkušenosti.
Bezne se dropuje prichozi provoz, ale pozor, uvedom si, ze bez dalsiho ti takova blokace odstreli uplne vsechno - nedostanes se ani na web. A jak uz ti napsal Rhinox, nastavuje se pravidlo na INPUT a pokud dotycnej stroj funguje jako router, tak na FORWARD. Nasledne se povoli jen to, co opravdu povolit chces (a jestli neco opravdu chces tak neco na tema -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT a totez samo na forward). To defakto rika, ze vazne chces dostat odpoved na komunikaci, kterou si sam vyvolal.
A proto si nemyslim (nejmin dokud nebudes zatracene dobre vedet co delas) ze je dobrej napad nastavovat DROP na OUTPUT. Protoze tam ti takovyhle pravidlo nepomuze, a budes tam muset nastavit vyjimku pro kazdou jednu vec extra. A ze jich je pozehnane (http/s,dns,ssh,mail - samo o sobe nekolik portu atd atd).
Ovsem pokud na tom stroji provozujes nejaky sluzby (mail, dns, ...) tak k nim stejne pristup povolit musis. Pak je otazka, co delas spatne spis na konfiguraci tehle veci. Samo firewall muzes pouzit k tomu, aby omezil nasledky neceho, ale nevyresis tim pricinu (muzes trebas omezit pocty pozadavku, omezit treaffic atd atd).
BTW: Klasicka proxy = cache/brana ... pro klienta (trebas browser), reverzni = totez pro server (tzn klienti se nebavej se serverem primo ale pres tu proxy).
-
Zacit na zacazku a naucit se co je port. Nez absolutme zakladni znalosti soupnout server do internetu ... .
Protoze "hacknuti serveru" ke spis problem s nejakou sluzbou. Vsadim se ze tam mas deravej wordpress nebo neco takoveho. Kdyz zavres vsechno krom 80 tak si stejne nepomuzes.
-
j:
No já bych raději fakt zakázal všechno a povolil jen to co používám. Je mi jasné, že se nedostanu na web, když nepovolím porty 80 a 443, mám server, kde nic jiného než pouze 80,443 a SSH a 161(SNMP), nic víc mě nenapadá, tak bych všechno zakázal a povolil jen tohle. Pak mám druhý server a tam mi kde mi stačí jen SSH, SNMP a custom port. Zablokoval bych všechno jak příchozí tak odchozí, nějak mi nedošlo, proč bych tak neměl učinit.
phpkral:
To těžko, WP nemám rád a navíc, weby mám na sdíleném webhostingu, ty si nehostuji sám, jak je vidět, nemám na webhosting ještě skill. Co je síťový port vím, nějaké podrobnosti mi jsou už jedno. Nejde ani tak o hacknutí serveru, to by mi nevadilo, horší je, že ten můj server je používán např skenování a tímhle to podchytím. Tak nějak nemám skill zabývat se tím, jak se to hacknutí stane, páč na serveru je pouze aplikace, kterou nijak nevyvíjím já a i kdybych měl, stejně na to nepřijdu. :-) Vím, že mi chceš pomoct, abych to podchytil lépe, ale to je na dlouho, na tyhle věci musím přijít sám postupem času. Momentálně mi jde opravdu jen o to, aby bylo povoleno opravdu jen a pouze pár portů, které mé démoni opravdu používají.
Popravdě bych byl rád, kdyby někdo zkušený co to už dává z hlavy mi napsal dva řádky, které vložím do konfiguračního souboru, aby výsledkem byl:
1. Řádek - Zablokování všeho
2. Řádek - Povolení SSH
3. Řádek - Už si povolím jen porty na kterých chci aby server komunikoval
V podstatě potřebuji neco takovéhleho, akorát aby to bylo napsané správně (nikde v těch příkazech nevidím jestli je to input nebo output) a taky asi ne všechny ty služby komunikují:
firewall-cmd --zone=public --del-port=0-65535/udp --permanent #zablokuje vše
firewall-cmd --zone=public --del-port=0-65535/tcp --permanent # zablokuje vše
firewall-cmd --zone=public --add-port=22/tcp --permanent # následně povolí SSH, které hádám běží jen na TCP
firewall-cmd --zone=public --add-port=80/udp --permanent
firewall-cmd --zone=public --add-port=80/tcp --permanent
firewall-cmd --zone=public --add-port=443/udp --permanent
firewall-cmd --zone=public --add-port=443/tcp --permanent
firewall-cmd --zone=public --add-port=161/udp --permanent
firewall-cmd --zone=public --add-port=161/tcp --permanent
-
Ještě holýma rukama v IPtables:
vypsat aktuální pravidla
iptables -L
smazat všechna aktuální pravidla (flush) - pouze v hlavní tabulce, ale nat ani mangle asi zatím používat nebudete
iptables -F
default pro chain "input" ať je drop
iptables -P INPUT DROP
default pro chain "output" by mohl být accept?
iptables -P OUTPUT ACCEPT
povolit cokoli z interního IP loopbacku
sudo iptables -A INPUT -i lo -j ACCEPT
povolit traffic směrem dovnitř, který souvisí s relacemi které jsme sami navázali směrem ven:
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTnebo
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
V tomto stavu by měly chodit interní služby přes loopback, plus byste se měl dostat všude ven, ale nikdo se nedostane k Vám dovnitř.
Příklad: povolíme port 80 směrem dovnitř:
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
Příklad: povolíme port 22 směrem dovnitř:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
Příklad: povolíme ping směrem dovnitř
iptables -A INPUT -p icmp --icmp-type ping -j ACCEPT
Je to jenom naprostý základ, ale na to jste se ptal.
Nehrozí, že Vám prostě uhodli hrubou silou (automatem) heslo na SSH?
Pokud ho potřebujete otevřené zvenčí, zvažte fail2ban.
Jak už tu někdo psal... pokud někdo využil díru v HTTPd nebo tak něčem,
co potřebujete mít otevřené do světa, tak Vám packet-level firewall nemusí
postačit.
https://www.docum.org/docum.org/kptd/
https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands
https://linux.die.net/man/8/iptables
-
František Ryšánek
Děkuji moc, za informace, jistě jste si s tím dal dost práce. Vypnu tedy firewalld a nainstaluji iptables, abych mohl použít, co jste mi sepsal. Nějaké loopback rozhraní na serveru definované je, tak snad to bude fungovat. "default pro chain "output" by mohl být accept?" Jestli to dobře, chápu, tak právě, že nemohl. Jde mi o to, aby můj server nemohl být zneužit pro generování vysokého trafficu, v minulosti sem měl problém s port mapperem, který byl zneužit a můj server generoval převysoký traffic, chtěl bych se tomu pro příště vyhnout tak, že zakážu především output, aby nemohl být generován TX přenos. Jinak to chápu, děkuji moc. Tedy stačí tam dát taktéž DROP a potom porty, které potřebuji aby komunikovali na OUTPUTU, tak pravidla budou vypadat stejně jako ty pro INPUT.
Fail2ban znám a najivně jsem si myslel, že tuto službu má centos už v sobě. Pokud nemá, tak centos je přece úplně nepoužitelný, když kdokoliv může beztrestně napadnou můj server přes SSH hrubou silou... :-(
Takže plán je jasný, doinstalovat fail2ban (doufám, že nebude třeba nic konfigurovat a postačí defaultní nastavení) + nasazení iptables s Vámi odeslanými pravidly a bude to tak, jak jsem požadoval.
Případně je ještě něco kromě povolení icmp pingu, co by mělo být povolené, jako standardně bývá otevřené, nerad bych něco opomněl.
Držte mi palce, ať se mi podaří správný efekt. Ještě jednou děkuji moc.
-
Zakazat všechny porty a povolit jen ty potřebné je snad úplně to první co človek se soudností udělá, to je esenciální základ!
A nejlepe ještě na předřazeném routeru. Jsou stroje, u kterých filtruju i jejich otput.
Každopádně firewal nestačí pokud na tom běží web a ten sám je napadnetulnej.
Dneš k většině průniků dojde právě tudy.
-
Jde mi o to, aby můj server nemohl být zneužit pro generování vysokého trafficu ...
Fail2ban znám a najivně jsem si myslel, že tuto službu má centos už v sobě. Pokud nemá, tak centos je přece úplně nepoužitelný, když kdokoliv může beztrestně napadnou můj server přes SSH hrubou silou... :-(
Takže plán je jasný, doinstalovat fail2ban (doufám, že nebude třeba nic konfigurovat a postačí defaultní nastavení) ...
Za generovani "vysokeho trafiku" nemuzou porty, ale nezabezpecena sluzba ktera za nima poslocha. I kdyz je jasne, ze metoda zakazat vsechno a povolit potrebne je na prvni strance jakehokoliv navodu.
CentOS bez fail2ban pochopitelne pouzitelny je.
A jestli doufas, ze na linuxu nebudey muset nic konfigurovat tak sis spatne vybral.
-
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!
-
František Ryšánek
Viem ze to sem nepatri, ale tvoj prispevok si zasluzi pochvalu.
-
Zalezi, jakou ma OP konfiguraci, ale je dost mozne, ze bude potreba ty uvedene priklady doplnit o iptables6 kvuli IPv6 nebo se mylim?
-
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.
-
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
-
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 .
-
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
-
tak dlouhe prispevky nikdo cist nebude ... .
-
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.
-
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 (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
-
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.