Rozdíl mezi REJECT a DROP ve firewallu

Rozdíl mezi REJECT a DROP ve firewallu
« kdy: 01. 01. 2025, 23:48:02 »
dává smysl pravidlo v OUTPUT -j REJECT (kontra DROP)? přijde icmp, dává to nějaký smysl?


Wasper

  • ***
  • 126
    • Zobrazit profil
    • E-mail
Re:má smysl iptables -je REJECT misto drop v OUTPUT
« Odpověď #1 kdy: 02. 01. 2025, 01:00:31 »
dává smysl pravidlo v OUTPUT -j REJECT (kontra DROP)? přijde icmp, dává to nějaký smysl?
Nechapu otazku - co je konkretne cilem cviceni?

Pokud tim clovek blokuje neco sobe, tak to smysl dava (okamzity reject misto dlouheho timeoutu tak neprudi), asi porad na smysl do rejectu hazet tcp/113 (ident) pokud tam nebezi prislusna servica, dal bych do rejectu 80 pokud tam neni apache/nginx s redirem na 443, opet aby kdyz nekdo da omylem http:// misto https:// apod.

Re:má smysl iptables -je REJECT misto drop v OUTPUT
« Odpověď #2 kdy: 02. 01. 2025, 07:21:38 »
Zamyslete se, na koho ten REJECT vs. DROP bude mířit, a s jakým efektem.

Reject je zdvořilé explicitní odmítnutí s okamžitým účinkem, tzn. "ano jsem tu, ale nemám zájem". Odesilateli se pošle nějaká ICMP odezva, proč mu jeho traffic neprošel.

DROP je "tvářím se, že tu nejsem, ale ať si tazatel počká = musí si sám pro sebe timeoutovat, aby k tomu závěru došel".

Jsou porty/situace/ směry příchozích pokusů, kde 100% trafficu budou tvořit šmejdi z internetu, kteří hledají otevřený port, aby třeba zkoušeli hádat hesla apod. Těm nemá cenu napovídat a šetřit tak jejich čas / zrychlovat obrátku pokusů o útok.

Naopak jsou situace, kde nějaké to "ICMP unreachable" je součástí správného a svižného fungování nějakého protokolu. Viz třeba tradičně zmíněný "ident" v souvislosti se SMTP (nevím jak moc je to dnes ještě aktuální) nebo třeba "couldn't fragment" při autodetekci path MTU (provádí TCP stack per connection, pokud se nepletu). Pak jsou třeba situace, kdy si ISP monitoruje dostupnost Vašeho CPE pomocí pingu - takže pokud si jako bezpečnostní opatření zakážete příchozí ping (nebo odchozí odpovědi) tak je dobré, udělat díru aspoň pro monitoring ze strany ISP. Podobně když budete DROPovat odchozí tuším "ICMP ttl exceeded", tak bude příchozí traceroute zvenčí končit v /dev/null - je jistě Vaše rozhodnutí, zda chcete být maximálně bezpečný, nebo to vezmete sportovně jako že "za svou existenci se nestydím a případných DoS blbečků se nebojím".  Obecně bych byl opatrný na paušální dropování ICMP.

Re:má smysl iptables -je REJECT misto drop v OUTPUT
« Odpověď #3 kdy: 02. 01. 2025, 08:17:14 »
...moment...
Teprve teď jsem si všiml chainu OUTPUT :-)
To je traffic od lokálně běžícího procesu, směrem ven.

Tam mi popravdě nedává moc smysl něco filtrovat, snad kromě selektivního filtru na ICMP = kolik toho mašina je ochotna na sebe vykecat. Případně by se filtr na tomhle místě dal použít jako "pojistka s velmi krátkou životností" pro případ, že se někomu povede stroj "převzít" :-) V tomto kontextu mi přijde trochu bizardní řešit navíc REJECT :-)

Moje předchozí poznámka se týkala v zásadě směru "FORWARD" a "INPUT" - jenom to vracené ICMP je možné/potřebné filtrovat směrem ven.

Re:Rozdíl mezi REJECT a DROP ve firewallu
« Odpověď #4 kdy: 02. 01. 2025, 08:49:04 »
Zvažte, prosím, v jakém kontextu se pohybujete. Sešna má nějaké parametry a timeouty, když dáte REJECT, tak aplikace / služba ví, že data neprojdou a může se přizpůsobit, reagovat. Když dáte jen DROP tak aplikace bude čekat až vyprší timeout ... zároveň se tím i omezuje počet (polo)otevřených spojení ...
U sebe si to můžete dělat tak, jak chcete, jinde se doporučuje nějaká přehlednost a třeba i logování ... pak se nastavují access-listy jen v nějakých směrech v souladu s bezpečnostní politikou.


Wasper

  • ***
  • 126
    • Zobrazit profil
    • E-mail
Re:má smysl iptables -je REJECT misto drop v OUTPUT
« Odpověď #5 kdy: 02. 01. 2025, 09:13:45 »
...moment...
Teprve teď jsem si všiml chainu OUTPUT :-)

Tam mi popravdě nedává moc smysl něco filtrovat, snad kromě selektivního filtru na ICMP = kolik toho mašina je ochotna na sebe vykecat. Případně by se filtr na tomhle místě dal použít jako "pojistka s velmi krátkou životností" pro případ, že se někomu povede stroj "převzít" :-) V tomto kontextu mi přijde trochu bizardní řešit navíc REJECT :-)
Taky jsem se nachytal. :-)
A priznavam, ze tenhle use-case pouzivam hned z nekolika duvodu (primarne asi dedikovany uzivatel na AI experimenty - ma zakazane uplne vsechno krome lezt na lokalniho squida, aby pripadna kompromitovana librarka/modul neskodila vic nez malo). Pripadne kdyz mam na dedikovanem uctu steam, ktery chci z nejakeho duvodu udrzet offline (rekneme treba Skyrim SE s SKSE a automapou, ktera na novejsim EXE nefunguje...)

Kazdopadne trvam na tom, ze nechapu puvodni, takhle siroce formulovany dotaz. Ma to use-cases, pro jine veci je to naprosto k nicemu, ale prvne to chce vedet, ceho chce clovek dosahnout a pak vymyslet, jak to technicky resit.

ICMP: Re:Rozdíl mezi REJECT a DROP ve firewallu (OUTPUT )
« Odpověď #6 kdy: 02. 01. 2025, 19:35:24 »
Omlouvám se dotaz, jsem nedopsal a nedovysvětlil.. Opravdu jde o output. A cílem cvičení je ICMP paket. Vznikne takový paket a "po jakém síťovém rozdhraní poběží") že by lo?

A už děkuju za jednu odpověď , že mě to nenapadlo  - dorazí  ten ICMP packet. To mě ale vrací k otázce : jak se ta aplikace dozví, že přišel  ICMP  (host unreachable / port , admin-prohibitedatd  - iptables snese všechno ) ??? Mimo jednoho případu kde jde o reject-with tcp-reset - to se té přímo k té aplikaci dostane, to si umím představit.

Re:Rozdíl mezi REJECT a DROP ve firewallu
« Odpověď #7 kdy: 02. 01. 2025, 20:32:11 »
> jak se to aplikace dozví

Programujete trochu? Pokud ano, v čem?

Já trochu znám BSD sockets API hezky jak ho pánbůh stvořil = v céčku. Tzn.:
- na straně klienta se TCP spojení navazuje: socket(), connect()
- na straně serveru klasická práce s TCP vypadá takto: socket(), bind(), listen(), accept()
V obou případech dostanete "otevřený file descriptor" - pokud všechna volání skončila úspěchem.
S otevřeným socketem/deskriptorem se dál pracuje pomocí funkcí jako send()/recv(), případně read()/write(), trochu specialita je select() = lze čekat na událost od kteréhokoli z více otevřených socketů ve specifikované množině.
Jsou i nějaké další modernější funkce nad otevřenými sockety (poll(), co já vím co ještě).

Takže pokud se pokusíte otevřít spojení na trase, kde je předem ofiltrováno pomocí REJECT směrem ven, tak Vám na klientu connect() skončí okamžitě chybou, na serveru si nejsem jist - accept() buď skončí chybou, nebo se možná vůbec neprobudí z blokujícího čekání na příchozí TCP relaci.

Pokud byste měl navázané TCP spojení, běžel na něm provoz, a vy byste v tu chvíli vložil pravidlo s REJECTem do iptables, tak Vám selže s chybou nějaký ten send() / recv() a socket se sám zavře / padne do nějakého vadného stavu.

Výše uvedené chování při REJECTu odhaduji pro TCP = když při vytváření socketu specifikujete option SOCK_STREAM.
Jak to vypadá při použití connection-less vrstvy UDP (SOCK_DGRAM) to si nejsem jist.

Okamžitý stav socketu se dá zjistit jednak funkcí getsockopt(), druhak i bez ní jednotlivá výše zmíněná volání "končí chybou" tím způsobem, že v souladu s manuálovou stránkou vrátí "chybovou" návratovou hodnotu (třeba recv() vrací 0 bajtů přijato, jiné funkce mohou vracet přímo chybový kód se znaménkem mínus) - vedle návratové hodnoty bývá současně k dispozici globální proměnná errno, kterou lze interpretovat na textovou zprávu (řetězec) funkcemi strerror() nebo perror()... k tomu všemu jsou v linuxu man pages.

Tom5

  • ***
  • 107
    • Zobrazit profil
Re:Rozdíl mezi REJECT a DROP ve firewallu
« Odpověď #8 kdy: Dnes v 09:22:24 »
Osobně dávám všude REJECT a povoluji/nezakazuji ICMP. IMHO DROP útočníkům nic nestěžuje a pro mne je důležitější funkční služba a jednodušší správa.

Re:Rozdíl mezi REJECT a DROP ve firewallu
« Odpověď #9 kdy: Dnes v 09:42:04 »
Pokud jde o ICMP tak existuje doporuceni NIST ktere vyjmenovava ICMP zpravy ktere by se nemely dropovat.
Z hlavy si pamatuju jen ICMP host unreachable.
I nas v praci se nejaci mozkovi giganti ze security rozhodli zahazovat kompletne vsechno ICMP vsude na vnitrni siti a to se pak dely veci. Hlavne systemy ktere mely nakonfigurovane HA mely problemy, umrely na timeout protoze cekaly dlouho na pripojeni do databaze.

jjrsk

  • *****
  • 605
    • Zobrazit profil
Re:Rozdíl mezi REJECT a DROP ve firewallu
« Odpověď #10 kdy: Dnes v 10:26:39 »
Bavime se o odchozim provozu (OUTPUT) tzn chceme zakazat klientovi se nekam pripojit nebo serveru na nejaky provoz odpovedet ....

Tzn vzdy by tam mel byt REJECT... jednoduse proto ze je to nas stroj, a tudiz chceme aby reagoval co nejrychleji.

Smerem zvenku (INPUT) je to spis opacne. V tomhle pripade drop omezuje zatizeni linky + pripadne posilani rejectu na skutecny cil utoku.