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/.
Strony: 1
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.
Offline
Czy te switche są zarządzalne czy to zwykłe "mydelniczki" ?
Dobrze by było wyłapać skąd ten ruch udp się bierze. Ruch protokołu UDP bardzo ładnie potrafi zatykać łącze co już się przekonałeś ;) Może ktoś w sieci ma jakiegoś wirusa i słane są informacje w świat, a może jakiś spoofing hmm no opcji jest kilka.
Może masz burze broadcastowe lub jakieś pętle to najlepiej jakimś tcpdumpem/wirsharkiem wyłapać.
Do sprawdzenia jest wydajność tych routerów np. CPU jak oczywiście istnieje możliwość podpatrzenia takich statystyk. Także do sprawdzenia NAT i QoS.
Dobrze by było włączyć się jakimś komputerem w sieć i tcpdumpem/wiresharkiem wyłapać ruch i go sobie obejrzeć, fajnie jak by można było się wpiąć fizycznie np. między Mikrotykiem, a switchem, między routerami itd. a jak nie ma możliwości to zostaje port monitoring, chociaż tutaj może być problem bo uszkodzone ramki są odrzucane przez switch i mogą nie być wyłapane przez snifer.
Ostatnio edytowany przez ba10 (2012-11-09 15:27:49)
Offline
Dzięki za odzew.
Czy te switche są zarządzalne czy to zwykłe "mydelniczki" ?[/quote]
z czystej oszczędności to zwykłe mydelniczki - w tej chwili stoją TP-LINKI (TL-SF100BD)Dobrze by było wyłapać skąd ten ruch udp się bierze....[/quote]
żródła są różne - zarówno wewnętrzne jak i zewnętrzne ip
Poniżej fragment statów mrtg z mikrotika
[img]http://jolka1.gugade.x25.pl/zrzut03.jpg[/img]
Burze broadkastowe... kiedy mogą występować? Ja nie mam na radiu WDSów i pętle też są niemożliwe...
Wirus.... to może i być, ale q...wa mać musi być bardzo perfidny (czytaj przebiegły).
Wydajność Mietków jest wystarczająca - nie pocą się wogóle - max. obciążenie nie było nigdy większe niż40-50 proc.
Nat i qos też sprawdzałem i jest spoko. Wyłączyłem z filtrów L7 by nie obciążał procka.
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....
Czekam na opinie innychOffline
[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ć :)
Offline
"Mydełka" są prosto ze sklepu, świeże dopiero co odpakowane, teoretycznie powinny być ok
A wireshark faktycznie daje dużo informacji. Odezwę zię jak to przeanalizuję i "przetrawię". Dzięki jeszcze raz.
Offline
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ć.
Offline
Witam... po przerwie technicznej. Uporządkowałem sieć jeśli chodzi o sprawy niedziałających łączy klienckich (było kilka nieużywanych kawałków skrętki). Niestety nic to nie dało. Mam zrzuty z wiresharka (początek z padniętą siecią, gdy furczą pakiety - średnio kilka do kilkunastu tys, pakietów na sekundę; koniec gdy sieć już działa i jest po restarcie prądowym - wyłączyłem/włączyłem zasilanie na swiczach i routerkach) - trochę tego jest. Może znajdzie się ktoś kto podpowie co i jak z tymi danymi zrobić - wiem, wiem najlepiej to trasz. Powaznie - chodzi mi o przeanalizowanie tych pakietów. Służę materiałem źródłowym.
PS. Najsmutniejsze jest to, że nie wiem skąd bierze się ip zewnętrzne (nie w zakresie adresacji sieci lokalnej) spod którego wychodzą te pakiety, które zatykają porty lan routera.
Ostatnio edytowany przez Nickleodeon (2013-01-15 14:34:09)
Offline
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)
Offline
Dzięki za odp. - szybką, naprawdę szybką. Analizowałem odp początku cały konfig sieci i mam kilka pytań do szanownych forumowiczów:
1. protokół zarządzania WAN (TR-069) - z czym to można zjeść, tzn. jakie jest zagrożenie bezpieczeństwa LAN przez taki protokół?
2. czy wlan na dgt (zewnętrzne IP) może w jakiś automagiczny sposób sprzędz się z wlan na jednym ze swiczy 8port (wewnętrzny IP), na którym jest dostępny jako klient AP; na jednym i na drugim radiu wymagana jest autoryzacja
jeden z rekordów wiresharka:
26 0.001582000 80.239.217.155 192.168.88.142 TCP 66 http > cplscrambler-in [FIN, ACK] Seq=1 Ack=1 Win=8312 Len=0 TSval=3591513055 TSecr=1854
to by mogło wiele tłumaczyć.... może się mylę....
Co wy na to?
Ostatnio edytowany przez Nickleodeon (2013-01-15 15:37:09)
Offline
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....
Offline
Jeżeli to się dzieje w sieci lokalnej zainteresuj się mac adresem źródłowym pakietu z publicznym adresem źródłowym z którego pochodzi ruch. Wszystkie pakiety z takim adresem w sieci lokalnej powinny mieć adres mac routera jako źródło każdy inny mac adres jest podejrzany. Skoro używasz mikrotika w prosty sposób rozwiążesz problem doraźnie na firewallu.
Zajebiste routery tplink ostatnimi miesiącami robią niespodzianki tego typu. Któryś z klientów kupił na promocji w lidlu czy innej biedronce router i stąd wynika problem. Znajdziesz gagatka po mac adresie na pewno.
Offline
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
Offline
Witam Matkę Przełożoną :P Dawno cie nie... czytałem...
Aby dokładnie doprecyzować temat powiem o sytuacji co niektórych juzerków. Otóż mają oni postawione u siebie w mieszkaniach AP i/lub swicze, które rozdzielają sygnał netu ode mnie. Na te AP potrafią logować się telefonem, tabletem czy lapkiem.Mam nawet takich, którzy mają same apple.
Te AP mają swoje IP (mogę się na nie logować jako admin :P). Do takiego jednego (Netgear) zauważyłem że w "chwilach kryzysu" napiera kilka tys. pakietów na sec. jako żródło adres spoza sieci, zewnętrzny. Protokoły są różne - raz są to UDP, innym razem TCP. Zawsze jest to jednak tak, że Mietek na lanie odnotowuje ponad 5 tys. pakietow na sek.
Offline
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]
Offline
Miałem taki sam przypadek, w sieci miałem jednego mikrotik'a, tez podejrzewałem go, jednak jak był odłączony działo się to samo. Po burzy mózgów w sieciowicami stwierdziliśmy że są dwie możliwości:
1) Ktoś ma jakiegoś syfa, jednak analiza ruchu nic nie pokazywała
2) Ktoś robi pętle, jak masz zarządzalne, robisz vlan (czy jajkoś tak) i co najwyżej pada Tobie jeden segment sieci. Zacząłem analizę pakietów UDP na broadcast odizolowałem jeden MAC, jednak klient w tym samym czasie zrezygnował, i problem jak ręką odjął. :)
To co piszesz faktycznie mogło by być przyczyną, ale raczej powolnego działania, a nie padu sieci. Zauważyłem to podczas jednej z analiz ruchu, i dlatego myślałem że ten mikrotik padł, jednak to nie było to, oczywiście u mnie. Do dzisiaj ten mikrotik działa ładnie.
Offline
Padu sieci to może być przyczyną, semi-admin here, 800 klientów na karq, nam znów zdychała centralka światłowodowa, pomagał reboot, ale ostatecznie doszliśmy do tego że to pętlenie się (nadajniki 5G w bridge'u i jeden dodatkowo podpięty po światłowodzie i po radiolinii), nawet dziesięciogigowe światłowody zapychało. Tak jak mówi kolega, ratuj się vlanami. Segmentujesz sobie sieć i dzięki temu zawężasz krąg poszukiwanych.
Skoro masz gdzieś tam mietka, to możesz postawić sobie The Dude jako monitoring sieci i ładnie widzieć w której części ruch przekracza normy.
Offline
Strony: 1
Time (s) | Query |
---|---|
0.00011 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00097 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.14.134.18' WHERE u.id=1 |
0.00078 | UPDATE punbb_online SET logged=1732236196 WHERE ident='3.14.134.18' |
0.00045 | SELECT * FROM punbb_online WHERE logged<1732235896 |
0.00073 | DELETE FROM punbb_online WHERE ident='66.249.66.73' |
0.00082 | SELECT topic_id FROM punbb_posts WHERE id=223996 |
0.00301 | SELECT id FROM punbb_posts WHERE topic_id=22261 ORDER BY posted |
0.00128 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=22261 AND t.moved_to IS NULL |
0.00011 | SELECT search_for, replace_with FROM punbb_censoring |
0.00110 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=22261 ORDER BY p.id LIMIT 0,25 |
0.00084 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=22261 |
Total query time: 0.01024 s |