Forum Debian Users Gang

[quote=Nickleodeon]Czy te switche są zarządzalne czy to zwykłe "mydelniczki" ?
z czystej oszczędności to zwykłe mydelniczki - w tej chwili stoją TP-LINKI (TL-SF100BD)[/quote]
I te oszczędności zawsze kiedyś w końcu odbijają się czkawką ;)
Ale właśnie te switche od razu wydają się podejrzane na dzień dobry, oczywiście nie muszą one być całym złem ale ... ;)

[quote=Nickleodeon]Dobrze by było wyłapać skąd ten ruch udp się bierze....
żródła są różne - zarówno wewnętrzne jak i zewnętrzne ip[/quote]
A nie pojawiają się jakieś adresy multicastowe ( początek ip 224....) ?
[quote=Nickleodeon]Burze broadkastowe... kiedy mogą występować? Ja nie mam na radiu WDSów i pętle też są niemożliwe...[/quote]
O pętle chodziło mi na przełącznikach, że ramki krążą w nieskończoność, a skoro to "mydelniczki" to tam nawet nie masz Spaning tree które w jakiś sposób mogą zapobiegać pętlą , które to pętle mogą powodować burze broadcastowe. Może być taka akcja, że któryś z użytkowników podłącza jakieś urządzenie, które taki ruch "wytwarza" i przez to są takie kłopoty.
[quote=Nickleodeon]Wirus.... to może i być, ale q...wa mać musi być bardzo perfidny (czytaj przebiegły).[/quote]
Oj tego bym nigdy nie wykluczał ...
[quote=Nickleodeon]Rozmawiałem dziś z kolesiem który twierdzi, że ten opis przypomina mu ataki typu DoS. Nie jestem jednak do tej hipotez przekonany....
Na razie spróbuję wiresharka, zobaczymy....[/quote]
Bo to jest podobne działanie, pisałem o spoofingu arp, który te przełączniki może zabić, w simie dos to jest zalewanie pakietami aż nam usługa/urządzenie odmówi dostępu co w sumie się dzieje. Więc nie dziwie się że taki wniosek wysnuł kolega.
Ale nie ma co gdybać , podałem już tyle teorii, że ulala :) złapany ruch wirsharkiem czy tcpdumpem powinien naprowadzić Ciebie na właściwy kierunek co tak naprawdę się dzieje i na podstawie przechwyconego ruchu można coś konkretnie stwierdzić, tak to teraz bajamy  co to może być :)

Identyczna sytuacja była w sieci, gdzie mam neta.
Tony spoofowanych pakietów UDP, kilkanaście razy łapałem gościa i jego prawdziwy Ip przez Etherape i opieprzałem admina u ISP, aż odcięli pacjenta na czas wyczyszczenia kompa.

Najciekawsze było to, że mając neta przez ppp0,  eth0 nie ma adresu, i nawet ma wyłączone Arp'y, a i tak na tym interfejsie widywałem ruch rzędu 4 - 50 Mbit/s.
Netu w czasie takiego ataku praktycznie nie dało się używać.

Sprawdzić dokładnie kompy podłączone do sieci o routery i switche.
Kompy na okoliczność backdoora czy trojana używanego w atakach ddos, switche i routery pod kontem integralności oprogramowania.

Roboty od zajeb..., ale jak nie potrafisz wyczesać źródła ataku  snifferem, to nic innego nie pozostaje.

W zwykłym Eherape widać, ile który host wysyła danych, dzięki temu, jak ktoś sra w tempie 50 Mbit/s to miej więcej wiadomo, gdzie szukać.
W dodatku taki srajacy pakietami komp widać na dwóch adresach, jego prawdziwym adresie, i na tym spoofowanym, dwa adresy, i ten sam co do bajta transfer  w danej jednostce czasu.

Lepiej na tych mydelniczkach, o ile to możliwe, wsadź Linuxa, zrób ipsetem tablice ip:mac i tylko na podstaiwe odwzorowania tej tablicy przepuszczaj ruch, resztę uwalaj.
Odejdzie Ci przypadek, kiedy w Twojej sieci lecą spoofowane pakiety rzekomo z "onetu", a w rzeczywistości np z 192.168.5.11.

Po prostu router przy filtrowaniu ipsetem mac:ip przepuści co prawda pakiety z hosta 192.168.5.14 pod warunkiem, ze jego mac będzie się zgadzał z wpisanym w tablicy, a sam adres też będzie w tej tablicy.
Wytnij też pofragmentowany ruch UDP, dzisiaj nie ma już chyba systemu podantego na ten typ ataku (teardrop), ale taki atak świetnie się nadaje do zapychania łącza śmieciowymi pakietami.
Jak do tego zrobisz sensowne limity na ruch icmpz każdego hosta, powinna się sytuacja przejaśnić dość znacząco.

Potem zamulać mogą jeszcze sieci p2p, lub atak po tcp, ale tcp nie jest protokołem bezpołączeniowym, jak udp i icmp, dlatego dużo łatwiej go limitować i obcinać, i dlatego nie nadaje się zbytnio do atakowania serwerów internetowych.
Stąd też rzadziej stosują go trojany, których pełno krąży w sieci, czatując na każdego "super bezpiecznego" Windowsa.

Ostatnio edytowany przez Jacekalex (2013-02-02 01:50:56)

odpowiem samemu sobie - wifi na degietce nie miało wpływu na pady sieci. Było dzisiaj wyłaczone a zator miałem / jak potem wyczytałem/ 65 Mbit/s gdy upload mam max 4Mbit/s. No bajki az zaniemowiłem....

1 monitoring :P
Zainstaluj sobie na tym brzegowym MT Dude http://www.mikrotik.com/thedude
i obserwuj co się dzieje.

Tymczasowo limituj ilość połączeń tak by można było diagnozować przyczynę a pady nie były tak uciążliwe

Kolejki na miętkach mają dużą tendencje do przeciekania więc podejrzewam w dude od razu będziesz widział który to delikwent :P

Szkoda że nie masz switchy zarządzalnych bo taką zwykłą mydelniczkę bardzo łatwo jest "zapkietować"

Tutaj masz linka do "biedronki" (o ile chesz na RB robić szkielet)
http://www.ted.net.pl/product_info.php?products_id=1643
niedrogi ale do wymogów Twojej sieci wystarczy

Dość dawnotemu popełniłem tego posta na forum, z nadzieją, że ktoś pomoże mi to rozwikłać:
[quote=Nickleodeon]Witam forumowiczów po dość długiej nieobecności.
Do odezwania skłonił mnie jeden, spędzający mi sen z oczu problem jak w temacie.
Jest sobie sieć jak na schemacie poniżej (z góry przepraszam za "rysunek" - może się rozjechać):


                                                                                                                         | <== AP(2,4GHz) > | <-- 3 uzerków
                                 (100.100.100.49/29)                   (1992.168.88.0/24)            | <--> juzer03
                                            WAN                                         LAN                        | <--> juzer04
inet <==> router DGT  > | <====== MikroTik RB750 > |                                     | <--> juzer05
                                                        (router+QOS)       | <===== switch 8port > | <--> juzer06
                                                                                   | <--> juzer01                 | <--> juzer07
                                                                                   | <--> juzer02                 | <--> juzer08
                                                                                                                         | <==== switch 8port > | <-->  juzer09
                                                                                                                                                             | <-->  juzer10
                                                                                                                                                             | <-->  juzer11
                                                                                                                                                             | <-->  juzer12
                                                                                                                                                             | <-->  juzer13
                                                                                                                            | < switch 8port== >   | <-->  juzer14
                                                                                                                            | <-->  juzer15
                                                                                            | < switch 5port== > |
                                                                     juzer21  <-->   |                               | <-->  juzer16
                                                                     juzer22  <-->   |                               | <-->  juzer17
                                                                                                                            | <-->  juzer18
                                                                                                                            | <-->  juzer19
                                                                                                                            | <-->  juzer20


Łącze do ineta jest asymetryczne 40/4 MBit/s, działa przyzwoicie
DeGieTka robi za routrer brzegowy i pierwszy nat, później MieteK robi ten właściwy nat i dzieli pasmo (qos na sq+qt+L7), ma odpalony dhcp
Aperiodycznie, kilka razy w tygodniu, nieraz na dobę, bądź co kilkadziesiąt minut następuje taka sytuacja, że sieć LAN zatyka ruch rzędu 12 - 13 tys. pakietów na sekundę (sic!!!). Ogólnie pada łącze ze światem. Wtedy po IP do MietKa się nie dostanę (tylko po MACu). W logach nie ma nic niepokojącego, z monitorowania łacza wynika, że z MietKa idą pakiety udp na jakieśtam IP ("dobór" IP jest mi nieznany, niekiedy jest to zew. ip, z poza klasy adresowej LAN, innym razem jest to ip z LAN). Na tę "czkawkę" pomaga przeważnie reboot prądowy wszystkich urządzeń w LAN. Bywają sytuacje że wszystko samo wraca do normy. Początkowo myślałęm, że to nagrzebane coś przeze mnie na MietKu. Konsultowałem moje ustawienia i są poprawne. Potem przypuszczałem że może jest padnięty port/porty w swiczu/swiczach lub na MietKu. Wymieniłem na początku tego tygodnia wszystek sprzęt na fabrycznie nowy, ze sklepu i D...PA!!! sytuacja się powtarza, co prawda rzadziej, ale jednak.
Nadmienię ze swicze leżą w różnych szafkach porozrzucane po całym, 4 piętrowym bloku - od piwnicy po strych w różnych klatkach. Restart urządzeń jest szczególnie stresujący po 24 w nocy - zamknięte drzwi wejściowe do piwnicy, brak klucza itp.
Normalnie siwieję....

Może ktoś coś podobnego miał lub spotkał gdzieś na forach.

PS. Dysponuję zrzutami ekranowymi okienek winboxa w czasie padu oraz wykresów mrtg łacza LAN i WAN.[/quote]
Otóż dość niedawno trafiłem na wątek na jednym z forów 'zagramanicznych' ([url]http://forum.mikrotik.com/viewtopic.php?f=2&t=89991[/url]), gdzie był opisany podobny przypadek i podane (połowiczne dla mnie) rozwiązanie. Cyt:

Yes, that was exactly the problem!
After analyzing all the cables I found that they had a Cisco switch between some of the APs and the Mikrotik and it was sending all the packages to everyone, creating some kind of loop and generating the flood.
I removed it and now all the APs are connected directly to the Mikrotik, where I'm dropping such packages and controlling the problem.
Anyway I think this type of multicast iOS devices are doing is crazy because when you have such kind of switchs these packages are multiplying every second!
Since I removed that switch the problem stopped.
Thanks for all your help, I learned A LOT trying to solve it :)[/quote]
[b][color=red]PYTANIE: czy faktycznie w moim przypadku można upatrywać problemów z siecią bo moje juzki używają na swoich końcówkach routerów i łączą sie  telefonami ipadami czy tabletami (sprzętem iOS)?[/color][/b]