Problem z bezpieczeństwe

[amdfanatyk]

2005-09-07 01:43:46 bojleros napisał:

> 2005-09-07 00:03:39 amdfanatyk napisał:
 >
 > > 2005-09-06 22:53:54 bojleros napisał:
 >  >
 >  > > 2005-09-06 13:22:48 amdfanatyk napisał:
 >  >  >
 >  >  >
 >  >  >  > #zastap ppp0 swoim interfejsem
 >  >  >  > current_ip="`ip addr show ppp0 | grep 'inet' | awk '{print $2}'`"
 >  >  >  > echo $current_ip
 >  >  >  > /sbin/iptables -A INPUT -i ppp0 -s $current_ip -j LOG --log-prefix 'FROM LAND
 > '
 >  >  >  > /sbin/iptables -A INPUT -i ppp0 -s $current_ip -j DROP
 >  >  >
 >  >  > Te dwie linie mają bład . Powinno być -d $current_ip o ile wogóle to jest tu
 > konieczne.
 >  > Takie
 >  >  > rozwiązanie powoduje konieczność startowania pliku firewalla po każdej zmianie ip
 > (np
 >  > jezeli
 >  >  > masz neo ) .
 >  >  >
 >  >  >
 >  > czlowieku ty musisz gwaltownie poglebic swoja wiedze na temat rodzajow atakow na system a
 > w
 >  > szczegolnosci na czym polega land, co myslisz ze co, mam wyciac wszystkie pakiety, ktore
 > do
 >  > mnie ida? na moje ip, tak? jak piles, to nie pisz na forum!
 >  >
 >
 >
 > Ale w łańcuchu INPUT -s (source adress) i adres z twojego ip ??
 > Czyli na wejściu masz na swoim interfejsie pakiet  ze swoim adresem zródłowym ,

Ciekawym atakiem jest Land. Polega na tym, ze pakiet ACK z identycznym IP zrodlowym jak i docelowym (oba wskazuja na atakowany system) zostaje wyslany do ofiary. Atakowany system odbiera taki pakiet i wysyla SYN/ACK do adresu zrodlowego - czyli sam do siebie i wpada w petle. Problemem sa tu numery sekwencji, atakowany komputer oczekuje numeru sekwencji "o jeden wiekszego" od tego ktory wysyla (normalnie maszyna z drugiej strony powieksza go o jeden), kiedy ten sie nie zmienia wysyla pakiet ACK z prosba o poprawienie numeru sekwencji i znow oczekuje na  naprawiony pakiet. Dostaje jednak taki sam pakiet spowrotem - w efekcie koncowym wpada w bledne kolo, co w efekcie powoduje blokade stosu TCP.

zrodlo: http://www.cc-team.org/index.php?name=artykuly&show=69

  Z tego co
 > wiem to wiekszość systemów jest odporna na pakiety z adresem źródłowym takim smym jak ich ip.

Kilka lat temu na atak podatna była większość systemów operacyjnych włącznie z Windows, Cisco, NetBSD, FreeBSD itp. Microsoft opublikował łatające tę dziurę poprawki dla Windows 98. Internauta o pseudonimie Dejan Levaja przetestował pod tym kątem najnowsze systemy z rodziny Windows. Okazało się, że w przypadku Windows XP SP2 zużycie procesora wzrasta do 100% w ciągu kilkudziesięciu sekund po odebraniu każdego pakietu.

jesli w takich automatach problem jest to nie licze nawet, ze w unix'ach go nie ma, bo niby co mialoby odrzucac te pakiety?

 > Co do drugiej linijki przyznaje sie do błedu polegajacego na tym ze jej najzwyklej
 > niedoczytałem -j DROP , co i tak nie daje ci powodu do obrazania mnie na forum. W takim
 > momencie cywilizowany człowiek podejmuje dyskusje a nie obrzuca drugiego chmaskimi obelgami.

dopiero moge cie z blotem zmieszac jak mi sie wetniesz ponownie z takimi zbdurami :]

 > BTW ... Nie popieram pisania błednych wypowiedzi ale każdemu pomyłki sie zdarzają. Pociesz się
 > tym ze przy wyjaśnianiu tego rodzaju błędów używasz o wiele większej liczby argumentów niż przy
 > odpowiedzi na zwykłe posty. To daje korzyść w treści dla forum w przeciwieństwie do tego co
 > zaprezentowałeś :/

za to co sam zaprezentowales przyprawilo mnie o atak smiechu.

 >
 > Pozdrawiam !!
 >

a ja nie.

[amdfanatyk]

tcp 0 0 195.116.242.*:80 202.104.237.6:1627 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:2918 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:3526 SYN_RECV
tcp 0 0 195.116.242.*:80 24.127.169.163:3885 SYN_RECV
tcp 0 0 195.116.242.*:80 218.76.65.2:4040 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:3558 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:1741 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:1128 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:1845 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:2741 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:1045 SYN_RECV
tcp 0 0 195.116.242.*:80 151.198.154.213:3455 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:2628 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:2789 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:1482 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:3670 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:4899 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:3206 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:3973 SYN_RECV
tcp 0 0 195.116.242.*:80 202.104.237.6:3615 SYN_RECV

cos mi to wyglada na syn-flood zapomnialem napisac, ze przed syn-floodem mozna takze zabezpieczyc sie na poziomie samiego kernela - syn-cookies, wyedytuj .config i sprawdz, czy masz taka linie:

CONFIG_SYN_COOKIES=y

ograniczyles tez ilosc otwartych sesji spod tego samego ip??

nie wiem, czy bedzie Ci dzialac ten anty-land poniewaz jak komputer dziala w sieci to pewnie ma inne ip niz ten, co jest przez niego wyjscie realizowane ale jak to tam jest to do konca nie wiem krotko mowiac sprawdz, czy w logach iptables ip docelowe to na pewno ip Twojej maszyny.

a teraz kolejne reguly, dodalem blokowanie syfiastych zakresow - moze pomoze :/

#!/bin/sh

#generated by ipt-qt-conf 1.3.2
#report bugs and wishes to amdfanatyk: amdfanatyk (at) wp (dot) pl

/sbin/iptables -F INPUT
/sbin/iptables -F OUTPUT
/sbin/iptables -F FORWARD

/sbin/iptables -Z INPUT
/sbin/iptables -Z OUTPUT
/sbin/iptables -Z FORWARD

/sbin/iptables -P INPUT DROP
/sbin/iptables -P OUTPUT ACCEPT
/sbin/iptables -P FORWARD DROP

/sbin/iptables -X syn
/sbin/iptables -X echorequest

/sbin/iptables -N syn
/sbin/iptables -N echorequest

#zastap ppp0 swoim interfejsem
current_ip="`ip addr show ppp0 | grep 'inet' | awk '{print $2}'`"
echo $current_ip
/sbin/iptables -A INPUT -i ppp0 -s $current_ip -j LOG --log-prefix 'FROM LAND '
/sbin/iptables -A INPUT -i ppp0 -s $current_ip -j DROP

/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

/sbin/iptables -A INPUT -s 10.0.0.0/8 -j DROP # klasa A
/sbin/iptables -A INPUT -s 172.16.0.0/12 -j DROP # klasa B
#/sbin/iptables -A INPUT -s 192.168.0.0/16 -j DROP # klasa C
/sbin/iptables -A INPUT -s 224.0.0.0/4 -j DROP # multicast
/sbin/iptables -A INPUT -s 240.0.0.0/5 -j DROP # reserved

/sbin/iptables -A INPUT -p icmp --icmp-type echo-request -j echorequest
/sbin/iptables -A echorequest -m limit --limit 1/s -j ACCEPT
/sbin/iptables -A echorequest  -j LOG --log-prefix 'FROM DOS '
/sbin/iptables -A echorequest  -j DROP

/sbin/iptables -A INPUT -p tcp --tcp-flags ! ALL SYN -m state --state NEW -j LOG --log-prefix 'FROM NOSYN '
/sbin/iptables -A INPUT -p tcp --tcp-flags ! ALL SYN -m state --state NEW -j DROP

/sbin/iptables -A INPUT -p tcp --tcp-flags ALL SYN --dport 80 -m state --state NEW -j syn
/sbin/iptables -A syn -m limit --limit 1/s -j ACCEPT
/sbin/iptables -A syn -j LOG --log-prefix 'FROM DOS '
/sbin/iptables -A syn -j DROP

/sbin/iptables -A INPUT -m limit --limit 1/s -j LOG --log-prefix 'FROM DROP '

[mapet]

Ale to jest właśnie serwer z którego to wszystko wychodzi. Do niego są podpięte wszystkie kompy i przez niego wychodzą na zewnątrz.

CONFIG_SYN_COOKIE=y

więc jest wkompilowane.

I co poradzić?

[amdfanatyk]

zaaplikuj te najnowsze reguly; tak w ogole to je zapisujesz? bo ja nie dalem tam zadnej linijki bo nie wiem czy masz iptables z rpm czy ze zrodla; jezeli rpm to daj /sbin/service iptables save;

strzelam: moze masz jakas stara wersje apacza, ktora jest bardziej podatna na takie ataki (dziwne ale tonacy brzytwy sie chwyta);

mozna jeszcze zwiekszyc czas reakcji w iptables zamieniajac 1/s na np 30/m ale mozna tez przedobrzyc bo jak bedzie duza przewaga zalewajacych pakietow, to i tak moze byc tak, ze ten co ma dobre zamiary sie nie dostanie :/

[wojtekm]

Chciałbym nieśmiało zauważyć, że cały atak jest prawdopodobnie przeprowadzany z jednego bądź conajwyżej 255 adresów. Proponował bym przyjrzeć się dokładnie z jakich adresów przychodzą połączenia (oczywiście adrsy źródłowe mogą być podmienione ale zawsze warto spróbować), poszukać ich właścicieli w bazie whois i skontaktować z nimi.
Cała podklasa 195.116.0.0/26 należy to TPSA, więc możesz się też zwrócić bezpośrednio do nich:
http://www.ripe.net/perl/whois?form_type=simple&full_query_string=&searchtext=195.116.242&do_search=Search

Wojtek

[amdfanatyk]

albo poprostu chamsko zablokowac caly zakres;

ja do wyszukiwania najbardziej agresywnych osobnikow napisalem sobie prog, ktory analizuje /var/log/messages tyle, ze algorytm nie jest zbyt szybki wiec polecam skorzystanie z niego tylko w wypadu niezbyt duzego pliku logow;

http://www.kde-apps.org/content/show.php?content=26867

[wojtekm]

2005-09-07 13:48:30 amdfanatyk napisał:

> albo poprostu chamsko zablokowac caly zakres;
 >
 > ja do wyszukiwania najbardziej agresywnych osobnikow napisalem sobie prog, ktory analizuje
 > /var/log/messages tyle, ze algorytm nie jest zbyt szybki wiec polecam skorzystanie z niego
 > tylko w wypadu niezbyt duzego pliku logow;

Tylko, że to tak naprawdę niewiele daje, bo co z tego, że nie mogą się z Tobą połączyć, jak zabierają Ci większość pasma?
Jedynym rozsądnym rozwiązaniem w takim przypadku jest odcięcie tego ruchu ma wyższym poziomie i może to zrobić tylko bezpośredni dostawca usługi lub ktoś od kogo sam dierżawi łącza.

Wojtek

[mapet]

Ale przecież adres 195.116.242.* to mój adres IP.

Oczywiście kopiuje twoje regułki iptables.
Ja nie muszę używać /sbin/iptables tylko po prostu iptables. Kopiuje i uruchamiam.

Teraz sprawdziłem taką rzecz, że zablokowałem wszystko co wychodzi z mojego serwera na 80

Czy możliwe, za wpiepszył mi sie jakiś brudas do systemu i wysyła takie informacje?

ale znowy jak wyłącze apache to też wszystko stoi.

Jak sprawdzić z jakiego albo z jakich adresów IP są te wszystkie IP?

[wojtekm]

2005-09-07 14:02:19 mapet napisał:

 > Jak sprawdzić z jakiego albo z jakich adresów IP są te wszystkie IP?

Musisz zejść na niższy poziom i porównywać pakiety z tym adresem i adresami MAC. Uruchom np. Ethereal i daj mu takie reguły aby logował tylko pakiety z adresem źródłowym z Twojego kompa. Potem przyglądnij się MAC-om i zobacz skąd tak naprawdę pochodziła każda komunikacja. Jeśli winowajca jest w Twojej sieci to na 100% powinien się znaleźć.

Wojtek

[wojtekm]

2005-09-07 14:17:25 wojtekm napisał:

 > Musisz zejść na niższy poziom i porównywać pakiety z tym adresem i adresami MAC.

Oczywiście dotyczy to tylko sieci Ethernetowych. W zależności od stosowanej warstwy łącza danych adresy sprzętowe mogą być różne, np. gdy jesteś połączony ze swoim providerem za pomocą DLS-a i PPPoA (tak jest w tepsie) to adresami łącza danych są dersy ATM-owskie. Nie mniej jednak reguła jest podobna.
Generlanie: http://pl.wikipedia.org/wiki/ISO/OSI

Wojtek

[bojleros]

amdfanatyk -  śmieszę cie ?? dobrze ze piszesz na forum a nie na privie , odrazu widać co o tobie trzeba sądzić. ze zachwujesz się jak ludzie którzy węgiel z wagonów kolejowych kradną to już na tobie sie odbije, albo może zdolności społecznych brakuje ??  weź odejdź czasem od komputera może da sie coś jeszcze nadrobić

[amdfanatyk]

2005-09-07 14:55:26 bojleros napisał:

> amdfanatyk -  śmieszę cie ?? dobrze ze piszesz na forum a nie na privie , odrazu widać co o
 > tobie trzeba sądzić. ze zachwujesz się jak ludzie którzy węgiel z wagonów kolejowych kradną to
 > już na tobie sie odbije, albo może zdolności społecznych brakuje ??  weź odejdź czasem od
 > komputera może da sie coś jeszcze nadrobić
 >

na prawde wali mni co o mnie uwazasz i inni uwazaja; takze to co sie mi odbije nie jest twoim interesem wiec sie nie wpieprzaj; sam jestes typem dupka, ktory wszedzie musi wtracic swoje 3 grosze nawet jak nie ma pojecia o temacie; na razie nie wniosles nic do tematu wiec wy*********.

[bojleros]

2005-09-07 15:41:52 amdfanatyk napisał:

> 2005-09-07 14:55:26 bojleros napisał:
 >
 > > amdfanatyk -  śmieszę cie ?? dobrze ze piszesz na forum a nie na privie , odrazu widać co
 > o
 >  > tobie trzeba sądzić. ze zachwujesz się jak ludzie którzy węgiel z wagonów kolejowych
 > kradną to
 >  > już na tobie sie odbije, albo może zdolności społecznych brakuje ??  weź odejdź czasem
 > od
 >  > komputera może da sie coś jeszcze nadrobić
 >  >
 >
 > na prawde wali mni co o mnie uwazasz i inni uwazaja; takze to co sie mi odbije nie jest twoim
 > interesem wiec sie nie wpieprzaj; sam jestes typem dupka, ktory wszedzie musi wtracic swoje 3
 > grosze nawet jak nie ma pojecia o temacie; na razie nie wniosles nic do tematu wiec
 > wy*********.

chrzań sie robaku !!

[Lorenzo]

Bolejros i amdfanatyk!!

Nie plujcie sie na forum!! Człowiek założył posta bo ma poważnego problema. Pomyślcie razem co wykombinować a nie róbcie gnoju.

---------
Oburzony na was

[mapet]

Czy już nikt nie jest w stanie mi pomóc?? ;((((((