Badania śladów zostawionych przez moje tamagotchi odcinek kolejny. Tym razem zobaczę co powiedzą o jego działaniu ślady zgromadzone w systemie plików. A konkretnie czego się można dowiedzieć porównując jego snapshot wykonany przed i po infekcji, jak również sprawdzę, czy uda się stworzyć jakiś timeline działań malware w systemie.
Mając ten komfort, że nikt nie będzie mi zarzucał naruszenie stanu obiektu badań, uruchomiłem na zainfekowanym systemie kilka narzędzi, które za zadanie miały zebrać pewne informacje o tym, co się w nim dzieje.
Chciałem dziś zaktualizować listę POI na Miplo, ale okazało się, że to nie jest wcale takie proste... Na stronie powitał mnie komunikat: (...) W ZWIĄZKU ZE ZMIANAMI SYSTEMU ZABEZPIECZEŃ SERWISU MIPLO (W NASTĘPSTWIE MOŻLIWOŚCI UJAWNIENIE HASEŁ CZĘŚCI KONT), PROSIMY WSZYSTKICH UŻYTKOWNIKÓW O USTAWIENIE NOWEGO HASŁA. (...) Przepraszamy wszystkich użytkowników za powstałe problemy. Zespół Miplo. 13 MAJA 2008 No bardzo konkretne wyjaśnienie. Znaczy się co, ktoś się włamał i wyprowadził listę użytkowników? Bo raczej nie sądzę, że chodzi o brak SSL (wciąż trzeba sobie wybrać “loguj się bezpiecznie”). Dziś jest 18 maja, komunikat ma więc 5 dni. Cóż, nie aktualizuję POI codziennie. Zakładając, że było jakieś naruszenie bezpieczeństwa (no dobrze, nie koniecznie włamanie, może ktoś wyrzucił jakiś dysk, płytki/taśmy z backupem, czy coś w tym stylu), to dlaczego użytkownicy serwisu nie zostali o tym poinformowani (choćby mailem)? Niektórzy prości użytkownicy mają tendencję do używania jednego hasła do wszystkich systemów, więc, w moim głębokim przekonaniu, poinformowanie o potencjalnym jego ujawnieniu powinno mieć miejsce natychmiast po stwierdzeniu możliwości jego zaistnienia.
Irytuje mnie, gdy logi mojego obszczymurka są pełne tego typu wpisów: (...) May 16 06:14:43 puffy sshd[16266]: Invalid user tester from 207.210.75.197 May 16 06:14:43 puffy sshd[30954]: inputuserauthrequest: invalid user tester May 16 06:14:43 puffy sshd[30954]: Received disconnect from 207.210.75.197: 11: Bye Bye (...) Wiem, że można sobie z tym radzić na różne sposoby, przenieść SSH na inny port, blokować uciążliwe IP, na Linuksie miałem kiedyś zrobione port-knocking...
Dzisiaj postanowiłem nieco utrudnić życie automatom, których aktywność może się nasilić choćby z uwagi na słynną już dziurę w OpenSSL i zestaw złych kluczy. Znów poszedłem po najmniejszej linii oporu i wykorzystałem to, co pf ma samo w sobie, czyli max-src-conn-rate (patrz pf.conf). Ciekawe jak sobie poradzą z limitem jednego połączenia na 30 sekund...