Port 0/TCP jest wg rejestru IANA portem zarezerwowanym. Oznacza to, że żadna usługa nie powinna korzystać z tego portu do komunikacji sieciowej. Gdy w dniu 13 listopada 2011 roku do sond systemu ARAKIS zaczęła napływać wzmożona liczba pakietów TCP kierowanych na port 0, zbudziło to nasze zainteresowanie. Próby połączeń na ten port były widziane zarówno przez honeypoty, jak i w sieci darknet. Znaczna większość pakietów zarejestrowanych w honeypotach był zniekształcona (szczegóły niżej). Ruch wrócił do normy z dniem 17.11.2011. Zarejestrowaliśmy jeszcze krótkotrwały wzrost 30.11-01.12.2011. Nasze obserwacje w tych okresach pokrywają się z danymi pochodzącymi z systemu DSHIELD, co świadczy o globalnym zasięgu tej anomalii.

(more…)

W zeszłym tygodniu zaobserwowaliśmy interesujący ruch sieciowy, będący efektem skanowania przeprowadzonego na dużą skalę. Skanowanie losowych adresów w celu sprawdzenia ich dostępności lub podatności na ataki nie jest niczym niezwykłym i codziennie rejestrujemy aktywność tego typu. Jednak wspomniany skan miał nietypową charakterystykę, co spowodowało, że postanowiliśmy mu się dokładniej przyjrzeć.

(more…)

Our annual report for 2010 presents and comments on statistical data derived from CERT Polska daily operations in 2010. The outcome is a comprehensive analysis of network threats affecting Polish networks as we see them. Unlike previous years, when we focused on manually handled incidents, the data presented in the current report is collected largely in an automated fashion from various external and internal systems, yielding millions of records. This allowed us to produce a report analyzing over 12 million submissions that we consider a unique and fairly authoritative picture, not only due to amount and variety of data, but also the extent in which Polish networks are covered. (more…)

Trzy dni temu pojawiły się w systemie ARAKIS połączenia HTTP nawiązane przez – jeżeli wierzyć polu “User-Agent” – pająka webowego HuaweiSymantec. Poprzez żądania GET próbowano pobrać z naszych honeypotów pliki konfiguracyjne (setup.php) znanego narzędzia do zarządzania bazami danych MySQL – phpMyAdmin. Na pierwszy rzut oka wyglądało to jak połączenia generowane przez typowy skaner luk próbujący na ślepo znaleźć podatne lub źle skonfigurowane narzędzie na sprawdzanym serwerze:

(more…)

Od połowy września 2008 roku w sieci obserwowane są skanowania w poszukiwaniu niezabezpieczonych bramek PSTN, które umożliwiają zestawienie połączenia pomiędzy siecią VoIP a publiczną siecią telefoniczną PSTN. Takie niepoprawnie skonfigurowane bramki PSTN umożliwiają atakującemu wykonywanie połączeń telefonicznych do abonentów publicznej sieci na koszt właściciela takiej bramki.

Atak polega na wysyłaniu (najczęściej na port 5060/UDP) pakietów zawierających żądanie INVITE protokołu SIP. Żądanie takie w zamierzeniu służy do inicjowania połączeń głosowych. Atakujący może dowolne sfałszować nagłówki żądania SIP (takie jak numer wywołujący czy identyfikator połączenia), jednak adres IP atakującego w opisywanym scenariuszu nie jest fałszowany, aby umożliwić mu otrzymanie odpowiedzi (a tym samym informacji o powodzeniu ataku). Gdy taki pakiet dotrze do publicznie dostępnej bramki PSTN, nastąpi przekazanie połączenia do publicznej sieci PSTN. Co ciekawe, gdy taki pakiet trafi do telefonu VoIP, nastąpi wywołanie (to właśnie dzwoniące telefony VoIP były jednym z symptomów, dzięki którym zauważono opisywane skanowania). Podejrzane żądania INVITE zostały także zauważone przez system wczesnego ostrzegania ARAKIS – pierwsze obserwacje pochodzą z 14 września 2008 roku. Dnia 2 października nastąpił znaczny wzrost takiej aktywności, co doprowadziło do wyzwolenia reguły systemu wykrywania włamań Snort “VOIP INVITE Message Flood“. Tak przedstawia się przykładowy pakiet protokołu SIP zarejestrowany na porcie 5060/UDP zawierający podejrzane żądanie INVITE:

Aby zapobiec tego typu atakom, administratorzy bramek PSTN lub serwerów proxy SIP powinni wyeliminować możliwość nieautoryzowanego dostępu do tych usług. Zabezpieczenie powinno polegać na umożliwieniu korzystania z bramek tylko wybranym adresom IP (jeśli oprogramowanie bramek nie udostępnia takiej funkcjonalności, powinien zostać zastosowany firewall) lub tylko uwierzytelnionym użytkownikom. Centralki PBX (np. Asterisk) powinny zostać skonfigurowane w taki sposób, aby odrzucać nieautoryzowane żądania połączeń do sieci PSTN.

Więcej szczegółów w artykule Analysis of a VoIP Attack.