ANTYNET.PL – Administracja Sieci

Problemy z ruchem DNS

Przed chwilą miałem sytuację, która wcześniej czy później spotka każdego admina. Mianowicie bardzo długi czas oczekiwania na rozwiązywanie nazw, wiec do dzieła.

1. Obciążenie serwera, może coś męczy mój serwer ( np. flood) i brakuje mu czasu na odpowiedzi DNS.
- named zabiera 90% czasu procesora, mamy winowajce.
2. Czas sprawdzić dlaczego. Pierwsza myśl to jakiś flood z zawirusowanej maszyny, lub próba zatrucia itp itd. W każdym razie należy sprawdzić co się dzieje.
apt-get install dnstop
dnstop -s eth0
eth0 – karta na której wpada ruch dns.

no proszę, jak ładnie można znaleźć winowajcę:
***********************
1 new queries, 374 total queries Wed Dec 27 16:55:16 2006
Sources count %
—————- ——— ——
xx.xx.23.229 141 37.7
xx.xx.24.61 24 6.4
xx.xx.18.101 9 2.4
Oczywiście ten log juz jest po floodzie, a raczej po wycięciu klienta.
Jednakże wartości count oraz %, bardzo dokładnie pokazują który host przeciąża nam serwer DNS.
Dalsza analiza pokazała iż głównie pytania były o rekordy MX, tak więc na 100% miałem do czynienia z wirusem rozsyłającym spam.
Klient widzi planszę z info o wirusie, admin ma czas na piwko.

Sender Policy Framework (SPF) to niekomercyjny projekt mający na celu wprowadzenie zabezpieczenia serwerów SMTP przed przyjmowaniem poczty z niedozwolonych źródeł. Ma to pozytywnie wpłynąć na ograniczenie ilości spamu oraz zmniejszenie ilości rozsyłających się wirusów.

Konfiguracja postfixa do współpracy z SPF pewnie niedługo się pojawi na tej stronie, na razie przedstawię jak skonfigurować nasz serwer DNS Bind aby inne serwery pocztowe mogły sprawdzić czy poczta przyszła z prawdziwego serwera.
Zabezpieczy to nas przed podszywaniem się wirusów pod naszą domenę.
Oczywiście zakładając, iż zdalny serwer pocztowy sprawdza wpis SPF dla przesyłek pocztowych.

W pliku strefy naszej domeny dodajemy wpis:

antynet.pl. TXT “v=spf1 ip4:xxx.xxx.xxx.xxx ip4:xxx.xxx.xxx.xxx -all”

xxx.xxx.xxx.xxx – adres(y) naszych serwerów smtp
Prawdopodobnie w większości konfiguracji będzie to jeden IP

Postfix – walczymy ze spamem

Większość spamu jaki dociera do naszych skrzynek pocztowych jest wysyłana przez ogromne sieci komputerów zombie, pracujących pod kontrolą cudownego Windows XP.

Są to zawirusowane komputery z własnymi silnikami SMTP, silniki te są zwykle napisane w możliwie najprostszy sposób, bez obsługi błędów.
Błędnie się przedstawiają, starają się podszyć pod istniejące serwery pocztowe itp. To będzie teraz nasza broń, dodamy do postfixa kilka regułek pozwalających wykryć tego typu śmieci i usunąć je zanim zostaną dostarczone do naszego systemu.

Zajmiemy się konfiguracją pliku:

/etc/postfix/main.cf

w sekcji:
smtpd_recipient_restrictions

dodajemy:

reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_hostname,
reject_unverified_recipient,

Na tym etapie z całą pewnością spora część poczty z windzianych botnetów zostanie odrzucona.

wpis:
reject_unknown_client,

Ten wpis odrzuci połączenia z serwerów nie posiadających RevDns, jest bardzo skuteczny na sporą część spamu, jednakże wciąż istnieją serwery pocztowe bez wpisu Rev. Ja osobiści daruje sobie tę metodę, przynajmniej na razie, ale pewnie tylko do czasu gdy moje obecne metody antyspamowe będą działać należycie.

HASHLIMIT

1) iptables -A FORWARD -p tcp –dport 3000 -m hashlimit –hashlimit 3/minute –hashlimit-burst 2 \
–hashlimit-name dupa –hashlimit-mode dstip –hashlimit-htable-expire 60000 -j ACCEPT
2) iptables -A FORWARD -p tcp –dport 3000 -j DROP

1) Podobno ma działać jak LIMIT tylko rozszerzony o reguły dstip,srcip,dstport,srcport (nie zachodzi konieczność pisania regułki dla każdego hosta w sieci),z tego co na razie widzę to –hashlimit-burst w rzeczywistości zawsze jest większy o 1 niż zadeklarowaliśmy, poza tym algorytm czasowy działa tak jak w LIMIT z tym wyjątkiem iż jeżeli w regule jest parametr np.: 3/minute to należy dopisać do reguły –hashlimit-htable-expire 40000 co oznacza 40000 milisekund czyli dokładnie 40 sekund, jezeli tego brak to tablica ipt_hashlimit/dupa zostaje czyszczona automatycznie po defaultowym czasie 1000 ms i wszystko się p……., ten czas wyliczyłem z iloczynu –hashlimit-burst i przedziału czasowego –hashlimit wynoszącego 20000 ms, chociaż jeżeli jednostką w –hashlimit jest sec to można pozostawić tę wartość default

–hashlimit x/sec,minute,hour,day określa przedział czasowy pomiędzy seriami
–hashlimit-burst x określa ilość pakietów w pierwszej serii tzw.token bucket
–hashlimit-mode dstip,srcip,dstport,srcport wiadomo ale można wpisywać kilka wartośći po przecinkach
–hashlimit-htable-size x maksymalna liczba “bucket” czyli jeżeli reguła jest połączona z dstip,dstport to znaczy że max może być otwarte x portów w tym samym czasie
–hashlimit-htable-max max ilość wpisów w tablicy o nazwie określonej w –hashlimit-name
–hashlimit-htable-expire = (–hashlimit) * (–hashlimit-burst) czas trwania wpisów w tablicy omówione wyżej
–hashlimit-htable-gcinterval x znalazłem taki opis w iptables tutorial:
How often should the garbage collection function be run. Generally speaking this value should be lower than the expire value. The value is measured in milliseconds. If it is set too low it will be taking up unnecessary system resources and processing power, but if it is too high it can leave unused token buckets lying around for too long and leaving other connections impossible.

RECENT

1) iptables -A FORWARD -m recent –name dupa –update –seconds 30 –hitcount 3 -j DROP
2) iptables -A FORWARD -p tcp –dport 3000 -m recent –name –set

1) określone pakiety oznaczone “dupa” uaktualniaj od ostatniego, zwracaj uwagę tylko na te które przyszły w trójkę w przedziale 30 sekund a na wszystkich pozostałych wykonaj regułę DROP
2) ustaw określonym pakietom nazwę “dupa”

–hitcount sprawdza określoną liczbę trafionych pakietów w okresie czasu –seconds
–set dodaje pakiet żródłowy do listy, jeżeli jest na liście to robi jego update
–rcheck sprawdza czy pojawił się pakiet o określonej nazwie w ciągu sekund określonych parametrem –seconds, jeżeli przykładowo leci 10 pakietów to zapisuje czas pierwszego złapanego i jeżeli pojawią się następne to ten z nich, który pojawił się po czasie –seconds znowu przechodzi
–update działa inaczej niż –rcheck ponieważ zapisuje czas ostatniego złapanego pakietu i dopiero musi upłynąć czas –seconds bez transmisji jakichkolwiek wskazanych pakietów aby mogły przejść
–rsource,–rdest aby nie pisać reguł dla każdego usera można znaczyć je po źródle lub przeznaczeniu
parametry –set –rcheck –update –remove mogą się pojawić tylko pojedynczo w regule iptables

LIMIT

1) iptables -A FORWARD -p tcp –dport 3000 -m limit –limit 3/minute –limit-burst 4 -j ACCEPT
2) iptables -A FORWARD -p tcp –dport 3000 -j DROP

1) Gdy wskazany pakiet wystąpi pierwszy raz to wykonaj regułę ACCEPT na czterech pakietach, następnie czekaj przez czas określony współczynnnikiem 3/minute tzn. 20 sekund i wykonaj regułę ACCEPT na jednym pakiecie, ale jeśli po 20 sekundach nie pojawi się żaden wskazany pakiet a pojawi się dopiero po 40 sekundach od pierwszych trzech to zastosuj regułę do dwóch pakietów, ale jeśli ani po 20 ani po 40 nie pojawi się żaden wskazany pakiet a pojawi się dopiero po 60 sekundach od pierwszych trzech to zastosuj regułę do trzech pakietów itd.
Jak pisze Bromirski, każde 20 sekund które minie bez pakietu, który pasowałby do tej reguły, spowoduje odnowienie jednego numeru z serii, jeśli żaden pakiet nie będzie pasował do reguły w ciągu 80 sekund, seria zostanie w pełni odnowiona do 4 sztuk tak jak zaczęliśmy.

IIII <—- 20s —-> I
IIII <—- 20s —-> <—- 20s —-> II
IIII <—- 20s —-> <—- 20s —-> <—- 20s —-> III
IIII <—- 20s —-> <—- 20s —-> <—- 20s —-> <—- 20s —-> IIII

–limit x/second,minute,hour,day określa przedział czasowy pomiędzy seriami
–limit-burst x określa ilość pakietów w pierwszej serii

BIND – Podstawy Bezpieczeństwa

BIND (Berkeley Internet Name Domain, poprzednio: Berkeley Internet Name Daemon) jest popularnym serwerem (demonem) DNS. Został on stworzony przez Paula Vixie w roku 1988 podczas jego pracy w DEC. BIND jest jednym z najpopularniejszych serwerów DNS wykorzystywanym w systemach Linux i Unix. BIND stanowi niezmiernie ważny składnik zapewniający poprawne działanie sytemu nazw w Internecie. Wielu użytkowników globalnej sieci bezwiednie korzysta z serwera BIND, kiedy ich przeglądarka WWW odpytuje go o adres IP komputera udostępniającego interesującą ich stronę.

Skanując sieć internetową można bardzo szybko zauważyć, iż znakomita większość serwerów DNS jest po prostu zainstalowana i skonfigurowana do obsługi jakieś domeny lub domen.
Zadając tym serwerom pytanie o dowolna domenę zaraz nam odpowie, czyli pełne open for all, zwykle nawet pozwalają na transfer całej swojej strefy. Chyba nie muszę tłumaczyć iż to nie jest najbezpieczniejszy pomysł, nasz serwer powinien:

Każdemu odpowiedzieć na pytanie TYLKO o obsługiwane przez siebie domeny,
pozwolić transferować swoje domeny TYLKO swoim serwerom podrzędnym,
odpowiadać na każde zapytanie TYLKO obsługiwanym przez siebie siecią. (klientom)

Teraz opiszę jak osiągnąć to w Bind v8.
całość polega na edycji pliku /etc/bind/named.conf (Debian GNU/Linux)

Określamy kto może nas pytać o dowolną domenę:

acl “swoi” { 127.0.0.1/8; 192.168.0.0/24; };
options {
directory “/var/cache/bind”;
allow-query {”swoi”;};
};

Teraz określimy, kto może transferować naszą domenę oraz kto może pytać o naszą domenę:

zone “antynet.pl” {
type master;
file “/etc/bind/antynet.pl”;
notify yes;
allow-transfer { ip_sec_dns1; ip_sec_dns2; };
allow-query { 0.0.0.0/0;};
};

allow-transfer są to serwery które mogą transferować od nas strefę antynet.pl, w celu jej dalszego rozgłaszania.

allow-query określa kto może pytać o naszą domenę. Oczywiście że wszyscy, tak więc wpisujemy 0.0.0.0/0

Tych kilka prostych zabiegów znacznie poprawi stopień bezpieczeństwa naszego serwera DNS.
Teraz śledzimy logi i patrzymy ile dziwnych sieci stara się o uzyskanie odpowiedzi z naszego serwera. Ciekawe w jakim celu? :>

Logowanie użytkowników

Pomijając aspekty prawne niezwykle przydatne jest logowanie ruchu użytkowników, o zaletach posiadania takich logów nie muszę chyba nikogo przekonywać.

Oczywiste jest że logowanie wszystkich pakietów jakie generują komputery naszych użytkowników jest mało możliwe, przynajmniej ze względu pojemności dysków twardych.
Dlatego też zajmiemy się logowaniem tylko i wyłącznie nowych połączeń.

Oto najprostsza metoda:

$fw -t nat -A PREROUTING -i eth1 -p tcp -j LOG -m state –state NEW –log-level 7 –log-prefix “Logowanie userow ”

Karta eth1 to oczywiście karta wewnętrzna naszej sieci.

Teraz w logach pojawiają się nam wpisy z prefixem „Logowanie userow”, co z nimi zrobimy zależy od fantazji admina. Ze swojej strony życzę aby jak najrzadziej udostępniać je smutnym panom.

Często stajemy przed zadaniem policzenia ilości aktywnych użytkowników w sieci lub stopnia wykorzystania adresów IP.
Nic prostszego, z pomocą przychodzi nam hashlimit:

#liczymy maszyny

iptables -A PREROUTING -i eth1 -t mangle -m hashlimit \
–hashlimit 1/min \
–hashlimit-mode srcip \
–hashlimit-burst 1 \
–hashlimit-name “ip_count” \
–hashlimit-htable-size 10000 \
–hashlimit-htable-max 10000 \
–hashlimit-htable-expire 60000 \
-j MARK –set-mark 5555

Oczywiście karta eth1 to karta wewnętrzna naszej sieci, nie liczymy tego co do nas przychodzi tylko to co wychodzi z naszej sieci.

Ok, super. Teraz jak odczytać ilość użytkowników?

Tak:
wc -l /proc/net/ipt_hashlimit/ip_count | awk ‘{print $1}’

Dalej już mrtg, rdd lub co kto lubi.

Walka z wirusami.
Iptables można zaprząc do pomocy w walce z wirusami typu saser/blaster oraz wirusami spamującymi.
Oto rozwiązanie jakie mam uruchomione w swoich sieciach, jak na razie sprawdza się całkiem przyzwoicie.
$fw -N worms
$fw -A FORWARD -j worms
$fw -A worms -i \! eth0 -p tcp -m tcp –dport 445 -m recent –set –name saser –rsource
$fw -A worms -i \! eth0 -m recent –rcheck –seconds 10 –hitcount 20 –name saser –rsource -j LOG
$fw -t nat -A PREROUTING -p tcp -m recent –rcheck –seconds 10 –name saser –rsource -j DROP
$fw -A worms -i \! eth0 -p tcp -m tcp –dport 135 -m recent –set –name blaster –rsource
$fw -A worms -i \! eth0 -m recent –rcheck –seconds 10 –hitcount 20 –name blaster –rsource -j LOG
$fw -t nat -A PREROUTING -p tcp -m recent –rcheck –seconds 10 –name blaster –rsource -j DROP
$fw -A worms -i \! eth0 -p tcp -m tcp –dport 139 -m recent –set –name blaster_2 –rsource
$fw -A worms -i \! eth0 -m recent –rcheck –seconds 10 –hitcount 20 –name blaster_2 –rsource -j LOG
$fw -t nat -A PREROUTING -p tcp -m recent –rcheck –seconds 10 –name blaster_2 –rsource -j DROP
$fw -A worms -i \! eth0 -p tcp -m tcp –dport 25 –syn -m recent –set –name spam –rsource
$fw -A worms -i \! eth0 -m recent –rcheck –seconds 10 –hitcount 20 –name spam –rsource -j LOG
$fw -t nat -A PREROUTING -p tcp -m recent –rcheck –seconds 10 –name spam –rsource -j DROP
W swoich zaporach nie mam celu LOG, za wiele tego, nawet z limitem na log, taki to urok z sieciami po parę tys. użytkowników.
Jednakże na początek proponuje z celem LOG uruchomiæ aby sprawdzić poprawność działania regułek.
Z blokadą na spam proszę ostrożnie, jest zbyt restrykcyjna dla niektórych klientów, a przy okazji wycina delikwentów korzystających z portu 25 do niecnych celów.
W każdym razie ten zestaw całkiem miło sprząta ruch w sieci.