ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [inet-admins] tripwire ?



> > > > >
> > > > > Что предлагается делать, если атакер подменил мониторинг активности ?
> > > 
> > > Защитить мониторинг гораздо проще, нежели систему с большим количеством
> > > пользователей/сессий. Мониторинг активности можно дублировать и вынести
> > > вообще за пределы системы, защитившись от "hijacking'а".
> > > 
> > > Вполне реализуемо, дешево и очень действенно.
> > 
> > Полностью вынести за пределы, без всякой поддержки со стороны
> > самой системы? Я не вижу как это возможно без получения как минимум
> > части проблем из SNI paper про IDS. Также, как быть с шифрованными
> > сессиями? Придется все равно делать какую-то поддержку в самой системе,
> > которую можно там поправить.
> 
> Вклинься, пожалуйста, в ssh сессию так, чтобы это не было заметно.

А причем тут это? Если я правильно понял, выше говорилось о нарушении
работы самого мониторинга, что подразумевало успешную атаку _до_ того.
Поэтому, когда я говорил про шифрованные сессии, я имел ввиду уже ничем
внешне не проявляющиеся сессии intruder'а после успешного взлома. Хотя,
точно также внешний мониторинг ничего не даст для обнаружения атак на
тот же ssh, при условии что эти атаки направлены на уровни протокола уже
за шифрованием.

Но, еще раз, одних SNI'шных проблем вполне достаточно для невозможности
полного мониторинга без поддержки самой системы, даже если забыть про
шифрованные сессии.

Это, конечно, _не_ означает, что подобный чисто внешний мониторинг не
имеет смысла. Просто, как я понял, до сих пор этот thread был попыткой
найти полное решение проблемы -- т.е. гарантированное обнаружение всех
изменений в системе (началось-то с tripwire).

> Любой перебой в этом потоке должен рассматриваться как intrusion
> и соответственно анализироваться. Поскольку активности около всех
> защищаемых объектов минимум, то и ее анализ можно организовать
> вплоть до окончания предыдущей тотальной проверки системы.

К сожалению, нельзя -- будучи вне защищаемых объектов, мы не можем знать
как они реагируют на какую-то активность в сети.

Как правильно сказал ArkanoiD, некоторые проблемы решаются принудительной
дефрагментацией. (Большинство или нет сказать не могу, достаточно того,
что не все.) Также, необходим отказ от снифферства, и пропуск всего потока
через наш монитор (иначе мы не сможем знать успели ли мы все заметить).
Но, к сожалению, и этого недостаточно. Проблемы вроде "а увидел ли наш
защищаемый хост этот RST или нет" останутся.

Так что, можно достичь очень неплохих результатов, но никакой гарантии
все равно не будет.

Signed,
Solar Designer
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on http://info.east.ru/rus/inetadm.html



 




Copyright © Lexa Software, 1996-2009.