ANTYNET.PL – Administracja Sieci

Linux w zastosowaniach profesjonalnych to bardzo tania i wygodna alternatywa.

ISP, czyli dostawcy Internetu często borykają się z granicami przepustowości routerów. Internet jest pełen opisów, tutoriali traktujących o budowie routera opartego o Linux.

Często są to bardzo dobre informacje, rzetelne i pozwalające zbudować dobrej jakości router. Jednakże zwykle  administrator trafia na problem z wydajnością, przepustowością.

Kupuje od dostawcy 400Mbps puszcza ruch a tam 250 – 300Mbps i koniec, dach na wykresach.

Powody są złożone, sprzęt (frimware np. eth) skonfigurowany optymalnie a nie wydajnie, braki w optymalizacji Firewalla.

Niekończące się linie iptables i tc, zanim pakiet trafi na swoja regułkę przeleci 2tyś innych, w tym czasie system się obciąża a pakiet czeka na wysłanie w świat. Jest wiele różnych bolączek konfiguracyjnych routera.

Doświadczenie i wiedza pozwalają rozwiązać te problemy, na maszynie

cat /proc/cpuinfo | grep "model name"
model name      : Intel(R) Pentium(R) CPU        G6950  @ 2.80GHz
model name      : Intel(R) Pentium(R) CPU        G6950  @ 2.80GHz
cat /proc/meminfo
MemTotal:        2053400 kB
MemFree:          175188 kB
lspci | grep Eth
10:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
10:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
20:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe (rev 10)
22:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe (rev 10)

Spokojnie z load 0.0 czasem 0.05 obsługiwanych jest 4tyś. abonentów, adresy prywatne a więc maskowane.

Komunikat ip_conntrack: table full

nie zaistnieje. Wszystko jest kwestią odpowiedniego przeprogramowania sprzętu oraz systemu.

Profesjonalne, niezwykle wydajne i skalowalne routery, które nie kosztują dziesiątek czy setek tysięcy złotych to nie mit.

Nie daj się wciągać w drogie „sprzętowe” rozwiązania.  Zaufaj odpowiedniej wiedzy i doświadczeniu.

Odpowiednio przygotowana maszyna może być równocześnie wydajnym i skalowalnym routerem dla tysięcy abonentów, obsługiwać BGP i OSPF do kilku operatorów oraz pracować jako koncentrator PPPoE. W takiej konfiguracji podmiana adresu mac nie pozwoli kraść Internet.

Zapraszam do kontaktu.

Wykres przepustowości z jednego z routerów Linuks:

cd /usr/src
wget https://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.38.6.tar.gz

tar xf linux-2.6.38.6.tar.gz
cd linux-2.6.38.6

pobieramy patcha IMQ

wget http://www.linuximq.net/patchs/linux-2.6.38-imq-multiqueue-test1.patch

patch -p1 <linux-2.6.38-imq-multiqueue-test1.patch

W celu ułatwienia sobie życia skopiujemy aktualne ustawienia jądra:

cp /boot/config-`uname -r` ./.config

teraz

make menuconfig

Teraz z grubej rury blokada

iptables -N apache_dos

iptables -A INPUT -p tcp –dport 80 –syn -j apache_dos

iptables -A apache_dos -m hashlimit –hashlimit 10/sec –hashlimit-burst 30 \

–hashlimit-mode srcip –hashlimit-name apache_DDOS \

–hashlimit-htable-expire 30000 \

–hashlimit-htable-max 65535 -j ACCEPT

iptables -A apache_dos -j DROP

Metoda chyba najpewniejsza i najprostsza, można zobaczyć efekty wykonując polecenie:

iptables -vL apache_dos

inspiracja – sow

Po skonfigurowaniu koncentratora PPPoE na vlan pojawił się malutki problem.
Otóż stacje z MS działały prawidłowo ale z Ubuntu już nie, pingi działały prawidłowo ale próba otwarcia strony kończyła się niepowodzeniem.
Aby było śmieszniej strony zagraniczne w większości działały, polskie… w mniejszości
Generalnie na pierwszy rzut oka jakaś magia i/lub czeski błąd w testach.

Problemem okazało się zamieszanie z MTU, koncentrator pracuje na 1472, vlan na 1500. Synchronizacja tych wartości
nie przyniosła efektów. Więc tak na 100% gdzie problem to nie wiem, niemniej jednak przypomniałem sobie że kiedyś podobny problem był ze stroną
avon.com.
Wtedy zamiast martwić się MTU starczyło zainteresować się maksymalnym rozmiarem segmentu, czyli MSS.
Manipulacja tego pola także pozwala ustalać maksymalny rozmiar pakietu.
Więc pomijając zamieszanie z MTU vlan, eth, ppp zajmiemy się konfiguracją MSS.

iptables -A FORWARD -p tcp –tcp-flags SYN,RST SYN -j TCPMSS –clamp-mss-to-pmtu

Tym sposobem system samodzielnie wyliczy odpowiednie MSS dla połączenia.
Oczywiście problem z MTU został zażegnany

Dedykowany Serwer PPPoE , wysoka wydajność

Standardowo skonfigurowany Linux, pracujący jako router w dużej sieci zaczyna się męczyć przy 250 Mbit/s. Okazało się tak na maszynie Debian / 2.80GHz / 1GB Ram / eth – 1GigE / ~800 klientów. Do tego oczywiście firewall oraz htb ( filtry mieszające ) no i BGP z dwoma operatorami. Taka maszyna w godzinach szczytu wykazywała load 1-2.5, ponadto poważnie wzrastała temperatura procesora.

Znasz ten problem?
Nasłuchałeś się o ograniczeniach transferu Linuxa?
Proponuje czytać dalej!

Jak zawsze rozwiązanie okazało się banalne, szybki tuning sysctl i nasza maszyna przy 600 Mbit/s pracuje z load 0.07
Oczywiście komfort pracy w sieci wzrasta naprawdę zauważalnie.

Więc co zrobić?

net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.netdev_max_backlog = 2500
net.ipv4.core.rmem_default = 262144
net.ipv4.core.wmem_default = 262144

net.ipv4.tcp_rmem = 4096 87380 8388608

net.ipv4.tcp_wmem = 4096 87380 8388608
net.ipv4.tcp_mem = 8388608 8388608 8388608
net.ipv4.core.rmem_max = 8388608
net.ipv4.core.wmem_max = 8388608

Warto także stuningować obsługę arp:
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

Twój Linux zatrzymał się na 250 Mbit/s to zobacz to:

W przypadku Linuxa z Quagga ( BGP ), opis tutaj to absolutna podstawa konfiguracji.
Pamiętaj też o rozsądnym zastosowaniu smp_affinity oraz wyłączeniu ( jeśli to możliwe ) modułów NAT.

powodzonka

Masz problem z samodzielnym uruchomieniem routera 1GigE opartego o Linux?
Zapraszamy do współpracy:
Usługa Instalacji Routera BGP opartego o LINUX

Bruteforce na SSH to strasznie irytująca plaga, szanse na udane włamanie są niewielkie gdy admin dba o serwer.
Jednakże wiecznie zaśmiecone logi i sam fakt … no krew zalewa.
Opisałem już wcześniej metodę opartą o haslimit, działa dobrze ale… dziś dodamy jeszcze jedno rozwiązanie.

Powstał fajny projekt, sshbl.org – (the SSH blacklist), co 15 minut tworzona jest czarna lista adresów IP z których przeprowadzane są ataki.
W prosty sposób wykorzystamy tą listę.

mkdir /etc/ssh-brute
cd /etc/ssh-brute
touch ssh.brute
chmod +x ssh.brute

w plik ssh.brute umieszczamy zawartość:

————————————————————————————————–
#!/bin/bash

PATH=”/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin”

adresy=`cat /tmp/ipki | grep [0-9] | grep -v “#”`
for x in $adresy
do
iptables -D INPUT -s $x -j DROP
done

wget http://www.sshbl.org/lists/base.txt -O /tmp/ipki

adresy=`cat /tmp/ipki | grep [0-9] | grep -v “#”`
for x in $adresy
do
iptables -I INPUT -s $x -j DROP
done
————————————————————————————————–

Teraz do crona dodamy wywołanie skryptu:
*/15 * * * * root /etc/ssh-brute/ssh.brute &>/dev/null

Powodzenia

Update:

Kilka maszyn szalało przy dodaniu kolejnych paru tysięcy wpisów w iptables. Dlatego też pomyślałem o innej metodzie blokowania listy hostów z sshbl.org.
Padło na routing.

Gotowy skrypt:
######################################

#!/bin/bash

PATH=”/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin”

rm /tmp/ipki
wget -q http://www.sshbl.org/lists/base.txt -O /tmp/ipki

adresy=`route -n | grep \!H | awk ‘{print $1}’`
for x in $adresy
do
route del -host $x reject
done

adresy=`cat /tmp/ipki | grep [0-9] | grep -v “#”`
for x in $adresy
do
route add -host $x reject
done

###########################################

Działa wyśmienicie

Optymalizacja routera opartego o system Linux

Każdy admin pewnego dnia staje przed zadaniem optymalizacji reguł iptables celem ich optymalizacji. W moim przypadku problem pojawił się w momencie przekroczenia sumarycznego ruchu (do i z rutera) 360Mb/s. W tym Momocie sumaryczna ilość pakietów wzrosła do 31.8 k./s.
Efekt był taki, iż zaczęły się chwilami gubić pakiety, ponadto czas wczytywania stron www odczuwalnie się wydłużył, pomimo faktu, iż podczas ściągania danych w sieciach p2p nadal działały bez zakłóceń. Pakiety ICMP coraz częściej wypadały i/lub rosły ich czasy, load average routera dochodził do 1,5.
W związku z tym przystąpiłem do optymalizacji regułek iptables i innych drobnych zabiegów, kilka z nich przedstawiam poniżej.

1. Na początek dochodzimy do wniosku, w jakim celu filtrować po IP źródłowym połączenia, na które klient już wcześniej dostał zezwolenie. Przecież to bezsensu! Skoro już klient wysłał pakiet SYN kontrolowany na podstawie adresu IP oraz MAC i dostał zezwolenie na połączenie, to dalsze pakiety możemy spokojnie puścić bez tej kontroli, testujemy tylko stan połączenia:

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

2. Najbardziej popularne porty puszczamy szybciutko na początku filtrowania, pozwoli to znacznie zwiększyć prędkość wczytywania danych, ktoś zapyta a co z adresami IP, które maja blokadę dostępu do Internetu? O tym później

iptables -A FORWARD -i eth1 -p tcp -m multiport –dports 25,80,110 -j ACCEPT

3. Podobna sytuacja z pakietami UDP, gry on-line oraz telefonia internetowa znacznie przyśpieszy.

iptables -A FORWARD -i eth1 -p udp -j ACCEPT

4. Zmieniamy domyślne wartości dla protokołu IPV4, po prostu przyspieszamy pewne operacje.

echo 20 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 1800 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream

5. Przy tak skonstruowanych regułach iptables klienci, którzy, powinni mieć wycięty ruch do Internetu bez problemu mogą korzystać z www oraz poczty. Chcąc ich zablokować należy regułki DROP dać na początek, w efekcie pakiet autoryzowany musi pokonać regułki blokad i dopiero trafia na swoje zezwalające na dostęp do Internetu. Powoduje to oczywiste opóźnienie. Dlatego też wycinanie klientów realizowane będzie na poziomie routingu a nie filtrowania pakietów. Kolejne tysiące pakietów nie będą musiały być filtrowane:

route add -host ip_hosta reject

Połączenia z adresu ip_hosta nawet niedotrze do regułek filtrujących, chyba nie muszę mówić jak odpocznie nasz firewall.

Parę prostych zabiegów a Internet znowu zaczął u klientów szaleć aż miło, ponadto load average z 1,5 spadło do 0,05 czego życzę i Wam

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