Sprzątając ostatnio spamerskie komentarze zauważyłem, że za sporą część z nich odpowiada raptem kilkanaście maszyn. Wyblokowanie ich na stałe jest mniej kłopotliwe niż ciągłe sprzątanie wymoderowanych komentarzy (choć niewidoczne, rozpychają niepotrzebnie bazę danych i backup).
Można to oczywiście zrobić na wiele sposobów i na różnych poziomach ale skoro na początku cyklu o konfiguracji VPS doradzałem używanie shorewalla, to opiszę tutaj jak odciąć wybrańców na poziomie połączenia sieciowego.
Drobna uwaga: w poprzednim artykule doradzałem instalację pakietu
shorewall-perl. W bieżących wersjach Debiana i Ubuntu takowego już nie ma, instalujemy po prostushorewall(który zawiera zresztą właśnie perlową wersję generatora reguł, shellowa została od wersji 4.4.0 zarzucona).
Blokowanie ad hoc
Metoda poręczna gdy zauważę, że właśnie teraz ktoś zalewa mnie spamem, próbuje się włamać albo zapuścił przesadnie agresywny scraper:
$ sudo shorewall drop 61.143.154.42 $ sudo shorewall reject 202.108.5.35
i odpowiedni adres zostaje tymczasowo odcięty (do czasu restartu maszyny).
Różnica między drop a reject: drop po prostu po cichu ignoruje
pakiety z danego źródła, klient nie dostaje żadnej informacji o
błędzie (zwykle czeka na jakiś timeout by ustalić, że połączenie się
nie udało) a reject explicite odrzuca połączenie (klient od razu
dostaje informację o błędzie). To pierwsze może nieco utrudnić
życie spamerskim skryptom, przynajmniej tym gorzej napisanym.
Są też shorewall logdrop i shorewall logreject, działające
identycznie ale dodatkowo zapisujące (standardowo w
/var/log/messages) informację o odrzuconych połączeniach.
Sprawdzić aktualną zawartość listy można robiąc
$ sudo shorewall show dynamic
(w starszych wersjach może być potrzebne nieco dłuższe
sudo shorewall show chain dynamic). Wynik może wyglądać następująco:
Chain dynamic (2 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 61.143.154.42 0.0.0.0/0
0 0 reject all -- * * 202.108.5.35 0.0.0.0/0
Odwrócenie ewentualnej pomyłki:
$ sudo shorewall allow 1.2.3.4
Listy te można nawet zapisywać na dłużej - polecenie sudo shorewall
save zrzuca je do /var/lib/shorewall/save, skąd mogą być wczytane
ponownie przez sudo shorewall restore - ale do trwałego blokowania
lepiej nadaje się metoda opisana w następnym rozdziale.
Stała czarna lista
Do trwałego blokowania lepiej od powyższego nadaje się czarna lista
utrzymywana w /etc/shorewall/blacklist. Umieszczane na niej adresy
można opatrzeć komentarzami, sam plik wersjonować i backupować, oprócz
całkowitej blokady danego IP można też blokować mu wybrane porty i/lub
protokoły, można blokować całe podsieci.
Plik ten może wyglądać następująco:
#ADDRESS/SUBNET PROTOCOL PORT # Próby włamań 38.111.147.84 - - 46.4.158.20 - - 62.221.61.155 - - 67.210.98.180 - - 75.125.222.178 - - # ... # Spam blogowy 14.136.194.138 - - 41.190.16.17 - - 46.17.96.43 - - 58.215.78.157 - - 61.19.252.148 - - # ...
Lista jest wczytywana przy uruchamianiu się Shorewalla, po jej ewentualnym uzupełnieniu trzeba wydać polecenie
$ sudo shorewall refresh
by została wczytana ponownie.
O tym, co się dzieje z blokowanymi adresami, decyduje dyrektywa
BLACKLIST_DISPOSITION z /etc/shorewall/shorewall.conf (domyślną
wartością jest DROP).
Wstępna konfiguracja stałej czarnej listy
Cały mechanizm czarnej listy domyślnie nie działa, aby funkcjonował,
trzeba dodać opcję blacklist dla odpowiedniego interfejsu. W moim
wypadku musiałem napisać w pliku /etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS - eth0 detect tcpflags,nosmurfs,logmartians,routefilter,blacklist #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
oraz w pliku /etc/shorewall/hosts:
#ZONE HOST(S) OPTIONS net eth0:0.0.0.0/0 blacklist dom eth0:211.66.49.193 # ...
Nie mam pewności, czemu musiałem podać ją także w
hosts, ale bez tego mechanizm nie działał.
Konsekwencje braku tej opcji można zauważyć uruchamiając
$ sudo shorewall compile
co kończy się ostrzeżeniem:
...
Compiling /etc/shorewall/policy...
Compiling /etc/shorewall/blacklist...
WARNING: The entries in /etc/shorewall/blacklist have been ignored because there are no 'blacklist' interfaces : /etc/shorewall/blacklist (line 6)
Compiling Kernel Route Filtering...
Compiling Martian Logging...
...
Ponadto po pierwszym aktywowaniu czarnej listy shorewalla trzeba zrestartować przez:
$ sudo shorewall restart
Po restarcie shorewalla warto też upewnić się, czy odpowiedni łańcuszek powstał. Można to zrobić poleceniem
$ sudo shorewall show blacklst
czego efektem powinno być coś w stylu (po dłuższym działaniu mamy tu przy okazji ilość i łączny rozmiar odrzuconych pakietów):
Chain blacklst (2 references)
pkts bytes target prot opt in out source destination
0 0 blacklog all -- * * 87.249.4.250 0.0.0.0/0
3 152 blacklog all -- * * 89.169.143.4 0.0.0.0/0
4 240 blacklog all -- * * 91.143.58.1 0.0.0.0/0
...
albo starym, dobrym
$ sudo iptables --list
gdzie widzimy:
Chain blacklst (2 references) target prot opt source destination blacklog all -- 014136194138.static.ctinets.com anywhere blacklog all -- 41.190.16.17 anywhere blacklog all -- 46.17.96.43 anywhere blacklog all -- 58.215.78.157 anywhere ...
Więcej informacji
Dalsze informacje są dostępne w dokumentacji shorewalla.
Dopisek
Artur Szymański zasugerował wykorzystanie drop listy firmy Spamhaus. Jest to nietrudne,
wystarczy pobrać odpowiednią listę i po niewielkiej edycji (nawet nie trzeba oskryptawiać, wystarczy zamienić średniki na sekwencje - - #) wkleić ją do pliku blacklist. Przykładowy fragment /etc/shorewall/blacklist:
# Wdg. Spamhaus DROP List 4/29/11 - (c) 2011 The Spamhaus Project 109.94.212.0/22 - - # SBL84898 110.232.160.0/20 - - # SBL79387 110.44.128.0/20 - - # SBL79386 # ...
(Shorewall obsługuje standardową składnię IP/ilość bitów przy blacklistowaniu całych sieci).
W moim wypadku, faktycznie, z kilku z tych sieci miałem znaczącą ilość spamu, więc skórka warta wyprawki.
Operację przydałoby się od czasu do czasu powtórzyć.
RSS
Feedly
Email
Subskrybuj
