Forbedre sikkerheten for FreeBSD ved å bruke IPFW og SSHGuard

VPS-servere er ofte målrettet av inntrengere. En vanlig type angrep dukker opp i systemlogger som hundrevis av uautoriserte ssh-påloggingsforsøk. Det er veldig nyttig å sette opp en brannmur, men det kan i seg selv ikke kontrollere forstyrrende inntrengingsforsøk tilstrekkelig.

Denne opplæringen viser hvordan du konstruerer en forbedret inntrengningsbarriere for FreeBSD ved å bruke to programmer, ipfwbrannmuren og sshguard. SSHGuard er et lite tilleggsprogram som overvåker systemlogger for "misbrukende" oppføringer. Når lovbrytere forsøker å få tilgang, sshguardinstruerer de ipfwå blokkere trafikk som stammer fra lovbryterens IP-adresse. Gjerningsmannen blir da effektivt stengt ute.

Når det først er forstått hvordan disse programmene fungerer, er det ganske enkelt å administrere serverbeskyttelse. Selv om denne veiledningen er fokusert på å konfigurere FreeBSD, gjelder deler av den andre operativsystemer og brannmurprogramvare.

Trinn 1. Konfigurere IPFW

FreeBSD har 3 brannmurer i sin standard ( GENERIC) kjerne, ipfw, pf, og ipfilter. Hver har fordeler og fans, men ipfwer FBSDs opprinnelige brannmurprogramvare og ganske enkel å bruke for våre formål. Det er verdt å merke seg at det ipfwgjør mange ting som man-siden viser, men funksjoner som NAT, trafikkforming osv. er ikke nødvendig for den typiske VPS-situasjonen. Heldigvis oppfyller brannmurens grunnleggende funksjoner enkelt våre krav.

For å starte brannmuren ved oppstart, legg til følgende i /etc/rc.conf:

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

Den servicekommandoen er tilgjengelig for å starte / stoppe brannmuren manuelt:

[user@vultr ~]$ sudo service ipfw start

Vil naturligvis ipfwikke gjøre noe før den legger til regler, ofte fra en fil, i dette eksemplet som ligger på /usr/local/etc/IPFW.rules. Regelfilen kan faktisk være plassert hvor som helst eller ha et hvilket som helst navn, så lenge den samsvarer med "firewall_script"-parameteren. Regelfilen er beskrevet i detalj nedenfor.

Trinn 2. Installer og konfigurer SSHGuard

sshguardkommer i flere smaker for bruk med forskjellige brannmurer. Bruk pkgverktøyet til å hente og installere sshguard-ipfw:

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

I de fleste tilfeller er det alt man trenger å gjøre. Den aktuelle variabelen settes automatisk inn i /etc/rc.conffor oppstart ved oppstart:

sshguard_enable="YES"

Standardinnstillingene fungerer normalt bra. Hvis det er nødvendig med forskjellige verdier, gir sshguardman-siden detaljert informasjon om parameterne:

# 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 starte sshguardmed den vanlige servicepåkallingen:

[user@vultr ~]$ sudo service sshguard start

Trinn 3. Lag et regelskript

Den vanskeligste delen er å lage brannmurregelsettet. ipfwkan bruke det medfølgende /etc/rc.firewallskriptet, men det må modifiseres for å imøtekomme SSHGuard, så vel som forskjellige operasjonsscenarier. En rekke nettsider og FreeBSD Manual har nyttig informasjon om å gjøre dette. Det er imidlertid ikke så vanskelig å skrive en regelfil, dessuten kan et tilpasset regelsett være lettere å forstå og endre når det er nødvendig.

En viktig egenskap ved ipfwregler er at første kamp vinner, noe som betyr at regelrekkefølge er viktig. I ipfwer hver regel en kommando, og regelfilen er et kjørbart skallskript. Det gjør at regelsettet kan endres ved å endre regler og deretter kjøre regelfilen som skallskriptet det er:

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

Vanligvis vil en regelfil definere en variabel for ipfwkommandoen, deretter fjerne gjeldende regler, utstede generiske regler, og deretter fortsette med å angi "ut"-regler, etterfulgt av "in"-regler. ipfw-manualsiden og andre ressurser inneholder et vell av informasjon om regelstruktur og alternativer som er mildt sagt mange.

Siden FreeBSD sshguard-versjonen har blitt oppdatert til versjon 1.6.2, har metoden for å sette inn blokkeringsregler for lovbrytere endret seg. Nå holdes lovbryternes adresser i en ipfw-tabell (tabell 22 for å være spesifikk), i stedet for å settes inn i reglene over 55 000 som før.

Heldigvis er det ganske enkelt å sette opp regelfilen for å bruke tabellen. Det er bare å sette tabellregelen på rett plass, og passe på å bruke riktig syntaks når du skriver regelen.

Når den sshguardfinner en lovbryter, plasserer den lovbryterens adresse på svartelisten, og legger også adressen inn i ipfwtabellen slik at den vil "utløse" nekting av tilgang. Denne regelen vil oppnå disse formålene:

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

Det er fortsatt nødvendig å sette regler som tillater innkommende tjenester over 01000 i dette tilfellet. La oss for eksempel si at adressen 10.20.30.40er en lovbryter i tabell 22, og vi har denne ipfw-regelen:

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

Siden ipfwmøter regel 01000 før regel 56420 , 10.20.30.40er blokkert . Det vil aldri bli sett av "tillat 22 inn"-regelen i det hele tatt. Hvis tillat-regelen hadde et "vanlig" tall som 00420 , ville den dårlige trafikken slippes inn og aldri blokkert (fordi 00420 er mindre enn 01000 og "første kamp vinner").

En fin funksjon med den oppdaterte versjonen er at nå når sshguard starter opp, legges alle adressene i svartelisten til i tabellen og er tilgjengelige for å blokkere innkommende lovbrytere uten forsinkelser. Svartelisten er kumulativ og beholdes mellom øktene.

På dette tidspunktet er det sannsynligvis fornuftig å vise et komplett ipfwregelsett modifisert for sshguard. Kommentarene skal gjøre det ganske enkelt å følge regellogikken:

#!/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

Trinn 4. Oppstart og testing

Systembehov varierer og ulike valg av porter som skal blokkeres eller fjernes, gjenspeiles i regelsettet. Når regelsettet er fullført, lagre filen til /usr/local/etc/IPFW.rulesog start FBSD-tjenestene:

 # service ipfw start
 # service sshguard start

Den utvidede brannmuren skal nå kjøre! Sjekk sshguard:

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

Hvis sshguardkjører, vises pid og full kommandolinje:

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

Dette viser brannmurregelsettet med statistikk og siste gang en pakke samsvarte med regelen:

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

Etter timer eller dager blir adressene til lovbrytere lagt til svartelisten og også tabell 22. For å se alle adressene i tabellen, bruk denne kommandoen:

ipfw table 22 list

Resultatet skrives ut som:

10.10.10.118/32 0
10.10.10.72/32 0
...

Som beskrevet ovenfor er tilkoblinger fra disse adressene ikke tillatt. Selvfølgelig sshguardvil det ikke være noen adresser i listen ved første gangs kjøring , men over tid kan den bli ganske lang. Ett alternativ er å lage separate blokkeringsregler for adresser med flere oppføringer i tabellen og deretter slette dem fra svartelisten.

Trinn 5. Vær på vakt...

Det er en god idé å sjekke logger av og til for å sikre at inntrenging er kontrollert. Generelt, /var/log/auth.logog /var/log/securityer informative. Huller eller feil i dekning av nettverkstjenester kan bli tydelige. Å endre brannmurregelsettet etter behov er en normal del av serveradministrasjonen.

I tidligere sshguard-versjoner, når /var/db/sshguard/blacklist.dbfilen hadde vokst seg stor, kunne den hindre sshguardfra å starte ved oppstart av systemet. Fjerning eller nytt navn til svartelistefilen har tillatelse sshguardtil å starte. Dette problemet ser ut til å være løst i den nyeste sshguard-versjonen, så denne løsningen er sannsynligvis ikke lenger nødvendig.

Sørg for å hviteliste IP-adressen du er koblet til SSH-økten fra. Hvis du ved et uhell låser deg ute, kan du alltid koble til noVNC-konsollen på https://my.vultr.com og hvitliste IP-en din.

Oppsummering, bruk av kombinasjonen av ipfwog sshguardhjelper med å holde FreeBSD-systemet ditt sikkert og gjøre jobben sin. Minimering av påtrengende nettverksaktivitet har en ekstra fordel: mindre "støy" gjør det enklere å spore og justere systemdriften, noe som bidrar til en sikrere, bedre kjørende server.

Effektiv beskyttelse av et FreeBSD-system/server er ikke spesielt komplisert. Selv om det kreves en beskjeden innsats for å få den i gang, lønner det seg i vesentlig større VPS og prosjektsikkerhet.