Михаил Флёнов - Linux глазами хакера

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

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

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

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

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

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

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

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

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

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

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

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

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

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