Да се доверим ли на чужд лог?

Да се доверим ли на чужд лог?

Преди няколко дни...

Днес сутринта се обади колега администратор (благодаря му за бързата реакция), който сподели, че е получил няколко писма на електронен адрес за сигнализиране при атаки и нередности, в които има информация, че са засечени опити за достъп от IP адрес, използван в лаборатория в университета, в който преподавам.

Посоченият IP адрес е конфигуриран на стар Linux сървър и там се хостват няколко CMS страници, базирани на приемливо защитена платформа (не - не е Joomla! или WordPress). Логнах се към устройството и прегледах процесите и текущите комуникационни сесии. Имаше няколко подозрителни, и при по-задълбочената проверка попаднах на артефакти, подсказващи за наличие на зловреден код. Изолирахме системата и започнахме експертиза за да установим по какъв начин зловредният код е инфектирал операционната система.

Колегата ми беше препратил няколко писма с логовете, съдържащи информация, че от конкретния IP адрес са извършени последователни неуспешни опити за достъп през SSH до различни крайни устройства в няколко държави. Докато ги преглеждах се замислих, по какъв начин се гарантира, че тези данни не са модифицирани или целенасочено въведени (б.а. - в конкретния случай имаше зловреден код, генерирал заявките)? При получаване на подобни писма естествената реакция е да се стартира проверка на посочените адреси (тук може да дадем като пример анализи, базирани на "Cyber Kill Chain" и "Diamond Model", да намесим ITIL и др.), а по-неопитните администратори могат веднага да блокират трафика към и от посочените адреси. Това не ви ли звучи като потенциален вектор на атака, базиран на социално инженерство? Умишлено създаване на фалшиви логове и изпращането им към администраторите на целевата инфраструктура.

Нека да се върнем на писмата с логовете. Те не бяха разписани с електронен подпис, а текстът беше автоматично генериран (подобни текстове винаги ми напомнят за клетвата, която полагат стражиницте от нощната/градксата стража в Анкх Морпрок).

Има ли начин някой да генерира подобно писмо и да добави логове, с желаните от него IP адреси и да опита да подведе администраторите на целевата мрежа? Тук отговорът е "твърдо да". Тогава, как да се доверим на посочените журнални записи и адреси?

Има няколко варианта да се действа в подобна ситуация. Единият е да приемем, че посочените логове са реални и да направим допълнителни проверки в легитимни и доверени публични източници. За разглеждания пример, извърших справка в GreyNoise и AbuseIP.

Откритите артефакти и данните в горните два сайта потвърдиха истинността на логовете. Подобни анализи отнемат време и трябва да се прецени, дали потенциално заразената система да бъде изолирана или да продължи да работи. Ако има реална зараза, то филтрирането на трафика ще помогне да се намалят нейните потенциални вреди на трети устройства, но ако няма зловреден код или успешно компрометиране, то изключването може да доведе до спиране на услуги.

Друг подход е да се използва технология, гарантираща, че съдържанието на логовете не е подправяно и в същото време еднозначно определяща източника. Има проекти, базирани на блокчейн, но те все още не намират масово приложение. В своя блог Steve Versteeg посочва, че за момента няма публична блокчейн технология, специализирана за защита на ситемни логове.

Замислих се, кое е нещото, което може да докаже атаката. Разбира се, това е мрежовият трафик, но колко компании и институции имат и въобще биха напарвили пълно записване (full packet capture) на комуникационните потоци? Да, тук отново има вероятност за умишлена подмяна на IP адресите (spoofing), но вече започваме да изпадаме в заешката дупка на теорията на конспирацията.

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

В наши дни...

Търсенето на решение за доказване на източника на логовете и тяхната истинност продължава...