Dotaz: iptables script: námitky

[kyekros]

Začínám si pohrávat s iptables a snažím se sestavit pravidla, která mi ochrání poštovní server. Pokud tu bude někdo té dobroty a mrkne na to. Rad bych slyšel nějaké výtky.

#!/bin/bash

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

iptables -N spoofing
iptables -A spoofing -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables spoofing: "
iptables -A spoofing -s 192.168.0.0/16 -j DROP
iptables -A spoofing -s 172.16.0.0/12 -j DROP
iptables -A spoofing -s 10.0.0.0/8 -j DROP

iptables -N syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 5 -j ACCEPT
iptables -A syn_flood -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables syn_flood: "
iptables -A syn_flood -p TCP --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset
iptables -A syn_flood -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables syn_flood_drop: "
iptables -A syn_flood -j DROP

iptables -N ssh-whitelist
iptables -A ssh-whitelist -j RETURN

iptables -N ssh-blacklist
iptables -A ssh-blacklist -m recent --name blacklist --set
iptables -A ssh-blacklist -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables ssh-blacklist: "
iptables -A ssh-blacklist -j DROP

iptables -N ssh
iptables -A ssh -j ssh-whitelist
iptables -A ssh -m recent --update --name blacklist --seconds 43200 --hitcount 1 -j DROP         
iptables -A ssh -m recent --set --name short
iptables -A ssh -m recent --set --name long
iptables -A ssh -m recent --update --name short --seconds 60 --hitcount 5 -j ssh-blacklist
iptables -A ssh -m recent --update --name long --seconds 1800 --hitcount 20 -j ssh-blacklist
iptables -A ssh -j ACCEPT

iptables -N tcp_p
iptables -A tcp_p -p TCP --dport 465 -j ACCEPT
iptables -A tcp_p -p TCP --dport 993 -j ACCEPT
iptables -A tcp_p -p TCP --dport 995 -j ACCEPT
iptables -A tcp_p -p TCP --dport 113 -j REJECT
iptables -A tcp_p -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A tcp_p -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables tcp_p: "
iptables -A tcp_p -p TCP -j DROP

iptables -N udp_p
iptables -A udp_p -p UDP -d 224.0.0.251 --dport 5353 -j ACCEPT #multicast DNS
iptables -A udp_p -p UDP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A udp_p -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables udp_p: "
iptables -A udp_p -p UDP -j DROP

iptables -N icmp_p
iptables -A icmp_p -p ICMP --icmp-type echo-request -m limit --limit 2/s --limit-burst 5 -j ACCEPT
iptables -A icmp_p -p ICMP --icmp-type 0 -j ACCEPT
iptables -A icmp_p -p ICMP --icmp-type 3 -j ACCEPT
iptables -A icmp_p -p ICMP --icmp-type 11 -j ACCEPT
iptables -A icmp_p -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables icmp_p: "
iptables -A icmp_p -p ICMP -j DROP

iptables -A INPUT -p ALL -i lo -j ACCEPT
iptables -A tcp_p -i eth0 -p TCP --syn -j syn_flood
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ssh
iptables -A INPUT -i eth0 -j spoofing
iptables -A INPUT -p TCP -j tcp_p
iptables -A INPUT -p UDP -j udp_p
iptables -A INPUT -p ICMP -j icmp_p

Odpovědi

[Michal Kubeček]

  iptables -A tcp_p -i eth0 -p TCP --syn -j syn_flood
  ...
  iptables -A syn_flood -p TCP --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset

Pokud mne paměť neklame, součástí podmínky --syn je i to, že ACK není nastaven, takže to druhé pravidlo by nemělo mít žádný smysl.

Podobně je zbytečné testovat znovu protokol v chainech tcp_p, udp_p a icmp_p, když do nich stejně posíláte jen pakety s příslušným protokolem.

Také mi nedává smysl to (jediné) pravidlo v ssh-whitelist: cokoli přidáte za něj, nebude mít žádný efekt; a pokud budete vkládat před něj, tak nebude mít pro změnu žádný efekt tohle pravidlo.

[NN]

Fak jsou ty chainy nutny? Udelej ten 'limit burst' globalne na cele rozhrani, usetris 10 pravidel a cele to divadlo kolem filtrovani. Kdyz uz poustis SSH ven, tak ho omez na jednu IP, jednim pravidlem a mas vyreseno. Osobne davam 'connecting tracking' na zacatek.. Imho kazdy rozumny ISP resi spoofing rezervovanych rozsahu za tebe a stejne zadne site neforwardujes. Jeste se zeptam, UDP multicast ma skutecne RELATED,ESTABLISHED stav?

[Michal Kubeček]

Imho kazdy rozumny ISP resi spoofing rezervovanych rozsahu za tebe a stejne zadne site neforwardujes.

Naopak by bylo dobré u spojení zvenku kontrolovat cílovou adresu, jestli je to ta správná, zejména pokud tam jsou nějací démoni, kteří jsou nakonfigurovaní, aby "poslouchali jen na vnitřním rozhraní / lokální smyčce".

UDP multicast ma skutecne RELATED,ESTABLISHED stav?

Proč? To jsou dvě různá pravidla.

[kyekros]

Hezký večer, děkuji všem za připomínky.

Pokud mne paměť neklame, součástí podmínky --syn je i to, že ACK není nastaven, takže to druhé pravidlo by nemělo mít žádný smysl.

Děkuji za upozornění, ono druhé pravidlo jsem přesunul na jiné místo. V tcp-flags se ještě příliš neorientuji.

Také mi nedává smysl to (jediné) pravidlo v ssh-whitelist: cokoli přidáte za něj, nebude mít žádný efekt; a pokud budete vkládat před něj, tak nebude mít pro změnu žádný efekt tohle pravidlo.

Zde mi jedno pravidlo vypadlo. Vím, že tento chain tak jak byl interpretován neměl žádný význam.

Udelej ten 'limit burst' globalne na cele rozhrani, usetris 10 pravidel a cele to divadlo kolem filtrovani.

Je opravdu tak přínosné ušetřit několik pravidel?

Osobne davam 'connecting tracking' na zacatek..

Můžete mi někdo malinko přiblížit jak na 'connecting tracking'? Význam tohoto spojení znám, ale jak jej řešíte?

Nyní script vypadá takto:

#!/bin/bash

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

iptables -N spoofing
iptables -A spoofing -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables spoofing: "
iptables -A spoofing -s 192.168.0.0/16 -j DROP
iptables -A spoofing -s 172.16.0.0/12 -j DROP
iptables -A spoofing -s 10.0.0.0/8 -j DROP

iptables -N syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 5 -j ACCEPT
iptables -A syn_flood -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables syn_flood: "
iptables -A syn_flood -j DROP

iptables -N ssh-whitelist
iptables -A ssh-whitelist -s 1.2.3.4 -j ACCEPT #IP adresu lze podvrhnout
iptables -A ssh-whitelist -j RETURN

iptables -N ssh-blacklist
iptables -A ssh-blacklist -m recent --name blacklist --set
iptables -A ssh-blacklist -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables ssh-blacklist: "
iptables -A ssh-blacklist -j DROP

iptables -N ssh
iptables -A ssh -j ssh-whitelist
iptables -A ssh -m recent --update --name blacklist --seconds 43200 --hitcount 1 -j DROP         
iptables -A ssh -m recent --set --name short
iptables -A ssh -m recent --set --name long
iptables -A ssh -m recent --update --name short --seconds 60 --hitcount 5 -j ssh-blacklist
iptables -A ssh -m recent --update --name long --seconds 1800 --hitcount 20 -j ssh-blacklist
iptables -A ssh -j ACCEPT

iptables -N tcp_p
iptables -A tcp_p --dport 465 -j ACCEPT
iptables -A tcp_p --dport 993 -j ACCEPT
iptables -A tcp_p --dport 995 -j ACCEPT
iptables -A tcp_p --dport 113 -j REJECT
iptables -A tcp_p -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A tcp_p -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables tcp_p: "
iptables -A tcp_p -j DROP

iptables -N udp_p
iptables -A udp_p -d 224.0.0.251 --dport 5353 -j ACCEPT #multicast DNS
iptables -A udp_p -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A udp_p -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables udp_p: "
iptables -A udp_p -j DROP

iptables -N icmp_p
iptables -A icmp_p --icmp-type echo-request -m limit --limit 2/s --limit-burst 5 -j ACCEPT
iptables -A icmp_p --icmp-type 0 -j ACCEPT
iptables -A icmp_p --icmp-type 3 -j ACCEPT
iptables -A icmp_p --icmp-type 11 -j ACCEPT
iptables -A icmp_p -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables icmp_p: "
iptables -A icmp_p -j DROP

iptables -A INPUT -p ALL -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ssh
iptables -A INPUT -p TCP --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset
iptables -A INPUT -i eth0 -p TCP --syn -j syn_flood
iptables -A INPUT -i eth0 -j spoofing
iptables -A INPUT -p TCP -j tcp_p
iptables -A INPUT -p UDP -j udp_p
iptables -A INPUT -p ICMP -j icmp_p

[kyekros]

Pardon, porty nelze uvádět bez uvedení protokolu.

[NN]

Zakladni 'connection tracking' je vlastne ip_conntack plugin a toto pravidlo:

iptables -A tcp_p -m state --state ESTABLISHED,RELATED -j ACCEPT

Tzn. protoze duveruji sestavenym spojenim, dam pravidlo na zacatek, abych urychlil prochazeni paketu firewallem.

UDP pakety "zadne" stavy nemaji, tzn. nasledujici pravidlo neni uplne korektni:

iptables -A udp_p -m state --state ESTABLISHED,RELATED -j ACCEPT

Stejne mi cela ta sarada kolem SSH prijde proste zbytecna, ale asi to proste vidim jinak a jeste jedne veci nerozumim, rikas postovni server, ale nevidim 25, jak to?

[bigBRAMBOR]

taky mam ESTABLISHED,RELATED pravidlo jedno na zacatku, spousta spojeni pak nemusi skakat celej firewall aby si to pravidlo naslo nekde dole ve svem chainu. A prijde mi lepsi jedno na zacatku, nez nekolikrat ruzne rozhazenejch, stejne se mu nevyhnes.

je nejaky velky vykonovy rozdil mezi tim zalozit si vlastni chainy pro TCP, a pro UDP, dat do jednoho jedno pravidlo, do druheho 4, a pak to filtrovat a to chainů rozdelovat? U takhle maleho poctu pravidel bych si tipnul ze rychlejsi bude tech 5 pravidel tam prdnout naostro, nebo kecam?

[kyekros]

Vložil jsem tedy na začátek tento řádek:

iptables -A INPUT --p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

Jen bych se chtěl ještě zeptat. Pokud vložím pravidlo v následující podobě:

iptables -A INPUT --p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT

Přestanou mi fungovat pravidla pro omezení ICMP. Znamená to tedy, že ICMP tyto stavy má?

Původně jsem chtěl, aby bylo možné připojit se přes SMTP pouze šifrovaně, ale když o tom mluvíte, tak asi i port 25 bude zapotřebí. Patrně MTA přes něj budou spolu komunikovat.

Co se týče té komedie kolem SSH, V případě problémů se budu připojovat i z nepředvídaných míst.

[Michal Kubeček]

Jak které ICMP. Např. chybové zprávy typu destination unreachable nebo timeout exceeded by z podstaty věci měly být RELATED a echo reply ESTABLISHED. Na druhou stranu, v zahazování těchto zpráv moc smyslu nevidím.

[bigBRAMBOR]

jj, pokud chces nechat ten ICMP chain, nejak me zatim nikdo moc nepresvedcil s ICMP nejak zvlast blbnout, budes do nej muset poslat data jeste pred tim ESTABLISHED,RELATED.

Pro pripojeni na SSH z nepredvidatelnych mist mam VPN

SMTP server bez portu 25 nebude zadna slava, moc si nepopovidas. Hod si klienty na submision, a ten sifruj. Pro komunikaci mezi servery musis mit 25, a sifrovani jako option, ale nedaval bycj ji povinou.

[kyekros]

Tak jsem to opět opravil "předešlé scripty mají v sobě chyby, takže jsou nepoužitelné". Na to SSH se podívám ještě později. Jinak jsem měl závažnou chybu v řádku

"iptables -A syn_flood -m limit --limit 1/s --limit-burst 5 -j tcp_p" kde jsem měl ACCEPT.

#!/bin/bash

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

iptables -A INPUT -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p ALL -i lo -j ACCEPT

iptables -N ssh-whitelist
iptables -A ssh-whitelist -s 1.2.3.4 -j ACCEPT
iptables -A ssh-whitelist -j RETURN

iptables -N ssh-blacklist
iptables -A ssh-blacklist -m recent --name blacklist --set
iptables -A ssh-blacklist -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables ssh-black: "
iptables -A ssh-blacklist -j DROP

iptables -N ssh
iptables -A ssh -j ssh-whitelist
iptables -A ssh -m recent --update --name blacklist --seconds 43200 --hitcount 1 -j DROP         
iptables -A ssh -m recent --set --name short
iptables -A ssh -m recent --set --name long
iptables -A ssh -m recent --update --name short --seconds 60 --hitcount 5 -j ssh-blacklist
iptables -A ssh -m recent --update --name long --seconds 3600 --hitcount 20 -j ssh-blacklist
iptables -A ssh -j ACCEPT

iptables -N spoofing
iptables -A spoofing -s 192.168.0.0/16 -j DROP
iptables -A spoofing -s 172.16.0.0/12 -j DROP
iptables -A spoofing -s 10.0.0.0/8 -j DROP

iptables -N tcp_p
iptables -A tcp_p -p TCP --dport 25 -j ACCEPT
iptables -A tcp_p -p TCP --dport 465 -j ACCEPT
iptables -A tcp_p -p TCP --dport 993 -j ACCEPT
iptables -A tcp_p -p TCP --dport 995 -j ACCEPT
iptables -A tcp_p -p TCP --dport 113 -j REJECT
iptables -A tcp_p -p TCP --sport 443 -j ACCEPT
iptables -A tcp_p -j RETURN

iptables -N syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 5 -j tcp_p
iptables -A syn_flood -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables syn_flood: "
iptables -A syn_flood -j DROP

iptables -N udp_p
iptables -A udp_p -p UDP -d 224.0.0.251 --dport 5353 -j ACCEPT #multicast DNS
iptables -A udp_p -j RETURN

iptables -N icmp_p
iptables -A icmp_p -p ICMP --icmp-type echo-request -m limit --limit 2/s --limit-burst 5 -j ACCEPT
iptables -A icmp_p -p ICMP --icmp-type 0 -j ACCEPT
iptables -A icmp_p -p ICMP --icmp-type 3 -j ACCEPT
iptables -A icmp_p -p ICMP --icmp-type 11 -j ACCEPT
iptables -A icmp_p -j RETURN

iptables -A INPUT -p TCP --dport 22 -m state --state NEW -j ssh
iptables -A tcp_p -p TCP --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j REJECT --reject-with tcp-reset #DRDoS"
iptables -A tcp_p -i eth0 -p TCP --syn -j syn_flood #vyzaduji venkovni rozhrani
iptables -A INPUT -i eth0 -j spoofing #venkovni rozhrani
iptables -A INPUT -p TCP -j tcp_p
iptables -A INPUT -p UDP -j udp_p
iptables -A INPUT -p ICMP -j icmp_p

iptables -A INPUT -m limit --limit 1/minute --limit-burst 10 -j LOG --log-prefix "iptables drop: "

[NN]

No to uz vypada lepe,ale jeste bych mnel posledni drobnou poznamku. Spoofing je L3 filtrovani, ale TCP kontrola je L4, takze je lepsi ho dat v INPUT za konfiguraci rozhrani/ICMP a pred filtrovani TCP. Ie. postupuju firewallem od nizsich vstev nahoru..

[kyekros]

Děkuji za všechny rady. Jen bych se ještě zeptal. Jestli náhodou ještě nevíte, jen tak s hlavy bez hledání, o nějaké knize "nejlépe v českém jazyce" o problematice sítí včetně oněch "levelů" filtrování.

[NN]

Tak defakto standard pro samostudium jako zaklad je 'Velký průvodce protokoly TCP/IP a systémem DNS' Dostalek/Kabelova, pripadne jeste druhy dil 'Zabezpeceni'.

[kudlanka bezbozna]

Pro pripojeni na SSH z nepredvidatelnych mist mam VPN

Kolik si navlikas kondomu pri soulozi? Navic SSH potrebuje jednoduche TCP spojeni, to ti pusti ven i v blbem pakistanskem hotelu narozdil od VPN. Uz od prehistorickych dob v minulem tisicleti provozuji na mnoha serverech SSH na vysokych portech (hlavne kvuli tomu, aby mi to nelogovalo automaty) a nemam sebemensi problem.

[bigBRAMBOR]

souložím pouze privátně, s manželkou, tedy bez kondomu. Stejne tak VPNkou se pripojím domu, a neřeším kondomy.

Tedy jednou nastavim VPN, a uz neresim SSH, FTP, cokoliv, cokoliv. Staci si na to zvyknout a do budoucna to prinese o mnoho mene nastavovani, a starostí.

[kudlanka bezbozna]

A to je duvod, proc blokovat SSH? SSH navic vzdy udrzuje spravce distribuce narozdil od VPN. Ale kdo chce kam, pomozme mu tam.

[pavlix]

Ještě víc se mi na to líbí dynamicky navazovaný IPsec s veřejným rozsahem.

[bigBRAMBOR]

v pakistanu jsem nikdy nebyl, na slovensku a madarsku kam bezne jezdim maji hotely dost casto povoleno pouze port 80. OVPN navazu po portu UDP 53 - sranda je ze to bez problemu chodi i v mistech kde chteji za Internet poplatek.

[kudlanka bezbozna]

No a? Vasi argumentaci nechapu. Pres DNS se da tunelovat skoro cokoli.

[bigBRAMBOR]

pouze jsem psal reakci na vetu - Navic SSH potrebuje jednoduche TCP spojeni, to ti pusti ven i v blbem pakistanskem hotelu narozdil od VPN. Existuji VPN, kterym stacim taky jednoduche TCP (UDP) spojeni. Nechapu co je nam to k nepochopeni.

[Michal Kubeček]

Jistě, TCP tunelované uvnitř TCP je naprosto skvělá věc… (sarcasm sign)

[pavlix]

A teď už je v té diskuzi dokonalej bordel :D.

[pavlix]

Přes DNS můžeš tuneovat i v případě, že není povolené volně. Lze komunikovat s falešným autoritativním serverem a na základě toho vytvořit (ač neefektivní) transport pro data.

[iKoulee]

Je opravdu tak přínosné ušetřit několik pravidel?

Velice, samozrejme zalezi na konfiguraci a zatizeni serveru v provozu, ale netfilter je obecne v performance killer. Osobne znam pripady, kdy unload celeho netfilteru dovoli serveru obsluhovat o 50k spojeni za vterinu vice.

Opravdu kazde pravidlo skrze ktere paket projde je znat, takze opravdu se vyplati ESTABLISED spojeni povolit hned na zacatku. A pak podle poctu paketu, ktere skrze ne projdou, takze obecne nasledovane asi nestavovymi sluzbami, jako je DNS, pak sluzby s velkym poctem kratkych spojeni (http,smtp) a nakonec veci jako je SSH kde na vterine nesejde.

Dal z pohledu bezpecnosti bych Vam doporucil zamyslet se nad tabulkou OUTPUT, hodilo by se zakazat navazovani spojeni jinam nez na povolene/zname sluzby a servery. Zanesnadni to pripadnemu utocnikovy, ktery ovladne nejakou sluzbu, aby zneuzil server ke svym nekalym zamerum (dokud nema roota).