Linux глазами хакера

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

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

Следующий способ защиты заключается в уменьшении времени действия неактивного соединения. В некоторых программах есть возможность в конфигурационных файлах установить длительность неактивного соединения. Убавив это значение до 10 секунд, сервер не получится загрузить SYN-пакетами. Пока образуется очередь подключений, первые соединения уже будут разрываться. Конечно же, могут возникнуть проблемы и неудобства у добропорядочных пользователей, которым, возможно, придется лишний раз устанавливать соединение с сервером, но, по крайней мере, работа не остановится.

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

14.6.4. TCP flood

Эта атака аналогична ICMP flood. Если не помогает смекалка, и хакер не может найти уязвимого места, то начинается засыпание сервера бессмысленными TCP-пакетами. Их эффективность иногда даже ниже ICMP-пакетов. Если в случае использования ping-запросов сервер обязан вернуть пакет с такими же данными, то в TCP-протоколе это не обязательно. Таким образом, канал связи у хакера должен быть идентичным, а то и больше, чем у атакуемой системы.

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

Можно использовать скачивание большого файла по протоколу HTTP. Множество таких запросов при плохой организации кэширования на сервере также могут привести к зависанию.

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

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

14.6.5. UDP

Ошибки в программах, ориентированных на UDP, наиболее опасны, потому что этот протокол не использует виртуального соединения. По нему пакеты просто отправляются по сети, и нет никаких механизмов проверки достоверности указанных данных. Если при использовании TCP подделать IP-адрес достаточно сложно, то с помощью UDP-протокола это реализуется элементарно.

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

14.6.6. DDoS

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

С другой стороны, реализовать действительно массовую атаку DDoS очень сложно, и крупные компании были даже уверены, что это практически невозможно. Даже очень большая группа хакеров на самых быстрых каналах не сможет получить в свое распоряжение такие вычислительные ресурсы, как у серверов yahoo.com, googIe.com или microsoft.com. Но хакеры находят новые способы. Мало кто из пользователей добровольно отдаст мощность своего компьютера для проведения распределенной атаки на крупные серверы. Чтобы решить эту проблему, хакеры пишут вирусы, которые без разрешения занимаются захватом.

Ярким примером удачной распределенной атаки является червь MyDoom. Этот червь, начиная с 22 августа 2003 года, в течение трех дней атаковал сайт компании SCO со всех зараженных в Интернете компьютеров. Через некоторое время подобную атаку пытались реализовать через вирус MyDoom В, но на серверы компании Microsoft. Вторая атака оказалась менее эффективной, но я это связываю с тем, что меньшее количество компьютеров в Интернете было заражено этим вирусом, поэтому мощности не хватило для проведения полноценного налета, да и код червя был далек от идеала.

Нередко для реализации DDoS хакеры используют захваченные мощные серверы на высокоскоростных каналах связи. Это позволяет злоумышленнику получить необходимые ресурсы для удачной распределенной атаки.

В будущем можно ожидать новые атаки DDoS, которые окажутся более эффективными и оригинальными. Здесь уже администратор будет бессилен, и в данном случае на помощь должны приходить правоохранительные органы.

14.6.7. DoS

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

О переполнении буфера мы уже говорили в разд. 14.2 и знаем, что с этими ошибками можно бороться, даже не дожидаясь исправлений программистами. Достаточно только поставить патч на ядро ОС, при котором запрещено выполнять код из стека.

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

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

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