22:49
4/2/2013
4/2/2013
Odpowiedni pakiet TCP może spowodować reboot urządzeń z Junosem sprzed 17 stycznia.
- Szkolenia
- |
- 5 PORAD
- |
- Audyty & Pentesty
- |
- SKLEP
- |
- Kontakt
Niebezpiecznik
o bezpieczeństwie i nie...
Zamów nasz wykład dla twojej firmy!
Zobacz nasze webinary!
Posłuchaj jednego z naszych 8 cyberwykładów. Wiedzę podajemy z humorem i w przystępny dla każdego pracownika sposób. Zdalnie lub u Ciebie w firmie. Kliknij tu i zobacz opisy wykładów!
Każdy powinien zobaczyć te webinary! Praktyczna wiedza i zrozumiały język. 6 topowych tematów — kliknij tutaj i zobacz szczegółowe opisy oraz darmowy webinar.
Ciekawy błąd, ale… Co komu po restartowaniu losowych maszynek?
Atak DoS
hmm, żeby zająć admina czymś :P
ciekawe jest to, że jeden z potencjalnie ciekawszych/ważniejszych news’ów z linkbloga doczekał się tak niewielu komentarzy :)
ktoś wie co to za pakiet ? :)
jak to mówią: szukajcie aż znajdziecie :O, niestety juniper pozamykał wszystkie “źródełka” z informacjami na ten temat, zapewne dlatego – by dać swoim partnerom czas na upgrade bądź zastosowanie workaround’u (20% rynku używa junipera :) ).
Niestety – informacje wysyłane do klientów, nie są zbyt jasne, choćby ze względu na JTAC Recommended Junos Software do którego odsyła KB (All Junos OS software releases built on or after 2013-01-17 have fixed this specific issue. All JTAC Recommended Releases listed in KB21476 have been updated to include this fix) który mówi, że najnowszy rekomendowany JunOS w różnych wersjach został wypuszczony 31.01.2013, przy czym np. dobierając się do paczki: JUNOS 11.4R6.6 okazuje się, że firmware był zbudowany 5.01.2013, co nie zbyt koreluje się z “All Junos OS software releases built on or after 2013-01-17 have fixed this specific issue”
[…] co poinformowaliśmy o problemie z urządzeniami sieciowymi Junipera, które restartowały się po odebraniu odpowiednio spreparowanego pakietu, a tu podobny problem spotkał także sieciówki Intela. Co gorsza, w przypadku Intela nawet […]
Bardzo po macoszemu potraktowaliście tą informację, jak nie znacie się na czymś, to zapytajcie, zamiast puszczać jednolinijkową informację. Problem jest z TCP, zarówno IPv4 i IPv6. TCP jest używany dla BGP, więc rutery muszą wpuszczać TCP choć z określonych adresów IP. Spoofując odpowiednio pakiet można wrzucić swój pakiet TCP do nawet najbardziej zabezpieczonych ruterów. Problem jest z opcjami TCP, ale szczegółów nie wiadomo. Juniper jest drugim największym na świecie producentem ruterów obok Cisco. Wiele największych sieci, jak np. Level3, Telia i dużo innych ma w szkielecie dużo Juniperów. Level3 np. w zeszłym tygodniu zrobił akcję upgradu softwaru w kilkuset ruterach, niesamowita akcja. W przypadku ruterów MX, które stanowią większość wdrożeń Junipera upgrade softu powoduje parominutową przerwę z powodu restartu kart z interfejsami.
Mogę być waszym konsultantem z zakresu sieci, jak chcecie wrzucać bardziej przydatne informacje :)
A co konkretnie w tej naszej informacji jest błędne?
Przypominam, że ptr* to linkblog — my wrzucamy minimalny, zazwyczaj jednozdaniowy, opis i odsyłamy do źródła.
A kto powiedział, że błędne?
chyba chodziło o to, że źródło kiepskie :), jak dla mnie tekst jest odpowiedni dla ptr*, ale mógłby znaleźć się i na “głownym” niebezpieczniku, tak jak zrobiliście w przypadku Intela (a tam impact jest zdecydowanie przecież mniejszy) właśnie przez wzpomniane przez Gregora powody.