Förbättra säkerheten för FreeBSD med hjälp av IPFW och SSHGuard

VPS-servrar riktas ofta mot inkräktare. En vanlig typ av attack dyker upp i systemloggar som hundratals obehöriga ssh-inloggningsförsök. Att konfigurera en brandvägg är mycket användbart, men i sig kan det inte hända att störande intrångsförsök kontrolleras tillräckligt.

Denna handledning visar hur man konstruerar en förbättrad intrångsbarriär för FreeBSD med två program, ipfwbrandväggen och sshguard. SSHGuard är ett litet tilläggsprogram som övervakar systemloggar för "missbrukande" poster. När brottslingar försöker få åtkomst, sshguardinstruerar de ipfwatt blockera trafik som kommer från gärningsmannens IP-adress. Gärningsmannen stängs då effektivt ute.

När man väl har förstått hur dessa program fungerar är det ganska enkelt att hantera serverskydd. Även om den här guiden är fokuserad på att konfigurera FreeBSD, gäller delar av den andra operativsystem och brandväggsprogram.

Steg 1. Konfigurera IPFW

FreeBSD tillhandahåller 3 brandväggar i sin standard ( GENERIC) kärna, ipfw, pf, och ipfilter. Var och en har fördelar och fans, men ipfwär FBSD:s inbyggda brandväggsprogramvara och ganska enkel att använda för våra syften. Det är värt att notera att det ipfwgör många saker som dess man-sida visar, men funktioner som NAT, trafikformning, etc., behövs inte för den typiska VPS-situationen. Lyckligtvis uppfyller brandväggens grundläggande funktioner lätt våra krav.

För att starta brandväggen vid uppstart, lägg till följande till /etc/rc.conf:

firewall_enable="YES"
firewall_script="/usr/local/etc/IPFW.rules"
firewall_logging="YES"

Den serviceKommandot är tillgängligt för att starta / stoppa brandväggen manuellt:

[user@vultr ~]$ sudo service ipfw start

Kommer naturligtvis ipfwinte att göra någonting förrän den lägger till regler, ofta från en fil, i det här exemplet som finns på /usr/local/etc/IPFW.rules. Regelfilen kan faktiskt finnas var som helst eller ha vilket namn som helst, så länge den matchar parametern "firewall_script". Regelfilen beskrivs i detalj nedan.

Steg 2. Installera och konfigurera SSHGuard

sshguardfinns i flera smaker för användning med olika brandväggar. Använd pkgverktyget för att hämta och installera sshguard-ipfw:

[user@vultr ~]$ sudo pkg install sshguard-ipfw

I de flesta fall är det allt man behöver göra. Lämplig variabel infogas automatiskt i /etc/rc.confför start vid uppstart:

sshguard_enable="YES"

Standardinställningarna fungerar normalt bra. Om olika värden är nödvändiga, ger sshguardman-sidan detaljerad information om parametrarna:

# sshguard--program defaults, so don't need to be in rc.conf unless assigning different value
# sshguard_pidfile="/var/run/sshguard.pid"
# sshguard_watch_logs="/var/log/auth.log:/var/log/mail"
# sshguard_blacklist="40:/var/db/sshguard/blacklist.db"
# sshguard_safety_thresh="40"
# sshguard_pardon_min_interval="420"
# sshguard_prescribe_interval="1200"

Du kan börja sshguardmed den vanliga serviceuppmaningen:

[user@vultr ~]$ sudo service sshguard start

Steg 3. Skapa ett regelskript

Det svåraste är att skapa brandväggens regeluppsättning. ipfwkan använda det medföljande /etc/rc.firewallskriptet, men det måste modifieras för att passa SSHGuard, såväl som olika operativa scenarier. Ett antal webbsidor och FreeBSD Manual har användbar information om att göra detta. Det är dock inte så svårt att skriva en regelfil, dessutom kan en anpassad regeluppsättning vara lättare att förstå och ändra vid behov.

En viktig egenskap hos ipfwregler är att första matchen vinner vilket betyder att regelordningen är viktig. I ipfwär varje regel ett kommando och regelfilen är ett körbart skalskript. Det gör att regeluppsättningen kan ändras genom att ändra regler och sedan köra regelfilen som skalskriptet det är:

[user@vultr /usr/local/etc]$ sudo ./IPFW.rules

I allmänhet kommer en regelfil att definiera en variabel för ipfwkommandot, sedan rensa de nuvarande reglerna, utfärda generiska regler och sedan fortsätta med att ange "out"-regler, följt av "in"-regler. ipfw-manualsidan och andra resurser innehåller en mängd information om regelstruktur och alternativ som är minst sagt många.

Sedan FreeBSD sshguard-versionen har uppdaterats till version 1.6.2 har metoden för att infoga blockeringsregler för lagöverträdare ändrats. Nu hålls förövarnas adresser i en ipfw-tabell (tabell 22 för att vara specifik), snarare än att infogas i reglerna över 55 000 som tidigare.

Lyckligtvis är det ganska enkelt att ställa in regelfilen för att använda tabellen. Det är bara att sätta tabellregeln på rätt plats, och se till att använda rätt syntax när du skriver regeln.

När den sshguardhittar en gärningsman, lägger den till gärningsmannens adress i sin svarta lista, och infogar även adressen i ipfwtabellen så att det kommer att "utlösa" att neka åtkomst. Denna regel kommer att uppnå dessa syften:

01000 deny ip from table\(22\) to any

Det är fortfarande nödvändigt att sätta regler som tillåter inkommande tjänster över 01000 i det här fallet. Låt oss till exempel säga att adressen 10.20.30.40är en lagöverträdare i tabell 22, och vi har den här ipfw-regeln:

56420 allow tcp from any to me dst-port 22 in via $vif

Eftersom ipfwmöter regel 01000 före regel 56420 , 10.20.30.40är blockerad . Det kommer aldrig att ses av "tillåt 22 in"-regeln alls. Om tillåtregeln hade ett "vanligt" nummer som 00420 , skulle den dåliga trafiken släppas in och aldrig blockeras (eftersom 00420 är mindre än 01000 och "första matchen vinner").

En trevlig funktion med den uppdaterade versionen är att nu när sshguard startar läggs alla adresser i den svarta listan till i tabellen och är tillgängliga för att blockera inkommande lagöverträdare utan dröjsmål. Den svarta listan är kumulativ och behålls mellan sessionerna.

Vid det här laget är det förmodligen klokt att visa en komplett ipfwregeluppsättning modifierad för sshguard. Kommentarerna ska göra det ganska enkelt att följa regellogiken:

#!/bin/sh

# ipfw config/rules
# from FBSD Handbook, rc.firewall, et. al.

# Flush all rules before we begin.
ipfw -q -f flush

# Set rules command prefix
cmd="ipfw -q add "

vif="vtnet0"

# allow all for localhost
$cmd 00010 allow ip from any to any via lo0

# checks stateful rules.  If marked as "keep-state" the packet has
# already passed through filters and is "OK" without futher
# rule matching
$cmd 00101 check-state

# allow DNS out
$cmd 00110 allow tcp from me to any dst-port 53 out via $vif setup keep-state
$cmd 00111 allow udp from me to any dst-port 53 out via $vif keep-state

# allow dhclient connection out (port numbers are important)
$cmd 00120 allow udp from me 68 to any dst-port 67 out via $vif keep-state

# allow HTTP HTTPS replies
$cmd 00200 allow tcp from any to any dst-port 80 out via $vif setup keep-state
$cmd 00220 allow tcp from any to any dst-port 443 out via $vif setup keep-state

# allow outbound mail
$cmd 00230 allow tcp from any to any dst-port 25 out via $vif setup keep-state
$cmd 00231 allow tcp from any to any dst-port 465 out via $vif setup keep-state
$cmd 00232 allow tcp from any to any dst-port 587 out via $vif setup keep-state

# allow icmp re: ping, et. al. 
# comment this out to disable ping, et.al.
$cmd 00250 allow icmp from any to any out via $vif keep-state

# alllow timeserver out
$cmd 00260 allow tcp from any to any dst-port 37 out via $vif setup keep-state

# allow ntp out
$cmd 00270 allow udp from any to any dst-port 123 out via $vif keep-state

# allow outbound SSH traffic
$cmd 00280 allow tcp from any to any dst-port 22 out via $vif setup keep-state

# otherwise deny outbound packets
# outbound catchall.  
$cmd 00299 deny log ip from any to any out via $vif

# inbound rules
# deny inbound traffic to restricted addresses
$cmd 00300 deny ip from 192.168.0.0/16 to any in via $vif
$cmd 00301 deny ip from 172.16.0.0/12 to any in via $vif
$cmd 00302 deny ip from 10.0.0.0/8 to any in via $vif
$cmd 00303 deny ip from 127.0.0.0/8 to any in via $vif
$cmd 00304 deny ip from 0.0.0.0/8 to any in via $vif
$cmd 00305 deny ip from 169.254.0.0/16 to any in via $vif
$cmd 00306 deny ip from 192.0.2.0/24 to any in via $vif
$cmd 00307 deny ip from 204.152.64.0/23 to any in via $vif
$cmd 00308 deny ip from 224.0.0.0/3 to any in via $vif

# deny inbound packets on these ports
# auth 113, netbios (services) 137/138/139, hosts-nameserver 81 
$cmd 00315 deny tcp from any to any dst-port 113 in via $vif
$cmd 00320 deny tcp from any to any dst-port 137 in via $vif
$cmd 00321 deny tcp from any to any dst-port 138 in via $vif
$cmd 00322 deny tcp from any to any dst-port 139 in via $vif
$cmd 00323 deny tcp from any to any dst-port 81 in via $vif

# deny partial packets
$cmd 00330 deny ip from any to any frag in via $vif
$cmd 00332 deny tcp from any to any established in via $vif

# allowing icmp re: ping, etc.
$cmd 00310 allow icmp from any to any in via $vif

# allowing inbound mail, dhcp, http, https
$cmd 00350 allow udp from any 53 to me in via $vif
$cmd 00360 allow tcp from any 53 to me in via $vif
$cmd 00370 allow udp from any 67 to me dst-port 68 in via $vif keep-state

$cmd 00400 allow tcp from any to me dst-port 80 in via $vif setup limit src-addr 2
$cmd 00410 allow tcp from any to me dst-port 443 in via $vif setup limit src-addr 2

# SSHguard puts offender addresses in table 22. Set up the table rule
# Please note the '\(22\)' syntax, necessary since it's run as shell command
$cmd 01000 deny ip from table\(22\) to any

# allow inbound ssh, mail. PROTECTED SERVICES: numbered ABOVE sshguard blacklist range 
$cmd 56420 allow tcp from any to me dst-port 22 in via $vif setup limit src-addr 2
$cmd 56530 allow tcp from any to any dst-port 25 in via $vif setup keep-state
$cmd 56531 allow tcp from any to any dst-port 465 in via $vif setup keep-state
$cmd 56532 allow tcp from any to any dst-port 587 in via $vif setup keep-state

# deny everything else, and log it
# inbound catchall
$cmd 56599 deny log ip from any to any in via $vif

# ipfw built-in default, don't uncomment
# $cmd 65535 deny ip from any to any

Steg 4. Start och testning

Systembehoven varierar och olika val av portar att blockera eller avblockera återspeglas i regeluppsättningen. När regeluppsättningen är klar, spara filen till /usr/local/etc/IPFW.rulesoch starta FBSD-tjänsterna:

 # service ipfw start
 # service sshguard start

Den utökade brandväggen bör nu vara igång! Kontrollera sshguard:

 [user@vultr ~]$ sudo pgrep -lfa ssh

Om den sshguardkörs visas dess pid och fullständiga kommandorad:

720 /usr/local/sbin/sshguard -b 40:/var/db/sshguard/blacklist.db -l /var/log/auth.log -l /var/log/maillog -a 40 -p 420 -s 1200 -w /usr/local/etc/sshguard.whitelist -i /var/run/sshguard.pid

Detta visar brandväggens regeluppsättning med statistik och senaste gången ett paket matchade regeln:

 [user@vultr ~]$ sudo ipfw -cat list

Efter timmar eller dagar läggs förövares adresser till på svartlistan och även i tabell 22. För att se alla adresser i tabellen, använd det här kommandot:

ipfw table 22 list

Resultatet skrivs ut som:

10.10.10.118/32 0
10.10.10.72/32 0
...

Som beskrivits ovan är anslutningar från dessa adresser inte tillåtna. Naturligtvis sshguardkommer det inte att finnas några adresser i listan vid första körning , men med tiden kan den bli ganska lång. Ett alternativ är att skapa separata blockeringsregler för adresser med flera poster i tabellen och sedan ta bort dem från den svarta listan.

Steg 5. Håll dig vaksam...

Det är en bra idé att ibland kontrollera loggar för att säkerställa att intrång är kontrollerade. I allmänhet /var/log/auth.logoch /var/log/securityär informativa. Luckor eller fel i att täcka nätverkstjänster kan bli uppenbara. Att ändra brandväggens regeluppsättning efter behov är en normal del av serveradministrationen.

I tidigare sshguard-versioner, när /var/db/sshguard/blacklist.dbfilen hade vuxit sig stor, kunde den förhindra att den sshguardstartade vid systemstart. Ta bort eller byta namn på svartlistfilen får sshguardstarta. Det här problemet verkar vara åtgärdat i den senaste sshguard-versionen, så den här lösningen är förmodligen inte längre nödvändig.

Se till att vitlista IP-adressen som du är ansluten till SSH-sessionen från. Om du av misstag låser dig ute kan du alltid ansluta till noVNC-konsolen på https://my.vultr.com och vitlista din IP.

Sammanfattningsvis, att använda kombinationen av ipfwoch sshguardhjälper till att hålla ditt FreeBSD-system säkert och göra sitt jobb. Att minimera påträngande nätverksaktivitet har en extra fördel: mindre "brus" gör det lättare att spåra och ställa in systemets drift, vilket bidrar till en säkrare, bättre fungerande server.

Att effektivt skydda ett FreeBSD-system/-server är inte särskilt komplicerat. Även om det krävs en blygsam ansträngning för att få det igång, lönar det sig i avsevärt bättre VPS och projektsäkerhet.