Krótko: Zmienione pliki znajdą Państwo w Linuxie poleceniem find z oknem czasowym, na przykład od 17 października 2026, czyli od pierwszej, według doniesień mediów, zaobserwowanej próby ataku na PHP2Shell. Proszę sprawdzać nie tylko czas zmiany zawartości (mtime), lecz także metadanych (ctime), ponieważ pierwszy łatwo sfałszować. Wiarygodny wynik daje dopiero porównanie z sumami kontrolnymi pakietów, Git lub kopią zapasową.
Dlaczego znaczniki czasu to dobry początek, ale nie dowód
Kto wprowadza kod na serwer, zmienia pliki. Nowe webshelle, zmienione pliki konfiguracyjne, dopisane wiersze w istniejących skryptach: wszystko to zostawia znaczniki czasu. Wyszukiwanie zmian we właściwym oknie czasowym jest więc jedną z najszybszych dróg do pierwszych znalezisk.
Dla PHP2Shell na początek okna nadaje się 17 października 2026, dzień pierwszej, według doniesień mediów, zaobserwowanej próby ataku. Poprawki ukazały się 21 października. Kto zaktualizował serwer dopiero potem, szuka do dnia własnej aktualizacji i dalej. Jak rozpoznać webshelle wśród znalezisk, opisuje Rozpoznawanie i usuwanie webshella. Tutaj chodzi o samą metodę wyszukiwania.
Trzy znaczniki czasu pliku
Linux zapisuje dla każdego pliku kilka momentów. Dla wyszukiwania zmian rozstrzygające są dwa.
| Znacznik czasu | Znaczenie | Czy można sfałszować? |
|---|---|---|
| mtime | ostatnia zmiana zawartości | tak, np. przez touch, przez każdego, kto może zapisywać plik |
| ctime | ostatnia zmiana zawartości lub metadanych, takich jak uprawnienia | nie prostymi środkami |
| atime | ostatni dostęp do odczytu | często wyłączony lub niedokładny, mało przydatny do wyszukiwania |
Atakujący chętnie cofają mtime do daty sąsiednich plików, aby nowy plik nie rzucał się w oczy. ctime zmienia się przy tym jednak razem z nimi. Plik ze starym mtime i świeżym ctime jest więc silną wskazówką manipulacji.
Przy porównaniu proszę zwracać uwagę na strefy czasowe. find i ls pokazują czas lokalny serwera, wiele plików logów i usług pracuje natomiast w UTC. Kto zestawia znaleziska z systemu plików i logów, powinien przeliczyć wszystkie dane na tę samą strefę czasową, w przeciwnym razie zdarzenia pozornie do siebie nie pasują. Poprawki ukazały się około 21 października o 14:00 UTC, czyli o 16:00 czasu niemieckiego.
Znajdowanie zmienionych plików w Linuxie przez find
Wszystkie polecenia tylko odczytują dane. Ścieżkę i datę proszę dostosować.
# Zawartość zmieniona od 17.10.2026, posortowana, z mtime, ctime i właścicielem
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metadane zmienione od 17.10.2026 (znajduje także pliki cofnięte w czasie)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Ukryć znany szum: cache, logi, sesje
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Zajrzeć także poza katalog WWW
find /etc /usr/local/bin /tmp /var/tmp /dev/shm -xdev -type f -newerct "2026-10-17" -printf '%C+ %p\n' 2>/dev/null | sort
Przy każdym trafieniu proszę porównać oba znaczniki czasu. Jeśli ctime jest wyraźnie młodszy od mtime, a nikt w tym czasie nie zmieniał uprawnień ani nie kopiował plików, plik trafia na listę. Proszę zwrócić uwagę także na właściciela: plik użytkownika serwera WWW wśród plików użytkownika deploy rzuca się w oczy.
Nie wolno zapominać o ukrytych plikach i katalogach. Nazwy zaczynające się od kropki wiele menedżerów plików i zwykłe ls nie pokazuje. Atakujący chętnie to wykorzystują, podobnie jak nazwy łudząco podobne do prawdziwych plików.
# Ukryte pliki i foldery w katalogu WWW, bez znanych jak .htaccess i .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Porównanie z wiarygodnym źródłem
Znaczniki czasu pokazują, gdzie coś się ruszyło. To, czy była to zmiana uzasadniona, pokazuje dopiero porównanie ze źródłem, któremu Państwo ufają.
- Zarządzanie pakietami: Dla plików systemowych
dpkg --verify(Debian/Ubuntu) lubrpm -Va(rodzina RHEL) sprawdzają pliki względem sum kontrolnych zainstalowanych pakietów. Pliki konfiguracyjne odbiegają zasadnie, pliki programów nie. - Git: Jeśli aplikacja leży w repozytorium,
git -C /var/www/projekt status --porcelainpokazuje każde odstępstwo od ostatniego commita. - Sumy kontrolne CMS: Wiele systemów potrafi porównać swoje pliki rdzenia z oficjalnymi sumami kontrolnymi, zob. Porównanie plików rdzenia CMS z oryginałem.
- Kopia zapasowa sprzed incydentu: Porównanie w trybie próbnym wypisuje różnice, niczego nie kopiując.
# Tylko wypisać różnice między stanem kopii zapasowej a systemem na żywo (tryb próbny, niczego nie kopiuje)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Porównanie z kopią zakłada, że kopia powstała przed incydentem i sama nie została zmieniona. Dlaczego oddzielnie przechowywane kopie są tu decydujące, wyjaśnia Kopie zapasowe według zasady 3-2-1.
Wyniki każdego wyszukiwania proszę zapisywać z datą w pliku poza serwerem. Z tych list powstaje później oś czasu incydentu i dokumentują one, co i kiedy Państwo sprawdzali.
Gdy nie ma ani kopii, ani repozytorium
W wielu mniejszych witrynach nie istnieje czysta baza porównawcza: brak Git, brak kopii sprzed incydentu, wtyczki od lat aktualizowane ręcznie. Mimo to nie są Państwo całkiem bez punktu zaczepienia.
Proszę pobrać CMS i rozszerzenia dokładnie w zainstalowanych wersjach od producenta i porównać te pliki z serwerem. To, co tam odbiega lub brakuje, zasługuje na spojrzenie. Zostają Państwa własne dostosowania, uploady i konfiguracja; tam pomaga wyszukiwanie po znacznikach czasu, uzupełnione o spojrzenie na właściciela i uprawnienia. Pliki, które jako jedyne w katalogu mają inną grupę, inne uprawnienia lub wyraźnie młodszy ctime niż sąsiedzi, trafiają na listę.
Szczerze mówiąc: bez bazy porównawczej pozostaje niepewność resztkowa. W systemach z wrażliwymi danymi budowa od nowa z czystych źródeł jest wtedy często bardziej wiarygodna niż szukanie każdego pojedynczego zmienionego pliku. Na przyszłość nauka jest prosta: repozytorium dla kodu i regularne, oddzielnie przechowywane kopie zapasowe.
Typowe źródła błędów przy wyszukiwaniu
- Zbyt szerokie wykluczenia: Katalogi cache i uploadu to ulubione kryjówki.
- Sprawdzone tylko mtime: Pliki cofnięte w czasie się prześlizgują.
- Wdrożenie w oknie czasowym: Regularne wdrożenie zmienia setki plików i zasłania pojedyncze znaleziska. Proszę porównać z repozytorium.
- Pliki już otwarte lub skopiowane: Kopie bez zachowania znaczników czasu niszczą ślady. Proszę zabezpieczać narzędziami, które zachowują znaczniki czasu.
- Przeszukany tylko katalog WWW: Atakujący umieszczają narzędzia także w
/tmp,/dev/shmlub w katalogu domowym użytkownika serwera WWW. - Przeoczone zmiany uprawnień: Plik, którego uprawnienia nagle pozwalają wszystkim na zapis, jest znaleziskiem, nawet jeśli jego zawartość jest niezmieniona.
Jak ze znalezisk złożyć przebieg zdarzeń, pokazuje Tworzenie osi czasu incydentu.
Jak konkretnie pomaga PHP SOS?
- Szukać systematycznie: Przeszukujemy katalogi WWW i ścieżki systemowe pod kątem zmian w istotnym oknie czasowym i oceniamy mtime i ctime łącznie.
- Sprawdzać z oryginałami: Porównujemy z pakietami, repozytorium, sumami kontrolnymi CMS i Państwa kopiami zapasowymi.
- Oceniać znaleziska: Oddzielamy zmiany regularne od manipulacji i zabezpieczamy dowody.
- Oczyścić: W ramach usuwania złośliwego oprogramowania przywracamy czysty stan i go dokumentujemy.
Częste pytania
Jak znaleźć wszystkie pliki zmienione od określonej daty?
Poleceniem find z opcją -newermt, na przykład find /var/www -type f -newermt "2026-10-17". Dla zmian metadanych proszę użyć -newerct. Oba polecenia tylko odczytują dane i niczego nie zmieniają.
Jaka jest różnica między mtime a ctime?
mtime to moment ostatniej zmiany zawartości i można go prostymi środkami cofnąć w czasie. ctime to moment ostatniej zmiany zawartości lub metadanych i nie da się go tak łatwo sfałszować. Jeśli oba mocno się różnią, warto przyjrzeć się dokładniej.
Jak wykluczyć pliki pamięci podręcznej z wyszukiwania?
Przez -not -path dla znanych katalogów cache, logów i sesji. Proszę jednak nie wykluczać zbyt szeroko, ponieważ atakujący chętnie umieszczają pliki właśnie tam, gdzie wiele zmian jest normalnych.
Która kontrola jest najbardziej wiarygodna?
Porównanie z wiarygodnym źródłem: sumy kontrolne zarządzania pakietami, repozytorium Git lub kopia zapasowa sprzed incydentu. Znaczniki czasu są dobrym początkiem, ale nie dowodem.