Netfilter
Iptablesissa on neljä erilaista taulua (table). Taulut ovat vain ylin kategoria, joka pitää sisällään useamman ketjun eli alakategorian, joiden sisällä on varsinaiset säännöt. Sinua kiinnostaa taulut vasta sitten kun teet jotain momnimutkaista ja eksoottista. Muutoin on vain nippelitietoa, että kaikki tästä eteenpäin kohdistuu tauluun nimeltä filter.
Iptables käyttää (eli aidosti taulu filter käyttää, mutta ei jäädä kahlaamaan nippelissä) neljää erilaista ketjua:
- INPUT – se käsittelee kaikki saapuvat yhteydet; kun joku saapuu sivuille, niin iptables katsoo onko IP-osoitteelle ja portille 443 (https-yhteys) jotain sääntöä,
- OUTPUT – se kattaa ulospäin liikkuvat asiat, kun serverillä jokin asia haluaa päästä ulospäin; kuten webserveri haluaa vastata tai SSH ylipäätään toimii.
- FORWARD – uudelleenohjaukset, kuten routereissa. Näitä ei periaatteessa pitäisi olla käytössä ”tavallisella” serverillä
- käyttäjän tekemät
Jokaiselle ketjulle pitäisi määrittää käytäntö (policy) mitä ne tekevät oletuksena jos IP-osoite ei osu sääntöihin. Pakasta revityllä iptablesilla, jolla ei ole mitään sääntöjä, vaan se päästää kaiken sisään, niin käytöntönä on ACCEPT. Mutta ufw:n myötä tilanne hieman muuttuu ja palomuurin lähtötilanne onkin, että mitään ei päästetä sisään eikä mitään ulos.
Näet ketjujen käytännöt komennolla
iptables -L | grep policy
- ACCEPT hyväksyy yhteyden ja asiat toimivat
- DROP katkaisee yhteyden eikä kerro yhtään mitään saapujalle; näyttää siltä, että mitään ei olisi vastassa
- REJECT kieltäytyy yhteydestä ja katkaisee sen, mutta kertoo kyselijälle, että kiitos, mutta ei kiitos
Jokaisella säännöllä on kohde (target), johon se kohdistuu. Joten marssijärjestys on, kun käyttäjä/pyyntö/paketti saapuu palomuurille:
- mennään oikeaan tauluun, joka tässä on aina filter
- katsotaan meneekö se sisälle vai ulos, tai onko sillä toiminnan suhteen omaa ketjua
- mennään oikeaan ketjuun ja katsotaan, onko siellä erillistä sääntöä (eli targetia); jos on, niin se toteutetaan
- jos sääntöä ei löydy, niin noudatetaan käytännön mukaista
Se mikä iptablesissa on vaikeaa, ainakin minulle periaattellisella tasolla, on oivaltaa, että se ei ole täysin samanlainen palomuuri kuin mitä mielletään vaikka selaimessa tai wifin routerissa. Niissä palomuuri on ulko- ja sisämaailman välillä. Kunhan yhteys on muodostettu palomuurin läpi, niin sitten mennään mihin mennään. Iptables taasen voi sisältää ketjuja myös sen mukaan mitä paketille aiotaan tehdä. Eli palomuuri toimii eräällä tavalla myös järjestelmän sisällä vauhtien mitä menee, minne menee ja kenen toimesta.
Vaikeus hahmottaa iptablesin toimintaa tulee siitä, että vaikka ACCEPT/DROP toimivat sillä hetkellä siinä paikassa. Mutta jokainen ketju voi olla myös ehdollinen ja haarautua. DROP katkaisee siihen paikkaan, mutta ACCEPT voikin jatkaa matkaa, ja määrätyissä tilanteissa tipauttaakin yhteyden muista syistä.
iptables -komento koostuu osasta tai kaikista osasista. Esimerkiksi komento iptables -A INPUT -p tcp --dport ssh -s 10.10.10.10 -j DROP tarkoittaa, että
- sääntö kirjoitetaan ketjun INPUT viimeiseksi, ja
- jos käytettävä protokolla on tcp ja
- jos portti on SSH:n käyttämä ja
- jos IP-osoite on 10.10.10.10
- niin yhteys katkaistaan
- muutoin jatketaan matkaa seuraavaan sääntöön
However, since custom chains don’t have a default policy, make sure you end up doing something to the packet. Here, we’ve added a last line that drops everything else.
iptables -F <ketju>
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT
Perhaps you’ve been facing some brute force attacks on your SSH server. Usually, attackers try to make many connections to speed up their attack. So, you can place a per-IP restriction like so, which will slow down the attackers:
iptables -A INPUT -p tcp -m tcp –dport 22 -m conntrack –ctstate NEW -m recent –set –name SSHLIMIT –rsource
iptables -A INPUT -p tcp -m tcp –dport 22 -m conntrack –ctstate NEW -m recent –set –name SSHLIMIT –update –seconds 180 –hitcount 5 –name SSH –rsource -j DROP