Дни открытых дверей
2 февраля 2004
Рубрика: Интернет и сети.
Автор: .
pic

Когда заводишь разговор о защите сетевых ресурсов, то чаще всего можно услышать мнение о том, что, якобы, надо ставить брандмауэр1 и закрывать порты2 от сканирования. Давайте разберемся, а так ли это на самом деле? Может ли файрвол дать реальную защиту или же, наоборот, служит в качестве успокоительного средства, притупляя бдительность. А что если поступить наоборот и устроить дни открытых дверей, допустив к сокетам всех желающих? В таком случае, как и ко всякому подобному мероприятию, следует тщательно подготовиться. Каким образом? Об этом и пойдет речь в статье.

Cуществует общераспространенное мнение, что за файрволом, как за каменной стеной, и администратору можно спать спокойно, так как служба идет, бухгалтер зарплату считает, а хакер в испуге под стол спрятался. На самом деле, если очень неймется, то TCP-порты в Unix можно прикрыть гораздо более примитивным демоном3 — tcpd. Другой вопрос, а нужно ли? Ведь их функции не столь бесполезны, чтобы на них вешать всякие замки и прочие кандалы? Что в первую очередь делает системный администратор? Отключает telnet, ftp c анонимным доступом и другие «опасные» сервисы. Дело иногда доходит до крайностей. Многие наши провайдеры завели моду отключать внешний доступ к почтовой службе POP3, мотивируя это «защитой» от хакеров. Таким образом, они лишь распугивают своих клиентов. Ведь в этом случае, оказавшись за пределами прямого доступа к серверу, пользователь лишается возможности получения своей личной почты из ящика, который, по утверждению того же «заботливого» провайдера, выделяется бесплатно и в довесок к уже оплаченным услугам. А что касается хакера, то при «необходимости» поломать почтовый сервер он сможет осуществить эту затею на вполне «законных» основаниях, заплатив деньги за трафик и употребив этот самый трафик в целях взлома.

pic

Почему же многие предполагают, что закрытые порты способны что-нибудь защитить? Скорее, от безграмотности и незнания принципов работы сети. В Unix, с точки зрения системы, практически ничего не рассчитано на пользователя — человека. Почему? Да потому что эта ОС — многопоточная и все в ней сплошные потоки: файлы, которые во всех каталогах, драйверы устройств в каталоге /dev и даже процессы в каталоге /proc. Не говоря уже о том, что политика пользователей и групп распространяется на системные службы, которые зарегистрированы юзерами и распределены по группам, по спискам /etc/passwd и /etc/group сразу же после администратора. Что касается реального двуногого пользователя, то он общается с системой только посредством этих самых потоков. Поэтому для самой системы нет никакой разницы, что за пользователь с ней общается — будь то ламер, хакер или системный администратор, принтер или служебный демон. Она видит лишь управляемые ими потоки, включая консольные, и если текущий поток имеет права доступа, тогда открываются ресурсы или же, в противном случае, выдается и логируется соответствующее сообщение.
Давайте рассмотрим, что может сделать файрвол? С его помощью можно оставить открытыми порты для одних IP-адресов, прикрыв их для остальных. Ну, конечно же! Кто бы спорил? Что делают в таких случаях хакеры, например печально известный Кевин Митник? Спуфинг. Заходят в сеть и подменяют IP-адрес своего хоста на тот IP, которому уже многое разрешено в правилах файрвола. И что тут сможет сделать брандмауэр, как не просто задерживать IP-пакеты, фильтруя их через многочисленные правила, причем все подряд, при этом пропуская все хакерские без проблем? И файрвол есть, и свои функции выполняет, задерживая трафик. И злоумышленник тоже есть, который свои функции также реализует. Вот только для чего же здесь этот самый брандмауэр нужен, если он при этом пускает всех, кого ни попадя?
Приведу простейший пример, который удалось услышать у знакомого администратора. Поставили клиентам RadioEthernet4. В этом случае сам провайдер настраивает сервер клиента и административные права оставляет за собой, а клиенту — лишь пользовательские. Вроде бы, никаких казусов возникать не может. Но спустя некоторое время руководство одной организации — клиента стало жаловаться, что им приходится платить лишние деньги, так как, согласно штатному расписанию, по ночам никто не работает и даже сервер выключен, но, несмотря на это, по логам провайдера в это время идет закачка трафика. Стали выяснять. И как оказалось, нашелся среди пользователей и такой, который не только догадался о возможностях спуфинга, но и реализовал их. Кто виноват? Системный администратор. Почему? Потому что он не предпринял мер против такой атаки на хост клиента.

pic

Согласно спецификации RFC-826, любой Ethernet работает совместно с протоколом ARP, точнее, без этого протокола он вообще работать не будет. У каждого Ethernet интерфейса помимо IP-адреса есть еще и аппаратный, то есть MAC-адрес размером в 6 байт. Первые байты — это идентификатор производителя устройства, а последние — серийный номер устройства, выпущенного данным производителем. Поэтому в одной сети не может быть двух интерфейсов с одинаковыми аппаратными адресами. Основное предназначение данного адреса заключается в том, чтобы устройства Ethernet могли общаться друг с другом с помощью транспортных протоколов, обращаясь друг к другу по этим самым адресам. В TCP/IP и любом другом сетевом протоколе также есть своя адресация, не соответствующая аппаратной, для чего и разработан протокол ARP, который позволяет привязать аппаратный адрес к IP-адресу и тем самым объединить оба протокола в одну коммуникацию.
Чтобы было понятнее, лучше расписать принцип действия. Если с какого-либо хоста необходимо отправить дейтаграмму для другого хоста с определенным IP-адресом назначения и если оба эти хоста в одной сети, а следовательно, объединены одним аппаратным уровнем коммуникации, то нужно найти в этой сети интерфейсное устройство с вышеозначенным IP и передать ему информацию, но уже по протоколу Ethernet. Чтобы передать по протоколу Ethernet, нужно вызвать этот самый интерфейс на аппаратном уровне. Для этого протокол ARP просматривает свою таблицу в поисках привязки соответствующего IP к MAC-адресу. Если таблица содержит такую запись, то остается лишь вызвать соответствующий интерфейс по его аппаратному имени и передать дейтаграммы. В противном случае, делается широковещательный запрос для всех Ethernet интерфейсов в сети на предмет принадлежности к данному IP. На этот запрос обязан ответить лишь тот интерфейс, который к данному IP привязан. После чего в динамические таблицы ARP обоих хостов добавляются соответствующие записи с той самой целью, чтобы каждый раз не делать широковещательных запросов, а сразу же отправлять информацию по назначению. Широковещательный запрос может быть послан и в том случае, если устройство с уже известным по динамической записи в таблице аппаратным адресом не отвечает ни на какие запросы. Но это понятно, так как любой желающий, а не только администратор может поменять IP-адрес своего хоста, если знает, как это сделать, и имеет соответствующий доступ. Правильнее было бы сказать, что надеяться на то, что пользователь не сможет изменить IP-адрес по меньшей мере наивно, а по большому счету глупо. Если также учесть, что сетевые ресурсы не для всех распределяются поровну, то рано или поздно найдется желающий отхапнуть себе чуть поболее того, что ему выдал системный администратор.
Вполне очевидно, что файрвол в данном случае помочь ничем не сможет.
Но если бы протокол ARP имел только динамические записи в таблице, то спуфинг стал бы основной бедой системных администраторов. Поэтому разработчики данного протокола предусмотрели еще и статические. Задаются они, что в Unix, что в Windows одинаково, а именно:

# arp-s IP_address Mac_address
Статическая запись создается вручную и не может меняться в процессе функционирования сети ARP-протоколом, даже если она не соответствует действительности. Следует также учесть, что при перезагрузке системы таблица ARP очищается и в динамической, и в статической части, поэтому желательно всю статику заведомо прописать единым скриптом и добавить вызов этого скрипта из соответствующих загрузочных файлов /etc/rc.d/rc.*. Собрать список аппаратных адресов в сети можно очень простым методом, а именно пропинговать подключенные к сети хосты, после чего запустить команду:

# arp > arp.log
и из файла arp.log уже соорудить соответствующий скрипт. После чего останется только проверить его реальные возможности, временно заменив на каком-либо хосту IP на любой статический и попробовать пропинговать сервер. Пинги проходить не должны. Точнее, приветы до сервера приходят, но ответы должны были бы отправиться только по тому адресу, который прописан в статической табличке, то бишь в никуда, так как адрес был изменен.

pic

Конечно же, можно и аппаратный адрес подделать. Но не всегда и не везде, так как для этого нужно иметь соответствующие утилиты и времени на это нужно гораздо больше, чем на подмену IP.
Есть еще одно заблуждение, в котором утверждается, что, якобы, в Unix «не бывает» вирусов. Во-первых, все основные вирусные «технологии» были отработаны именно в Unix, откуда они и пошли вслед за печально известным «Червем Морриса». Во-вторых, основным орудием хакеров до сих пор остаются «Трояны», которые и являются по классификации вирусами. Ну, а в-третьих, применяемые для атак на Unix вируса это не дешевенькие поделки из специально созданных для таких целей компанией Microsoft ActiveX компонентов. «Трояны», «Черви», «Бомбы» — это хорошо спланированные, прекрасно маскирующиеся и даже уничтожающие сами себя при попытках обнаружения процессы. Их цели не в разрушении ОС, поскольку при этом они теряют свое основное предназначение, а в незаметном получении доступа к ресурсам или выуживании необходимой для этого информации. Поэтому не стоит путать вандальские, наспех сляпанные поделки для Windows с тщательно продуманными и профессиональными образцами для Unix. Чего в Unix не проходит, так это компьютерный вандализм, поскольку здесь автор вируса может поразить лишь свои собственные ресурсы.
Чтобы защищаться от атак, надо понимать их механизм. Как я уже говорил, Unix — многопоточная система, а следовательно, все права доступа рассчитаны только на потоки. Процессы обрабатывают и создают потоки, но, как правило, соблюдая ограничения, согласно которым, нельзя превышать привилегии и передавать им только такие же или гораздо меньшие права. Исключением из этого правила являются лишь процессы, которые могут запускаться с передачей прав владельца пользователю. Но даже они не представляют особой опасности, так как хорошо известны и к тому же доступ к ним можно разграничить с помощью политики групп. Наибольшую опасность представляют те процессы, которые по долгу своей службы вынуждены запускаться только с высокими привилегиями и создавать привилегированные потоки, в том числе и для непривилегированных пользователей. Например, sendmail — любимая почтовая служба хакеров. Соответственно, задача хакера в том и состоит, что, имея птичьи права, подсунуть привилегированному процессу какой-нибудь скрипт5, который, будучи запущенным, выполнится с правами, превышающими авторские. Функции файрвола и здесь абсолютно бесполезны.
Зато есть другая, весьма полезная сетевая служба, которая именуется NAT (Network address translator. Спецификация RFC 1631) и давно присутствует в Unix, но не все ее используют. Принцип ее действия состоит в том, что, будучи поднятой на одном хосту, она может ловить пакеты, предназначенные для одного из своих портов, но все запросы форвардить6 на удаленные службы. А также обратно отправлять ответы удаленных служб клиентским сокетам, но только от своего имени. Своего рода посредник. Зато какой! Это вам не спекулянт по торговле недвижимостью. Основное удобство NAT в том, что с ее помощью можно очень быстро подменить упавшую службу резервной. Естественно, что никто даже и не заметит подмены, хотя новый хост будет иметь уже совершенно иной IP-адрес. Второе удобство — это защита сетевых служб от атак. Давайте посмотрим, как это осуществляется? Для того чтобы атаковать какую-либо службу, необходимо, чтобы ее процесс создал и обработал соответствующий хакерский поток. Для этого необходимым и достаточным условием является локализация этот самого потока и атакуемой службы на одном и том же хосту. А тут, когда мы транслируем службы через NAT, они оказываются разнесенными по разным хостам. Хотя тот же хакер, сканируя порты, видит их на одном. Очевидно, что, даже создав скрипт и субъективно «подсунув» его какому-либо привилегированному процессу, злоумышленник попросту ошибается, так как процесс, на который все рассчитывалось, в реальности оказывается изолированным от потока. Также можно различные сетевые службы разместить в сети с локальными адресами, получив тем самым дополнительную финансовую экономию на интернет-адресах. Плюс весьма эффективное резервирование и дублирование наиболее важных сервисов. Вот и весь секрет фокуса.
Таким образом, выясняется, что закрывать серверные сокеты от сканирования — это пустая трата времени, коли защитные функции при этом близки к нулю целых шишь десятых процента, не говоря о бесполезных задержках трафика. Наиболее эффективным, как мы выяснили, является обратное. Причем лучше всего разместить на неиспользуемых портах различные простенькие эмуляторы наиболее опасных служб, которые вроде бы и отвечают на клиентские запросы, но очень медленно и тщательно логируя коннекты. Ведь иногда полезнее заведомо знать, что кто-то лезет туда, куда его не просили лезть, чем узнать об этом тогда, когда будет уже слишком поздно.
Вполне очевидно, что NAT — это не панацея, так как практически не существует эффективной защиты от атак на отказ.
Конечно же, можно было бы расписать еще множество различных хитростей и приемов, но боюсь, что на все это не то чтобы журнала, но и нескольких томов не хватит. Да и зачем все это расписывать? Ведь в любом деле самое главное — это компетенция. Если знать принцип действия того или иного механизма, то всегда можно найти и устранить в нем неисправность. Если не знать, то можно только усугубить.

pic

Примечания:

1. Брандмауэр (нем. Brandmauer Brand пожар + Mauer — стена) — глухие, огнестойкие стены, с помощью которых отделяют одни части зданий от других с целью локализации распространения пожаров. То же самое значение имеет Файрвол ( англ. Firewall < fire огонь + wall стена). Еще одно значение данных терминов относительно информационных технологий, защитная программа, перекрывающая внешний доступ к сетевым сокетам. Существует целый ряд подобных программ, среди которых наиболее распространены: ipfwadm и ipchains. 2. Порты, каждый хост помимо IP-адресации имеет еще и 65536 портов TCP и столько же UDP, на каждый из которых можно установить различные сетевые сокеты (англ. - гнезда). Посредством сокетов клиентские и серверные приложения могут обмениваться информацией, передавая друг другу дейтаграммы (пакеты) и обращаясь друг к другу посредством адресации: IP-адрес и порт назначения. Своего рода аналогия с рядовой почтовой адресацией: номер дома, номер квартиры. 3. Демон (от англ. - daemon) - это не мифический персонаж, а резидентный процесс. Все службы - демоны помечаются с помощью окончания «d», например tcpd, httpd, ftpd, named и т.д. 4. Ethernet - коммуникационные устройства, которые могут работать «одновременно» на одном канале (одной частоте). 5. Скрипт - файл, содержащий последовательность команд в текстовом и пригодном для интерпретации виде. 6. Форвард - в информационных технологиях под этим термином подразумеваются не цели нападения или атаки, а перенаправляющие функции. Чаще всего это передача информационных данных той службе, которая наиболее компетентно их обработает.

Orphus system
Подписывайтесь на канал infoCOM.UZ в Telegram, чтобы первыми узнавать об ИКТ новостях Узбекистана
В Telegram
В Одноклассники
ВКонтакте