Zwiększanie bezpieczeństwa FreeBSD przy użyciu IPFW i SSHGuard

• Krok 1. Konfigurowanie IPFW
• Krok 2. Zainstaluj i skonfiguruj SSHGuard
• Krok 3. Utwórz skrypt reguł
• Krok 4. Uruchomienie i testowanie
• Krok 5. Zachowanie czujności ...

Serwery VPS są często atakowane przez intruzów. Popularny typ ataku pojawia się w logach systemowych jako setki nieautoryzowanych prób logowania ssh. Konfigurowanie zapory ogniowej jest bardzo przydatne, ale samo w sobie może nie kontrolować odpowiednio destrukcyjnych prób włamań.

W tym samouczku pokazano, jak zbudować ulepszoną barierę przed włamaniem do FreeBSD przy użyciu dwóch programów, ipfwzapory i sshguard. SSHGuard to mały program dodatkowy, który monitoruje dzienniki systemowe pod kątem „obraźliwych” wpisów. Gdy przestępcy próbują uzyskać dostęp, sshguardinstruuje, ipfwaby zablokować ruch pochodzący z adresu IP przestępcy. Sprawca zostaje następnie skutecznie odcięty.

Gdy zrozumiemy, jak działają te programy, zarządzanie ochroną serwera jest dość proste. Chociaż ten przewodnik koncentruje się na konfigurowaniu FreeBSD, jego część dotyczy innego systemu operacyjnego i oprogramowania zapory.

Krok 1. Konfigurowanie IPFW

FreeBSD zapewnia 3 zapór w swojej domyślnej ( GENERIC) jądra, ipfw, pf, i ipfilter. Każdy ma zalety i fanów, ale ipfwjest rodzimym oprogramowaniem zapory ogniowej FBSD i jest dość prosty w użyciu do naszych celów. Warto zauważyć, że ipfwrobi wiele rzeczy, jak pokazuje jego strona podręcznika, jednak funkcje takie jak NAT, kształtowanie ruchu itp. Nie są potrzebne w typowej sytuacji VPS. Na szczęście podstawowe funkcje zapory z łatwością spełniają nasze wymagania.

Aby uruchomić zaporę podczas uruchamiania, dodaj następujące elementy do /etc/rc.conf:

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

servicePolecenie jest dostępne, aby rozpocząć / zatrzymać ręcznie zaporę:

[user@vultr ~]$ sudo service ipfw start

Oczywiście ipfwnic nie zrobię, dopóki nie doda reguł, często z pliku, w tym przykładzie znajdującym się pod adresem /usr/local/etc/IPFW.rules. Plik reguł może w rzeczywistości znajdować się w dowolnym miejscu lub mieć dowolną nazwę, pod warunkiem, że pasuje do parametru „firewall_script”. Plik reguł jest szczegółowo opisany poniżej.

Krok 2. Zainstaluj i skonfiguruj SSHGuard

sshguardwystępuje w kilku wariantach do użytku z różnymi zaporami ogniowymi. Użyj pkgnarzędzia, aby pobrać i zainstalować sshguard-ipfw:

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

W większości przypadków to wszystko, co musisz zrobić. Odpowiednia zmienna jest automatycznie wstawiana w /etc/rc.confcelu uruchomienia podczas uruchamiania:

sshguard_enable="YES"

Domyślne ustawienia zwykle działają dobrze. Jeśli konieczne są różne wartości, sshguardstrona man podaje szczegółowe informacje o parametrach:

# 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"

Możesz zacząć sshguardod zwykłego servicewywołania:

[user@vultr ~]$ sudo service sshguard start

Krok 3. Utwórz skrypt reguł

Najtrudniejsze jest stworzenie zestawu reguł zapory ogniowej. ipfwmoże korzystać z dostarczonego /etc/rc.firewallskryptu, ale należy go zmodyfikować, aby uwzględnić SSHGuard, a także różne scenariusze operacyjne. Wiele stron internetowych i Podręcznik FreeBSD zawierają przydatne informacje na ten temat. Jednak pisanie pliku reguł nie jest trudne, poza tym niestandardowy zestaw reguł może być łatwiejszy do zrozumienia i zmiany w razie potrzeby.

Ważną cechą ipfwreguł jest to, że wygrywa pierwszy mecz, co oznacza, że ​​kolejność reguł jest ważna. W ipfwkażdej regule jest komenda, a plik reguł to wykonywalny skrypt powłoki. Pozwala to na zmianę zestawu reguł poprzez zmianę reguł, a następnie uruchomienie pliku reguł jako skryptu powłoki:

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

Zasadniczo plik reguł definiuje zmienną dla ipfwpolecenia, następnie usuwa bieżące reguły, wydaje ogólne reguły, a następnie przystępuje do ustanawiania reguł „out”, a następnie reguł „in”. Strona podręcznika ipfw i inne zasoby zawierają wiele informacji o strukturze reguł i opcjach, które są co najmniej liczne.

Od czasu aktualizacji sshguard FreeBSD do wersji 1.6.2 zmieniła się metoda wstawiania reguł blokowania dla przestępców. Teraz adresy przestępców są przechowywane w tabeli ipfw (konkretnie w tabeli 22), a nie wstawiane jak wcześniej w reguły powyżej 55000.

Na szczęście skonfigurowanie pliku reguł do korzystania z tabeli jest bardzo proste. To tylko kwestia umieszczenia reguły tabeli we właściwym miejscu i upewnienia się, że podczas pisania reguły używana jest poprawna składnia.

Kiedy sshguardznajdzie przestępcę, umieszcza adres przestępcy na czarnej liście, a także wstawia adres do ipfwtabeli, aby „wyzwolić” odmowę dostępu. Ta reguła osiągnie następujące cele:

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

W tym przypadku nadal konieczne jest wprowadzenie reguł zezwalających na usługi przychodzące powyżej 01000. Załóżmy na przykład, że adres 10.20.30.40jest przestępcą w tabeli 22 i mamy tę regułę ipfw:

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

Ponieważ ipfwnapotyka regułę 01000 przed regułą 56420 , 10.20.30.40jest blokowana . Nigdy nie zobaczy go reguła „zezwalaj na 22 w”. Gdyby reguła zezwalania miała „zwykły” numer, taki jak 00420 , zły ruch byłby wpuszczany i nigdy nie blokowany (ponieważ 00420 jest mniejszy niż 01000 i „wygrywa pierwszy mecz”).

Przyjemną cechą zaktualizowanej wersji jest to, że teraz, gdy sshguard uruchamia się, wszystkie adresy z czarnej listy są dodawane do tabeli i są dostępne, aby bezzwłocznie blokować przychodzących przestępców. Czarna lista jest kumulatywna i zachowywana między sesjami.

W tym momencie prawdopodobnie rozsądnie jest pokazać kompletny zestaw ipfwreguł zmodyfikowany dla sshguard. Komentarze powinny ułatwić logikę reguł:

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

Krok 4. Uruchomienie i testowanie

Potrzeby systemowe są różne, a różne wybory portów do blokowania lub odblokowywania znajdują odzwierciedlenie w zestawie reguł. Po zakończeniu zestawu reguł zapisz plik w /usr/local/etc/IPFW.rulesi uruchom usługi FBSD:

 # service ipfw start
 # service sshguard start

Rozszerzona zapora sieciowa powinna teraz działać! Sprawdź sshguard:

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

Jeśli sshguardjest uruchomiony, wyświetlane są jego pid i pełna linia poleceń:

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

Pokazuje zestaw reguł zapory ze statystykami i ostatnim razem, gdy pakiet pasował do reguły:

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

Po godzinach lub dniach adresy przestępców są dodawane do czarnej listy, a także do tabeli 22. Aby wyświetlić wszystkie adresy w tabeli, użyj tego polecenia:

ipfw table 22 list

Wynik jest drukowany jako:

10.10.10.118/32 0
10.10.10.72/32 0
...

Jak opisano powyżej, połączenia z tych adresów są niedozwolone. Oczywiście przy pierwszym uruchomieniu sshguardnie będzie żadnych adresów na liście, ale z czasem może być dość długo. Jedną z opcji jest utworzenie osobnych reguł blokowania dla adresów z wieloma wpisami w tabeli, a następnie usunięcie ich z czarnej listy.

Krok 5. Zachowanie czujności ...

Warto od czasu do czasu sprawdzać dzienniki, aby upewnić się, że włamania są kontrolowane. Ogólnie rzecz biorąc /var/log/auth.logi /var/log/securitymają charakter informacyjny. Mogą pojawić się luki lub błędy w pokrywaniu usług sieciowych. Modyfikowanie zestawu reguł zapory ogniowej w razie potrzeby jest normalną częścią administracji serwerem.

We wcześniejszych wersjach sshguard, gdy /var/db/sshguard/blacklist.dbplik urósł, mógł uniemożliwić sshguarduruchomienie systemu podczas uruchamiania systemu. Usuwanie lub zmiana nazwy pliku czarnej listy może sshguardsię rozpocząć. Wydaje się, że ten problem został rozwiązany w najnowszej wersji sshguard, więc to obejście prawdopodobnie nie jest już konieczne.

Pamiętaj, aby dodać do białej listy adres IP, z którego jesteś połączony z sesją SSH. Jeśli przypadkowo się zablokujesz, zawsze możesz połączyć się z konsolą noVNC na https://my.vultr.com i umieścić na białej liście swój adres IP.

Podsumowując, użycie kombinacji ipfwi sshguardpomaga zabezpieczyć system FreeBSD i wykonać jego zadanie. Minimalizacja uciążliwej aktywności sieci ma dodatkową zaletę: mniej „szumu” ułatwia śledzenie i dostrajanie działania systemu, przyczyniając się do bezpieczniejszego, lepiej działającego serwera.

Skuteczna ochrona systemu / serwera FreeBSD nie jest szczególnie skomplikowana. Chociaż jego uruchomienie wymaga niewielkiego wysiłku, opłaca się znacznie większe VPS i bezpieczeństwo projektu.