ANTYNET.PL – Administracja Sieci

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ść

Różne cuda dzieją się gdy klient zerwie połączenie zamiast je zamknąć.
min. pojawiają się interfejsy ppp z adresami IP, które są ponownie nadane do innego interfejsu.
Tragedii niema, PPPoE sam po czasie ubije taki interfejs. Ale po co nam taki bałagan?
Ponadto można tu pomyśleć nad DoS koncentratora, poniżej drobne rozwiązanie problemu:

del_iface=$(ip address show | grep $5 | awk ‘{print $7}’ | grep -v $PPP_IFACE)
for x in $del_iface
do
ifconfig ${x} down
done

Podobny problem:
“One session per host” w PPPoE pod Linuksem

powodzenia

Tani i wydajny koncentrator PPPoE

Zalety tego routingu nie będę tutaj opisywać, konieczność oszczędzania numerków IP zmusiła mnie do znalezienia rozwiązania na wprowadzenie rozsądnej metody dynamicznego przydziału numerów IP dla klientów.
Padło na Radius(sql)/PPPoE/OSPF.
Całość powstała w konsorcjum szyman-amon, teraz opisze tylko zagadnienie uruchomienia OSPF, reszta może kiedyś …. z mojej strony PPPoE, Radiusa zostawiam szymanowi

instalujemy pakiet quagga.

Konfiguracja ospfd.conf na maszynie 1.

hostname router
password xxx
enable password xxxyyy
log file /var/log/ospf.log
log syslog
interface eth1
router ospf
ospf router-id 172.0.0.1
network 0.0.0.0/0 area 0.0.0.0
area 0.0.0.0 authentication message-digest
line vty

Konfiguracja ospfd.conf na maszynie 2.

hostname osiedle
password xxx
enable password xxxyyy
log file /var/log/ospf.log
log syslog
interface eth0
router ospf
ospf router-id 172.0.0.100
network 0.0.0.0/0 area 0.0.0.0
area 0.0.0.0 authentication message-digest
line vty

w debianie pamiętajmy o daemons:

zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
isisd=no

Po uruchomieniu tych konfiguracji zobaczycie w logach że wszystko wstaje, stara się połączyć ale… nic z tego. Tablice routingu nieuzupełnianą się. OSPF komunikuje się multicastem dlatego też musimy załączyć obsługę multicastu.

ip link set dev ethx allmulticast on

Teraz wszystko powinno poprawnie zadziałać. Oczywiście prawdę Ci powie

route -n

na serwerze:
iperf -s

na kliencie:
iperf -c IP

Fajna kompilacja, linux z skonfigurowanym snortem oraz gotowymi statystykami ( web).

Pobranie ze strony obrazu ISO jest trudne znaczy musimy mieć czas.

polecam pobrać z mojego serwera

Insta-Snorby-0.6.0

Instalować i testować.

Kilka przydatnych poleceń i informacji:

plik startowy snorta: /usr/lib/inithooks/everyboot.d/88snortstart

aktualizacja snorby:
cd /var/www/snorby
git pull origin master
rake snorby:update

Ostatnio jesteśmy atakowani przez wiadomość e-mail zawierająca w załączniku złośliwy dokument PDF.

Dane wiadomości:

Temat: Your Order No 123456789 | Puremobile Inc. (numer 123456789 może być zmieniony)

Nadawca : PuremobileInc

Załącznik : Order_123456789.pdf (numer 123456789 może być zmieniony)

Wiadomość wytniemy w procmailu na podstawie tematu:

:0:

* ^Subject:.*Puremobile Inc

/tmp/wirus

Podczas instalacji vmware-tools w Debian 6 zobaczymy komunikat:

The path “/usr/bin/gcc”

is not valid path to the gcc binary.

Wszelkie ścieżki zostają określone jako błędne.

Rozwiązaniem jest instalacja:

apt-get install gcc-4.3 linux-headers-`uname -r` -y

powodzenie

Tranzyt w BGP

W sieci o BGP jest niemało. Jednakże opisy są jakie są…. Wie każdy kto szukał. O ile zestawienie samej sesji to średni problem o tyle informacje o tranzycie cudzego AS ( jego prefixów) są powiedziałbym bardzo skromne.

1. Zestawimy najzwyklejszą sesję z klientem. Ustawiamy filtry aby przypadkiem nie wysyłał do nas innych prefixów jak swoje. Oczywiście nie jest to konieczne a w pewnych przypadkach i wygodne jest przyjąć ścieżki od klienta.

2. Nasze filtry do dostawców mają pewnie składnię typu:

ip as-path access-list dostawca-out permit ^$

w ten sposób wysyłamy informacje tylko o naszych prefixach. Oczywiste jest że musimy poinformować naszych dostawców że tranzytujemy też inne prefixy.

3. Informujemy dostawców i inne routery BGP:

a) Dodajemy nowy filtr o składni:

ip as-path access-list dostawca-out permit ^xxxx$

gdzie xxx to AS naszego klienta.

Jeśli zgadzamy się aby klient prependował się, musimy ten filtr odpowiednio zmodyfikować.

b) w RIPE zakładamy rekord as-set:

https://www.db.ripe.net/fcgi-bin/webupdates.pl

składnia rekordu:

as-set:          AS-mojasiec

descr:           AS-mojasiec

members:         moj-as

members:         klienta-as

To zadziała w przypadku routerów automatycznie pobierających ścieżki z RIPE. Jednak niezaszkodzi e-mail do naszych dostawców z informacją jaki AS i jakie prefixy będziemy teraz tranzytować.

4. Na koniec pamiętajmy aby nasz iptables przepuszczał ruch od i z nowych prefixów.

powodzenia

Sprawa ważna, ale bardzo często zapominana, do momentu aż ktoś zacznie marudzić że coś chwilami DNS spowalnia.

Powodów może być oczywiście ogrom ale kto pamięta o systematycznym aktualizowaniu root name servers?

Więc dziś na tapetę szybka aktualizacja root serwerów w oprogramowaniu bind9.

ściągamy świeży plik definicji root serwerów  i od razu nadpisujemy dotychczasowy stary plik db.root:

wget –user=ftp –password=ftp ftp://ftp.rs.internic.net/domain/db.cache -O /etc/bind/db.root

pozostaje powiadomić bind’a o nowym pliku root.db

rndc reload

Po sprawie

powodzonka

Mamy poważny błąd w PHP.
Wystarczy metodą GET wywołać skrypt:

np. forum PHPBB.
viewforum.php?f=22250738585072011e-324

aby skutecznie zablokować serwer www.

inne formy zapisu liczby:
0.22250738585072011e-307
22.250738585072011e-309
2.2250738585072011e-308

Powodem problemu jest funkcja zend_strtod.

Jak się zabezpieczyć?

Można na początku każdego skryptu dodać:
if (strpos(str_replace(’.', ”, serialize($GLOBALS)), ‘22250738585072011′)!==false) die();

Lub co jest znacznie prostsze wykorzystać mod_security:
SecRule QUERY_STRING “\d+e\-\d+” “phase:2,deny,status:404″

Można także zastosować mechanizmy apache:

<LocationMatch “.*\d+e\-\d+.*>
deny from all
</LocationMatch>

Od tej chwili nie jesteśmy już podatni na ten atak DoS.