Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Schemat sieci:
LAN-----------------------eth0 server eth1 --------------modem ------------ świat
(192.168.1.0/24) 192.168.1.254 masquarade 192.168.15.44 192.168.15.66
Mam usera (192.168.1.52) który po odpaleniu iptraf generuje mi ruch na serwerze na eth1. jest to o tyle dziwne, że oprócz modemu nie powinno tam być żadnego ruchu, a na pewno nie z przed masquarady. Jest to chyba jakieś p2p bo przelatuje tysiące pakietów udp. Jak zablokować takiego delikwenta bez blokowania mu netu? Tylko on mi generuje ten ruch :(
Offline
Zablokuj gościowi wszystko co idzie od niego na port inny niż 80 i z czasem się nauczy :P albo daj mu connlimit na 50, sposobów jest wiele
Offline
Chce go zablokować tylko na eth1. Nie wiem jakim cudem przeskakuje mi eth0 nie zmieniając ip na bramkowe. Na eth1 (192.168.15.44) nie powinienem widzieć żadnego ruchu z ip 192.168.1.0/24.
Ostatnio edytowany przez Marek_boss (2009-07-07 09:46:50)
Offline
Moze na poczatek tcpdump aby zlapac troche danych testowych. Pozniej na tej podstawie werywikowac konfiguracje firewalla, pewnie masz gdzies luke, bo to nie powinno miec miejsca.
Jak juz rozwiazesz problem to napisz co i jak bo ciekawe to jest.
Offline
Dane to mogą być potrzebne ale do tego żeby zobaczyć jakie dane idą i w czym dokładnie problem leży. Ja podejrzewam że gościu ma jakiegoś trojanka który lekko zmienia pakiety, a zwłaszcza jak to tylko dzieje się na UDP, poinformuj go o problemie i jak wyżej pisali załóż limit na ilość połączeń, pomaga :)
Ostatnio edytowany przez djjanek (2009-07-07 12:32:26)
Offline
Na razie dostał
iptables -A FORWARD -s 192.168.1.52 -d 192.168.15.44 -j DROP
i jest spokój :)
Ostatnio edytowany przez Marek_boss (2009-07-08 08:53:06)
Offline
Znowu wrócił:( Jak go powstrzymać?
Offline
Ograniczenie ilości połączeń powinno pomóc.
Co do layer7 - l7 chyba nie wyłapie zaszyfrowanego p2p ( np. klienty torrent umożliwiają szyfrowanie po ssl ) - jak się mylę to proszę poprawić.
Offline
Nie chodzi mi o zablokowanie p2p, tylko żebym na serwerze w iptrafie nie widział na interface wyjściowym na świat ip z LAN-u.
Offline
Jak napisalem wczesniej. TCPDUMP + weryfikacja konfiguracji firewalla...
P2P teraz sa dosc sprytne i bez poprawnej konfiguracji ciezko z nimi walczyc. Nieraz modyfikuja odpowiednio pakiety, zmieniaja im flagi, wszystko po to aby przejsc przez standartowe ustawienia firewalli i ograniczenia transferu.
Offline
z tcp dump na eth1 dostaje:
13:43:27.987871 IP (tos 0x0, ttl 118, id 46614, offset 1480, flags [+], proto: UDP (17), length: 1500) cfsdgszow.pl > 192.168.1.52: udp 13:43:27.988371 IP (tos 0x0, ttl 118, id 46614, offset 2960, flags [+], proto: UDP (17), length: 1500) sfdgk.sobifgzow.pl > 192.168.1.52: udp 13:43:27.988871 IP (tos 0x0, ttl 118, id 46614, offset 4440, flags [+], proto: UDP (17), length: 1500) sdfgk.sobifgzow.pl > 192.168.1.52: udp 13:43:27.989371 IP (tos 0x0, ttl 118, id 46614, offset 5920, flags [+], proto: UDP (17), length: 1500) fdsgk.sobifgssfg.pl > 192.168.1.52: udp 13:43:27.989621 IP (tos 0x0, ttl 118, id 46614, offset 7400, flags [none], proto: UDP (17), length: 879) sfgfgsdfow.pl > 192.168.1.52: udp 13:43:27.991369 IP (tos 0x0, ttl 122, id 18993, offset 1480, flags [+], proto: UDP (17), length: 1500) afdsg.nesfdgtpnet.pl > 192.168.1.52: udp 13:43:27.992119 IP (tos 0x0, ttl 122, id 18993, offset 2960, flags [+], proto: UDP (17), length: 1500) arsfdg.nesfdgadsl.tpnet.pl > 192.168.1.52: udp 13:43:27.992369 IP (tos 0x0, ttl 122, id 18993, offset 4440, flags [+], proto: UDP (17), length: 1500) aresfdg8.neosfdgdsl.tpnet.pl > 192.168.1.52: udp 13:43:27.992868 IP (tos 0x0, ttl 122, id 18993, offset 5920, flags [+], proto: UDP (17), length: 1500) aresg8.nesdfgsl.tpnet.pl > 192.168.1.52: udp 13:43:27.992874 IP (tos 0x0, ttl 122, id 18993, offset 7400, flags [none], proto: UDP (17), length: 879) aresfg8.nesfdgadsl.tpnet.pl > 192.168.1.52: udp 13:43:28.000114 IP (tos 0x0, ttl 122, id 64317, offset 1480, flags [+], proto: UDP (17), length: 1500) acsfdg5.nesfdgdsl.tpnet.pl > 192.168.1.52: udp 13:43:28.000614 IP (tos 0x0, ttl 122, id 64317, offset 2960, flags [+], proto: UDP (17), length: 1500) adsfg5.nesdfgdsl.tpnet.pl > 192.168.1.52: udp 13:43:28.001364 IP (tos 0x0, ttl 122, id 64317, offset 4440, flags [+], proto: UDP (17), length: 1500) acsfdg5.nesfdgsl.tpnet.pl > 192.168.1.52: udp 13:43:47.233503 IP (tos 0x0, ttl 122, id 482, offset 1480, flags [+], proto: UDP (17), length: 1500) aabtgs.nsfdgdsl.tpnet.pl > 192.168.1.52: udp 13:43:47.234002 IP (tos 0x0, ttl 122, id 482, offset 2960, flags [+], proto: UDP (17), length: 1500) aafsdg6.nsdfgsl.tpnet.pl > 192.168.1.52: udp
jak go zablokować?
Ostatnio edytowany przez Marek_boss (2009-08-07 13:56:46)
Offline
Z tego co widac z internetu przychodza pakiety z adresem lokalnym z Twojej sieci - to jest normalne.
W wiekszosci przypadkow dropuje sie wszystko co przychodzi na WAN z adresem z sieci lokalnej.
Zbadaj jeszcze czy na eth1 (WAN) wychodza pakiety z adresem lokalnym uzytkownika z sieci lokalnej (to juz nie powinno miec miejsca bo masz NAT).
Offline
Tylko przychodzą. A jaką regułką można to skutecznie zablokować?
Generalnie nie chce na eth1 żadnych pakietów ani z ani do usera z jego wewnętrznym adresem. Wcześniej tak miałem, że na eth1 miałem tylko ruch z MODEMU i z ETH1. Teraz pokazują mie się ine adresy zza natu i mnie to denerwuje :(
Offline
Moze takie cos:
iptables -I INPUT -p ALL -i eth1 -d 192.168.0.0/24 -j DROP
Ostatnio edytowany przez tbird (2009-08-08 11:06:22)
Offline
gielo: routery dzialaj w l3 i najlepiej zeby tam pozostaly, a babranie sie w analize jeszcze l7 jest malo ze pozerajace zasoby tak i procesora jak i pamieci to jeszcze troche infiltrujace uzytkownikow. Latwiej jest przemyslec wszystkie widelki i ruch nieklasyfikowany wrzucac do najnizszego przedzialu (w tym w koncu i ruch p2p sie zawiera).
Co do blokowania na WAN, to dropowac wszelki ruch z sieci opisanych w RFC 1918, czyli 10/8, 172.16/12 i 192.168/16, a wiec adresacji prywatnej, no chyba ze interfejs WAN tez jest w puli prywatnych adresow.
Ostatnio edytowany przez qluk (2009-08-08 15:03:34)
Offline
W pierwszym poście jest schemat :)
Offline
Aby sklasyfikować ruch to trzeba go jakoś oznakować. Samo iptables niestety nie jest takie mądre i nie wie co pochodzi z p2p a co np. ze strony www. Można bawić się w podział na usługi po nr portów przypisując im odpowiedni priorytet ale w dzisiejszej dobie nic to nie da jako że internetowy syf z windowsa jak wirusy, trojany i inne g..o oraz programy p2p sobie z tym radzą bez problemu, chyba już nikogo nie dziwi p2p czy robal wykorzystujący port 80, 21, 22 czy inny powszechnie wykorzystywany więc potrzeba czegoś co rozpoznaje takie śmieci po nagłówkach a do tego właśnie służy layer7 czy też ipp2p. Layer7 pozwala na dużo więcej niż tylko znakowanie p2p. Jest to tylko jeden z filtrów jaki sam wykorzystuje w sieciach jakimi zarządzam i sprawdza się znakomicie.
Co do obciązeń to router sam w sobie nie generuje większego obciązenia i dodanie kilku dodatkowych zestawów filtrów w niczym mu nie przeszkadza. U mnie na serwerach z l7 i innymi gadżetami load jest na poziomie 0.0-0.2 Zużycie pamięci jest także bardzo małe. W sumie najwięcej zasobów pochłania lms i jego demon ale to już inna bajka
Ostatnio edytowany przez gielo (2009-08-09 19:35:20)
Offline
Ja nie widze zastosowania dla L7. Uzywanie tego czegos na serwerze/routerze to tylko proszenie sie o klopoty.
L7 to tylko analizowanie pakietow za pomoca wyrazen regularnych - co jest bardzo wolne.
Oczywiscie jak przez serwer przelatuje np. 1000pakietow na sekunde to wiekszego obciazenia nie zobaczymy, jednak wystarczy jakis trojan czy zle zkonfigurowany P2P i bedzie tego znacznie wiecej i co wtedy? obciazenie procka idzie do 100%, pakiety dostaja opoznienie bo L7 sie nie moze wyrobic na czas. Caly podzial lacza per user czy per usluga sie rozjezdza i przestaje miec sens.
Dodatkowo dzisiejsze programy P2P uzywaja czesto szyfrowania i L7 na nic sie nie przydaje.
Bawilem sie tym kiedys i nie polecam.
Offline
Marek_boss co mogę Ci doradzić
1. sprawa DROPOWANIE usera nie pomoże
2. Tworząc reguły ustaw politykę dla INPUT FORWARD na drop
pisząc reguły iptables dla MASQ SNAT/DNAT FORWADDU uzywaj notacji bezwzględnych mianowicie np:
iptables -A FORWARD -i eth0 -o eth1 -s ........
3. Zastosuj limitowanie ilości połączeń VIA user
NIE ma sensu korzystać z analizatorów ruchu takich jak ipp2p L7 (obciążenie procka wzrośnie a ich skuteczność jest dyskusyjna)
Kolejny problem zacznie CI się jak ten user wejdzie na 2 stopień wtajemniczenia i zacznie zmieniać mac/IP :]
i tutaj proponowałabym wprowadzenie następującego rozwiązania połączenia tunelowe... PtP np przy użyciu PPPoE postawić koncentrator każdy z uzytkowników ma login hasło i wiadomo co się dzieje nie ma żadnych kombinacji ;]
Offline