September 11th, 2006 by depesz | | 9 comments »
Did it help? If yes - maybe you can help me?

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.

  1. 9 comments

  2. Sep 12, 2006

    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? 🙂

  3. # zbig
    Sep 12, 2006

    bashowy exec Ci pomoże

  4. Sep 12, 2006

    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?

  5. Sep 13, 2006

    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 ? 🙂

  6. # zbig
    Sep 13, 2006

    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.

  7. Sep 13, 2006

    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?

  8. Sep 13, 2006

    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.

  9. # zbig
    Sep 13, 2006

    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.

  10. Sep 13, 2006

    zbig: SIGKILL / SIGBUS nic nie jest w stanie zignorowac,no chyba ze jakies konkretne zoombie 🙂

Leave a comment