Методы проникновения


Собираясь написать эту статью, я решил совместить чисто теоретические знания о методах проникновения сквозь брандмауэры, со своим опытом общения с ними. Когда я смотрел, что пишут мои соотечественники на данную тему, я обнаружил одну неприятную особенность,: подавляющие большинство автором просто нагло копировало статью МЛена из журнала Хакер. Из этого был сделан вывод, что полного рассмотрения данной темы до сих пор нет, поэтому-то и родилась данная статья. Какой я скромный, правда?




Ладно, пропустим лирику и перейдем к делу.
У системного администратора есть несколько возможность обеспечить безопасность своей сети. Первое это контролировать доступ с помощью TCP Wrappers или сервера xinetd. А вторая воспользоваться брандмауэром.
Для сравнение этих двух способов можно привести очень хорошую цитату Брайана Хатча:
"Брандмауэр в Linux это тоже самое, что брандмауэр в здании - не дает огню попасть в другую часть здания, TCP Wrappers - это нечто покрытия асбестом, когда огонь совсем рядом, но ты защищен". Отсюда вполне логично сделать вывод, что лучше чтобы огонь был наиболее удален от тебя.
Прежде чем начинать разговор о чем-либо необходимо дать определение обсуждаемому вопросу. Итак, брандмауэр это устройство или программа позволяющие анализировать входящие и исходящие сетевые пакеты, и производить их дальнейшую обработку в соответствии с заранее заданными правилами.



В ядрах линукса 2.4 для создания брандмауэра используется программа netfilter, а для управления ею iptables.
Правда раньше в 2.2 исользовался ipchains, но в настоящее время он практически не используется.
Фильтр пакетов анализирует заголовок полученного пакет и дальше поступает с ним в зависимости от установленных правил, то есть принимать, отклонять или запрещать.

Прием пакета:
/sbin/iptables -A INPUT -i [интерфейс] -s [ип, для которых применяется правило, для всех: 0/0] -d [my_IP] -p
[протокол] \ --dport [порт или служба] -j ACCEPT


Ответ при подключении:
[root@localhost k0r0l]# telnet 192.168.1.2 10000
Trying 192.168.1.2...
Connected to 192.168.1.2 (192.168.1.2).
Escape character is '^]'.


Отклонение пакета:
/sbin/iptables -A INPUT -i [интерфейс] -s [ип, для которых применяется правило, для всех: 0/0] -d [my_IP] -p
[протокол] \ --dport [порт или служба] -j REJECT


Ответ при подключнии:
[root@localhost k0r0l]# telnet 192.168.1.2 10000
Trying 192.168.1.2...
telnet: Unable to connect to remote host: Connection refused


Запрет пакета:
/sbin/iptables -A INPUT -i [интерфейс] -s [ип, для которых применяется правило, для всех: 0/0] -d [my_IP] -p
[протокол] \ --dport [порт или служба] -j DROP


Ответ при подключении:
[root@localhost k0r0l]# telnet 192.168.1.2 10000
Trying 192.168.1.2...





Как видно из приведенных записей можно сразу определить, что сеть защищена брандмауэром, если пакет отклоняется.
Второй метод обнаружения - невозможность пропинговать компьютер, хотя мы точно знаем, что он жив.
[root@localhost k0r0l]# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.

--- 192.168.1.2 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss

Настройки iptables в этом случае выглядят так:
/sbin/iptables -A INPUT -i [интерфейс] -s [ип, для которых применяется правило, для всех: 0/0] -d [my_IP] -p
icmp \ --icmp-type echo-request -j DROP



И третий метод - при попытке выполнить команду traceroute к назначенному компьютеру окажется, что адреса маршрутиризаторов закрыты звездочками.
[root@localhost k0r0l]# traceroute 192.168.1.2
traceroute to 192.168.1.2 (192.168.1.2), 30 hops max, 38 byte packets
1 * * *

Правила так:
/sbin/iptables -A INPUT -i [интерфейс] -s [ип, для которых применяется правило, для всех: 0/0] -d [my_IP] -p
udp \--dport 33435:33525 -j DROP




Существует простое жизненное правило: чем сложнее операция, тем легче совершить ошибку при ее выполнении. Давайте рассмотрим некоторые ошибки при составлении правил фильтрации.
Во-первых, необходимо пояснить , что правила фильтрации лежат в файле /etc/sysconfig/iptables.conf.
Порядок записи имеет основное значение. Например, если сначала прочитается правило запрета всех пакетов, то остальные правила будут неиспользуемыми. Поэтому сначала идет общая политика системы, потом конкретные правила, а далее запрет всех остальных пакетов (в лучшем для системного администратора и худшем для нас случае). В таком случае для успешного проникновения обычным перебором портов (ну или с помощью nmap) узнать на какие порты разрешено соединение. К слову, надо заметить, что не все сисадмины такие расторопные как их вышеописанный коллега. Очень часто при анализе доступных из сети портов становиться видно несколько мертвых портов, то есть на нем не висит никакой сервис, однако он доступен в настройках брандмауэра. так произошло однажды со мной, о чем я ниже напишу более подробно.

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

Помимо проникновения путем поиска ошибок в составлении правил фильтрации можно воспользоваться таким бездонным, с точки зрения багов, корытом как веб-скрипты. Банальная ошибка типа включения постороннего файла приводит прямо к катастрофическим последствиям. Поясняю: найдя инклюд-баг можно выполнять команды на сервере с привилегиями юзера www (то есть того от чьего имени работает веб-сервер). В этом случае мы уже обошли брандмауэр и теперь наши пакеты не фильтруются. Дальше у юзера есть очень много вариантов по закреплению в системе, но это уже другая история.
Однако и этот метод проникновения можно пресечь путем анализа содержимого пакетов. В ядро можно добавить заплатку, позволяющую осуществлять данную фильтрацию (совпадение строки запроса с заданным шаблоном). Для этого необходимо перекомпилить ядро с флагом CONFIG_IP_NF_MATCH_STRING (по умолчанию в большинстве версий не стоит).

Однако помимо брандмауэра netfilter существует много других программ, позволяющих организовать защиту компьютера. И во всем этом многообразие присутствует некоторое количество дыр, как на уровне работы с пакетами, так и при составлении правил. То есть послав определенный пакет на определенный брандмауэр можно вывести его из строя. Перечислять дырки в этой статье не имеет смысла, так как версии программ постоянно обновляются и статическая информация быстро устаревает. Ну а если говорить о типах дырок, то это, в основном, "гонка на выживание" и переполнение, хотя встречаются и экзотические варианты типа забыть проверить правильность запроса настроек брандмауэра (пример AS/400 от IBM).
Кстати получить версию об установленной огненной стене, можно не только анализируя ответы или подбирая запросы, характерные только данному виду брандмауэров, иногда для этого достаточно пообщаться с пользователями из сетки, в которую вы хотите попасть. Пример: многие админы от нечего делать часами сидят на различных форумах обсуждая тонкости настройки систем (сам этим грешу), и частенько можно увидеть фразы типа "а у меня с моим squid-ом ваще проблем нет". Или работодатели ищут человека, "разбирающегося в администрировании файрволлов ZyXel".



Теперь в качестве наглядного примера расскажу о случае, произошедшем со мной:
Наружу открыт один лишь вебсервер, остальные порты закрыты. Естественно пытаться попасть внутрь надо через вебсервер, так как других путей не видно. Сам сервер оказался довольно хорошо настроенным и популярных дырок при его рассмотрении замечено не было. Следовательно копать надо в скриптах. Дырка обнаружилась довольно быстро (просмотр любого файла). Далее было просто, в начале поискал правила брандмауэра и оказалось что наружу был доступен еще один порт 8080, видимо админ пока настраивал сайт держал на этом порте тестовую или вспомогательную версию апача, потом его снес, а правило удалить забыл. Командой wget я закачал скомпиленную версию netcat и одной строчкой открыл туннель наружу через этот самый 8080 порт. Получив таким образом шелл с правами юзера www я мог продолжить изучение машины... Впрочем это к делу не относиться, так как брандмауэр мы уже прошли.

На этом и завершая мою статью, пишите ваши комментарии и вопросы.



K0r0l

Автор: K0r0l , @ , WWW