Молодой хакер, на счету которого было огромное количество взломанных машин, безуспешно пытался зайти на сервер международного банка. Эту систему он наконец-то взломал, потратив на нее несколько бессонных ночей. "Неужели засекли? Я же чистил логи и был предельно осторожен", - вертелось у него в голове. Внезапно его раздумья прервал тонкий писк UPS, что означало отключение электропитания. Затем раздался громкий стук в дверь, за которой стояли вооруженные работники федеральной службы. Эта история закончилась бы печально, если бы горе-хакер не... проснулся от писка своего будильника.

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

Но ведь ломают! Ломают и удерживаются незамеченными на серверах месяцами, а то и годами. И все благодаря элементарной маскировке. Достигается она, как правило, соблюдением нескольких неписаных законов, которые знает каждый уважающий себя хакер. Нарушив одно из таких правил, можно стать уязвимым для админов, которые своевременно обнаружат и нейтрализуют найденного взломщика. При этом последствия для нарушителя могут быть весьма плачевными.

Тебе интересно, о каких нарушениях идет речь? В этом материале я кратко изложу десять ошибок хакера, которые, на мой взгляд, являются самыми популярными. Ошибки актуальны в основном для unix-like систем, поэтому любителей Windows попрошу не питать особых надежд.

1. Чистка логов

Как ни странно, мало кто любит чистить логи во взломанной системе. А ведь именно по логам админ обнаруживает вторжение. Давай рассмотрим механизм создания логов в unix-like операционке.

Как правило, служебная информация скидывается в файл при помощи функции syslog(). Эта функция напрямую работает с демоном syslogd, либо с его альтернативой (syslog-ng, например). У этого демона есть свой конфигурационный файл (по умолчанию /etc/syslog.conf), в котором подробно указывается местонахождение log-файлов и критерии для того или иного лога, чтобы корректно отделить мух от котлет. Хакер часто забывает, что админ может сменить названия дефолтовых журналов, перенаправив /var/log/secure, к примеру, в /usr/admin/secure. К тому же логи могут писаться в консоль конкретному юзеру, что сильно затрудняет положение хакера.

Чистка таких файлов должна осуществляться с особой осторожностью: проверенными логвайперами, либо руками (идеальный вариант). Я лично встречал такие логвайперы, после применения которых журналирование данных останавливалось. Думаю, добропорядочный админ при таком раскладе быстро заметит неполадки в системе.

Как ни странно, руками вычистить текстовые логи очень просто. Вначале необходимо узнать, есть ли в логах данные, которые следует убрать (например, ip хакера или логин в системе). Затем эта информация старательно вычищается из отдельно взятого журнала с последующим перенаправлением во временный файл. И лишь после этого временный файл переименовывается в настоящий. Эти операции осуществляются при помощи стандартных команд grep и mv. Их можно также провести и при помощи внешних редакторов (vi, ee, mc).

Если с чисткой текстовых логов не возникает особого геморроя, то обрабатывать бинарные файлы несколько сложнее. Тут не обойтись без специальных логвайперов, понимающих структуру следующих файлов: /var/log/wtmp, /var/log/lastlog и /var/run/utmp.

Часто хакеры решают проблему простой командой rm. Но если админ увидит, что за последний месяц в его системе не было пользователей, взломщику от этого лучше не станет. Удалять можно лишь utmp-файл, отображающий пользователей в системе в данный момент времени. После удаления должна последовать команда touch, создающая файл заново. Если этого не сделать, бинарник /usr/bin/w ругнется на отсутствие utmp, а запись онлайн юзеров производиться не будет.

2. Изменение даты на файлах

Дата на файлах - уязвимое место хакера. Именно по дате программы-следилки за системой определяют установку руткита, либо изменение системных файлов. Сменить дату на файле позволяет команда touch с параметром -t, после которого идет дата в формате: МесяцДеньЧасМинутаГод. Взломщики очень часто забывают менять дату обратно на старую после правки конфа либо перезаписи бинарника. Админские утилиты быстро определяют изменения в системе и посылают подробный отчет администратору на мыло.

3. История команд

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

Но если посмотреть с другой стороны, то и админ может быть параноиком, регулярно изучающим свой собственный history-файл. И если хакер порядочно наследил в системе, оставив таким образом историю установки руткитов или DoS'еров, реакция администратора непредсказуема. Поэтому каждый взломщик должен своевременно заметать свои следы.

Местонахождение history-файла можно узнать через переменную среды HISTFILE, просмотрев ее консольной командой echo $HISTFILE. Соответственно после команды export HISTFILE=/dev/null запись команд в файл прекратится. Внимание! Данный прием работает только на время текущей сессии, поэтому хакеру придется выполнять команду каждый раз при появлении в системе.

4. Заражение системы руткитами

Как это ни парадоксально, но установка руткитов может запросто выдать хакера. Во-первых, заменяя системные файлы, он, как правило, совершает ошибку №2, так как устанавливать первоначальную дату на туеву хучу бинарников мягко говоря долго и неспортивно. Во-вторых, если админ установил новую версию пакета (binutils, например), то установка старой поверх системной ни к чему хорошему не приведет. Более того, нарушителя могут выдать ключи к командам, задаваемые alias'ом. К примеру, старая версия /bin/ls не понимает ключа --colors, а многие руткиты содержат именно старые версии. Иными словами, установив старый руткит на новую систему, хакер автоматически подписывает себе смертный приговор.

5. Установка своего софта

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

На самом деле, после взлома нарушитель анализирует деятельность админа и делает выводы о степени запущенности сервера. Но устанавливать свои программы в корневые директории все же не стоит. Чтобы этого избежать, хакер должен создать свой отдельный скрытый каталог и ставить весь боевой софт в него. Это достигается командой ./configure --prefix=/path/to/hidden/xakep_dir при установке пакетов.

6. Сканирование со взломанной системы

Самая распространенная ошибка среди всех перечисленных. Ведь скан с порутанного сервера никогда не приводит ни к чему хорошему. Смотри сам: взломщик сканирует подсеть nmap'ом или другим доступным сканером. После чего законопослушный админ просканенной сетки может написать жалобу в abuse компании, с которой производился скан, с высылкой всех логов, доказывающих факт вторжения. Служба безопасности, закрепленная за компанией, в свою очередь приходит к выводу, что их сервер поломали, и стучат по голове администратору. Ясно, что после этого инцидента хакеру на сервере не жить.

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

7. Изменение рулесов фаервола

Фаервол - личное дело админа. И если он его установил, подразумевается, что он знает все его правила как свои пять пальцев. Если же взломщик будет их настраивать на свой вкус, то рано или поздно админ пресечет эти деяния. Исключение могут составлять жуткие нагромождения правил, составленные явно не администратором системы. Добавление неприметной записи в эту гремучую смесь не вызовет катастрофы.

Если же фаервол содержит несколько удобочитаемых правил, и, судя по HISTFILE, администратор регулярно следит за ними, то ничего не остается, кроме как подчиниться им, либо изменить исходники фаервола (для C гуру). Это, кстати, самый классный вариант.

8. Добавление новых пользователей

Довольно типичная ситуация: взломав систему, хакер делится впечатлениями о взломе в IRC или ICQ. Его лучшие друзья тут же начинают выпрашивать шелл для личных нужд. Поразмыслив немного, взломщик добавляет пользователя в систему, успокаивая себя, мол, шелл-то не рутовый, чем он может мне помешать. На следующий день администратор получает утренний отчет об аномальных происшествиях в системе и находит в нем интересную строку, например:

New users:

Теперь можно попрощаться с root-аккаунтом на взломанной тачке.

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

9. Допуск в систему посторонних лиц

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

Грамотный хакер никогда не создает подобных ситуаций. Более того, он не треплется о взломе где попало, всегда ставя собственную безопасность на первое место. Нарушение данного правила возможно лишь в случае, если ты убежден, что после предоставления доступа у тебя не возникнет лишних проблем.

10. Выбор профессии хакера

Да, ты не ослышался! Хакер - как сапер, первый раз ошибается еще при выборе своей профессии. Каждый взлом может оказаться для него фатальным, и сам он это осознает. Но не может с этим смириться, считая взлом экстремальным видом спорта. Если ты все еще раздумываешь, "быть или не быть хакером", то я дам тебе совет. НЕТ! Быть хакером уже не так модно, да к тому же опасно. Так что займись лучше чем-нибудь другим, например, продажей школьных выпускных сочинений по русскому языку через интернет .

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

Этот материал призван показать типичные случаи, когда хакеры выдают себя во взломанной системе. Не следует считать это руководством к действию. Прежде чем совершить непоправимое, прочитай еще раз 10 пункт. В мире ведь еще столько интересного .

Утилиты-следилки или помощь админу

В этой статье не раз упоминалось про админские утилиты. Они представляют собой программы, которые ежедневно сканируют систему (md5-сумма бинарников, изменение в конфах, процессах и т.п.) и сравнивают изменения в своей базе. После чего генерируют отчет и шлют его админу на мыло. Сама прога висит в виде демона или запускается crontab'ом. Примером такой утилиты является программа tripwire