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

Stanimir Stoyanov <[email protected]> Tue, 1 Nov 2016 15:43:23 +0200
Newsgroups	gmane.linux.region.bulgaria
Message-ID	<[email protected]>
Май е крайно време да проуча kexec по-детайлно... Натоварените сървъри
за които се грижа са в LB група, и ги пачвам по отделно без downtime, а
ненатоварените преживяват няколко минути нощна почивка...

Изключвайки дебъгване и други по-специфични процеси, аз също не мога да
се сетя за легитимна причина един процес да гледа чужди /proc/pid/*.

В kernel-hardening групата също има интересни идеи...
http://www.openwall.com/lists/kernel-hardening/

p.s. mx.inetg.bg връща 550 5.7.1 <[email protected]>... Relaying
denied. Proper authentication required. (in reply to RCPT TO command)

Поздрави,
Станимир


On 11/01/2016 03:06 PM, Marian Marinov wrote:
> Тъй като колегата пожела да ми пише директно, а и тази тема сме я
> обсъждали доста с колеги от 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

-- 
I prefer to use encrypted email. My public key fingerprint is 1D5A 5552 2B11 7534 65BE  1338 34DD BE1E 036F 7FEB. Learn how to encrypt your email with the Email Self Defense guide - https://emailselfdefense.fsf.org/en/

_______________________________________________
Lug-bg mailing list
Lug-bg-R/uZOSXD/[email protected]
http://linux-bulgaria.org/mailman/listinfo/lug-bg
signature.asc (application/pgp-signature, 801 B)