Тъй като колегата пожела да ми пише директно, а и тази тема сме я обсъждали доста с колеги от 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 <m...@yuhu.biz <mailto:m...@yuhu.biz>>: Днес почти целият ден се занимавах с 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 Lug-bg@linux-bulgaria.org <mailto:Lug-bg@linux-bulgaria.org> http://linux-bulgaria.org/mailman/listinfo/lug-bg <http://linux-bulgaria.org/mailman/listinfo/lug-bg> _______________________________________________ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
_______________________________________________ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
