Re: Как се справяте с k ernel exploits

Тъй като колегата пожела да ми пише директно, а и тази тема сме я обсъждали доста с колеги от Baidu, Alibaba и Facebook на няколко Kernel Summit-a, paste-вам писмото му тук:

On 11/01/2016 09:25 AM, Computer Burgas wrote:
> честно казано цъкаме с език и чоплим семки , докато те четем ;) ако отвориш бъгтрак ще видиш колко много експлойти има (къде за кернел , къде за сервизи), и мисля че това трябва да е последната ти грижа на този етап от живота ти ... който е решил да те хакне нищо няма да го спре ... просто предполагам не си интересен за хакерите ;)

И моят отговор:
При наличието на голямо количество унифициран setup(еднакъв hardware & software) и възможността да се тества на spare hardware нашата процедура е:
- анализ на kernel patch-а
- оценка на hot paths
- оценка на риска "това да се счупи"
- тест на development server
- тест на spare server
- тест на backup servers
- тест на един, леко натоварен live сървър
- тест на един, много натоварен сървър

Предвид горното и предвид разбирането на технологията, която използваме и особено факта, че до сега този подход не ни е подлъгал, не мога да се съглася с твърденията "не ти пука особено", "явната липса на опит" и "нежизненоважността".

Ако може бих желал да разбера, вие какво правите в ситуация при която имате 99% вероятност да ви exploit-нат kernel-a?
Особено предвид "големият ви опит" и "жизненоважността" на сървърите ви.

Когато една машина няма друга, която може да поеме всички нейни задължения/услуги, единственият вариянтите са:
- да рестартираш машината за да заредиш новият kernel
- да подготвиш нов kernel и да се нядяваш че при kexec-а всичко ще мине правилно

Ако функционалността е във модул, който имаш възможност да unload-неш, очевидно можеш просто да го update-неш и да заредиш новата версия, но много рядко това е случаят.


Мариян
П.С. Любопитно ми е за коя фирма работите. Аз работя в SiteGround.


On 11/01/2016 09:25 AM, Computer Burgas wrote:
> честно казано цъкаме с език и чоплим семки , докато те четем ;) ако отвориш бъгтрак ще видиш колко много експлойти има (къде за кернел , къде за сервизи), и мисля че това трябва да е последната ти грижа на този етап от живота ти ... който е решил да
> те хакне нищо няма да го спре ... просто предполагам не си интересен за хакерите ;)
>
> 2016-10-21 1:55 GMT+03:00 Marian Marinov <[email protected] <mailto:[email protected]>>:
>
>     Днес почти целият ден се занимавах с http://dirtycow.ninja/
>
>     В този ред на мисли, вие как си решавате проблемите с kernel exploits?
>
>     Моят подход винаги е бил:
>     1. Ограничаване на attack vector-а(като build-вам kernel-а само с поддръжка на нещата, които ми трябват)
>     2. Добавям GRsec
>     3. Опитвам се да стоя с по-нови kernels(latest stable)
>     4. Ограничавам достъпа до /proc & /sys, реално гледам друг освен root да не може да гледа почти нищо там освен тези неща, които са owned от него(GRsec proc hardening-а + същото нещо за /proc/PID/net & /sys)
>
>     От доста време наблюдавам развитието на kpatch & kgraft.
>
>     Вие използвали ли сте техника за live patching?
>     Function hijacking и подобни?
>
>     Поздрави,
>     Мариян
>
>     _______________________________________________
>     Lug-bg mailing list
>     [email protected] <mailto:[email protected]>
>     http://linux-bulgaria.org/mailman/listinfo/lug-bg <http://linux-bulgaria.org/mailman/listinfo/lug-bg>
>
>
>
>
> _______________________________________________
> Lug-bg mailing list
> [email protected]
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
>

_______________________________________________
Lug-bg mailing list
[email protected]
http://linux-bulgaria.org/mailman/listinfo/lug-bg