niniejszym chciałbym otworzyć nowy dział na blogu – łamigłówki.
będę tu co jakiś czas zamieszczał zagadki/pytania – zazwyczaj pewnie będą mocno techniczne.
nie przewiduję nagród czy nic takiego – po prostu – spróbuj się z tym zmierzyć – jak ci się uda – napisz komentarz. jeśli jeszcze nie zgadłeś – nie czytaj komentarzy. proste 🙂
pierwsza łamigłówka:
mamy do czynienia z serwerem linuksowym. opartym na standardowym kernelu, bez żadnych “ciekawostek" typu grsec czy selinux. standard.
serwer jest ważny, produkcyjny. pracują na nim istotne programy.
po ostatnich pracach administracyjnych zostały zalogowane 2 konsole na roota. na obu jest shell – bash.
niestety, wskutek błedu czy hacka, na maszynie została uruchomiona forkbomba.
nie ma limitów. forkbomba się forkuje i forkuje ignorując błędy. a błędy są bo wypełniła się tablica procesów. i nowe procesy nie mogą być tworzone. nie ma limitów dla roota, nic. ani root ani żaden inny user nie może stworzyć nowego procesu.
nie możemy zrobić reboot – bo serwer jest ważny. nie możemy zabijać losowych procesów – z tego samego powodu.
w jaki sposób spróbować odzyskać kontrolę nad serwerem?
od razu podpowiem, że idea: na jednej konsoli wpisuję “top", potem zamykam drugą i wciskam szybko enter na pierwszej nie zadziałają – może i szybko przełączanie konsole, ale forkbomba na pewno szybciej zrobi kolejnego forka.
sysrq musi byc wlaczone, wpisac na jednej “ps uaxw” – dla ustalenia nazwy ( bez enter ) , alt+sysrq +f ( zrobi oom_kill) ) najlepiej pare razy, wcisnac enter dla psa , oblookac nazwe forkbomby, wpisac killall -9 nazwa bomby ( bez enter ), alt+sysrq+f znow pare razy, szybko enter dla killa
ew. mozna wpisac: echo jakas_duza_liczba > /proc/sys/kernel/threads-max; ps uaxw; ( i tak w kolko, i tak samo dla kill ale watpie zeby to zadzialalo )
jeszcze mozna zrobic cos z tym threads-max jednakze cos w stylu “init 1; init 3”, ale to polozy wszystko…
w ostatecznosci mozna robic alt+sysrq+sync / ro remount i potem reboot.
dostane cukierka? 🙂
bashowy exec Ci pomoże
vnull – oom_kill ubije chba największe procesy – więc kiepska to metoda na ratowanie systemu. forkbomby są raczej małe. poza tym – wolałbym byś nie zakładał “małpiej zręczności” u operatora. raczej metoda która zadziała nawet jak piszemy 0.01 wpm.
zbig: jakieś szczegóły?
nie zgodze sie:
/*
* Processes which fork a lot of child processes are likely
* a good choice. We add the vmsize of the childs if they
* have an own mm. This prevents forking servers to flood the
* machine with an endless amount of childs
*/
( za http://linux-mm.org/OOM_Killer ), siebie mozna ochronic przez cos w stylu echo -17 > /proc/$$/oomadj i tak samo inne procesy ( znajac ich pidy, np 1 😉 )
zas bashowy exec to chyba one shoot mode…
btw: jako ze nikt nie odpowiada to jakie jest rozw ? 🙂
Nigdy nie miałem przyjemności zapoznać się z forkbombą 🙂 więc rozwiązanie jest teoretyczne.
Jeśli masz na dwóch kosolach zalogowanego roota z bashem, to ‘exec top’.
top zastąpi powłokę, w związku z czym żaden nowy proces nie zostanie utworzony.
Można też ‘exec ps’, a potem forkbombę killallem potraktować, oczywiście za pomocą execa.
Ogólnie, jeśli problem leży w niemożności utworzenia nowego procesu, to tak jak napisałem, polecenie podane po exec zastępuje basha.
vnull: rozwiazania za bardzo nie moge podac – a jak ktos jeszcze bedzie chetny sobie polamac glowe?
co do zapisywania do oomadj – fajnie. a jak poznac pidy *waznych* procesów które nie powinny być ubite?
cd /proc
for((x=1;x $x/oom_adj
fi
fi
done
jak ci sie skoncza “wazne” procesy ( to nie robi zadnego fork() ), alt+sysrq+_klawisz_od_oomkill_ pare razy -> ubije reszte. ot taki sobie bruteforce…
btw: super blog, IMHO najlepszy w pl.
vnull: Tak jak mówiłem nie miałem praktycznych doświadczeń z forkbombami, więc moje rozważania są czysto teoretyczne, ale killall powinien sobie chyba poradzić ze zwykłą forkbombą, chyba że ta ignoruje sygnały.
zbig: SIGKILL / SIGBUS nic nie jest w stanie zignorowac,no chyba ze jakies konkretne zoombie 🙂