DiBR
обычная кошмарная
домашняя страничка
Ежекакполучится околокомпьютерное обозрение
 
  <<<  предыдущий 17 июня 01 года следующий  >>>  
   Последний выпуск       Архив       Ссылки       Полезности       humor.filtered       О сайте   
          На гуру все спокойно. На багрепорт пришел ответ "спасибо за информацию, мы обязательно проверим", а Sony J5 по прежнему имеет длину 88мм. Ждем-с.
          Плохо быть еженедельщиком. Темы кончились. Ну и ладно. Будут старые темы. Скажем, про товарища Гибсона со спуфингом, виндами и микрософтом. Я и не знал, что он оказывается культовая личность - я вообще из культовых знаю Ленина, Леннона, Сталина и Столмана. И что он очень умный и умелый я не спорю - такой троян расковырял, да еще с хакерами побеседовал. И идея-то у него ясная и понимаемая - заткнуть хотя бы одну дырку для DDoS атак, раз уж другие не затыкабельны. Вот только винды от этого спуфить не разучились, а я до сих пор считаю, что линукс все равно опаснее. Ибо чайники не кончатся никогда, "шелл под линуксом" для среднего "хакера" более привлекателен чем какие-то винды, "ломают" линукс уже вполне массово, и будут ломать и дальше. Плюс - рост популярности упомянутого линукса...
          Кстати, о SYN-flood :-)
          Для начала скажу, что защититься от "флуда", если таковой достаточно мощный (заметно толще вашего собственного канала), идет со "случайных" адресов и "похож" на настоящий трафик (grc.com повезло, что их DDoS'или легко фильтруемым udp и icmp трафиком - а если бы в самом деле syn-flood?) - защититься от него нельзя. Против лома нет приема, кроме другого лома, большего размером, а против взвода стройбата с ломами у каждого - ломов не напасешься. Однако кое от чего защититься можно.
          Если физически "забит" внешний (до файрволла) канал - то тут уже не сделаешь ничего, в принципе. Если канал не забит - можно попытаться "отфильтровать" трафик по каким-нибудь признакам. Закрыть ненужные протоколы, запретить пакеты от несуществующих соединений, и тому подобное. Веселее получается в случае SYN-flood'а, которым можно (было?) не напрягаясь "покласть" небольшой сервер с модема, не отвлекаясь на поиски толстых каналов.
          Рассмотрим типичную реализацию взаимодействия клиента, сервера (ОС), сервиса (программы, обрабатывающей запрос клиента) в рамках tcp/ip. Фактическим стандартом на реализацию сокетного API являются "Berkley sockets" с теми или иными вариациями, и программы, естественно, пишутся используя то, что есть. Ну, а сам tcp/ip - он стандартен и един, иначе ничего бы и не работало.
          Итак, взаимодействие. Клиент устанавливает tcp-соединение с сервером, делает "запрос", сервис обрабатывает запрос и дает ответ.
          Установка tcp-соединения идет в три этапа. Клиент посылает серверу пакет "хочу" - tcp syn. Сервер посылает в ответ tcp syn-ack ("хочешь - бери") и ждет ответа tcp ack ("понял, не дурак"). С этого момента соединение считается установленным, и по нему можно гонять данные.
          Сервис, желающий принимать соединения на каком-нибудь порту, зовет функцию listen() и начинает "слушать" этот порт. По приходу SYN на этот порт, сервису тем или иным методом ("тушкой, чучелом", select(), WSA_*(), событие, сигнал, еще как) сообщают, что "клиент пришел". Сервис, в соответствии со своими понятиями о загруженности, решает - принять или отбить, и в случае если можно "принять" - вызывает на этот сокет accept(). Сервис получает "сокет" - сущность, через которую он, сервис, будет коммуницировать :-) с клиентом, и предпринимает сообразные этому действия - заводит структурку, ответственную за работу с клиентом, форкается, создает нить, или передает данные одному из pre-forked процессов, или просто опрашивает этот сокет в главном цикле обработки... в любом случае - расходует драгоценные ресурсы, поскольку для сервиса соединение уже состоялось, таблицы заполнены, ждем только запроса клиента.
          ...после вызова accept(), система посылает syn-ack и ждет ack. Ждет до таймаута, который может измеряться минутами, и только после этого "ресетит" сокет. Всё это время в сервисе "висит" полуоткрытый сокет, в позе "не умер - и не хоронят". Поскольку syn-пакет маленький, сервисы не так уж часто позволяют иметь больше нескольких тысяч одновременных соединений, а таймаут измеряется минутами - можно ввести сервер в состояние кататонии с обычного модема, не утруждая себя поиском толстого канала или еще чего-нибудь такого.
          Посмотрим, можно ли от этого защититься. В принципе - можно! Не защититься правда, а так, "смягчить удар", но можно. Пусть есть файрволл. Приходящие syn-пакеты он (файрволл) "не пущает", сам отсылает syn-ack, и сохраняет в табличке чего и куда он послал. В случае получения ack на свой syn-ack, файрволл посылает серверу syn, и далее транслирует tcp-сессию между клиентом и сервером через себя. В результате "поддельные" syn-пакеты до сервера не доходят вообще, а на каждый syn расходуется десяток байт памяти файрволла - "когда, куда, откуда, чего хотел, чего ответили". От классического син-флуда, который можно делать хоть с модема, это спасает. От более мощного - уже нет, поскольку память-то все-таки расходуется, хотя и менее катастрофически и на файрволле а не на сервере.
          Короче, всё плохо, и скоро будет ещё хуже. И все мы беззащитны перед интернетом. Аминь :-)
          Книжка Огурцова и Горина "соблазнение" - лежит на http://www.artex.nsk.su/kbv/lib2/Pickup/Soblazn/Soblazn.rar. Может, пригодится кому.
          Hitachi разработала прототип "бескнопочного" устройства Работающая моделъ устройства была названа "Waterscape", на данный момент она может приниматъ и передаватъ информацию. "Бескнопочный" дизайн обьясняется желанием компании создатъ простой и понятный с первого взгляда интерфейс. Устройство имеет сенсор, реагирующий на ускорение, и способно отображатъ различный контент, включая текст, неподвижные изображения, или музыку. Его размер ~10 см в диаметре. Сенсор ускорения может восприниматъ отклонения по Х и У осям. Выбранная информация предстает в виде "пузыръка", выплывшего на поверхностъ. При приближении к центру экрана "пузырек" лопается, и выбранный котнент выводится на дисплей. Для закрытия документа или приложения полъзователъ должен некоторое время силъно потрясти прибор. К сожалению, Hitachi пока не имеет планов коммерциализации подобных устройств.
          И слава богу. "Для завершения звонка некоторое время сильно потрясите свой телефон"...




<<<

архив

>>>

Версия для печати.