Каждый коммуникационный протокол оперирует с некоторой единицей передаваемых данных. Названия этих единиц иногда закрепляются стандартом, но чаще просто определяются традицией. В стеке TCP/IP за многие годы его эксплуатации образовалась устоявшаяся терминология в этой области (табл.3).
Табл.3. Единицы данных в стеке TCP/IP.
| I | ПРИКЛАДНЫЕ ПРОТОКОЛЫ(поток) | |
| II | UDP (дейтаграмма) | TCP (сегмент) |
| III | IP (пакет или IP-дейтаграмма) | |
| IV | СЕТЕВЫЕ ИНТЕРФЕЙСЫ(кадр(фрейм)) |
Потоком называют данные, поступающие от приложений на вход транспортного уровня TCP или UDP.
Протокол TCP нарезает из потока сегменты.
Единицу данных протокола UDP часто называют дейтаграммой (или датаграммой). Дейтаграмма - это общее название для единиц данных, которыми оперируют протоколы без установления соединений. К таким протоколам относится и протокол межсетевого взаимодействия IP.
Дейтаграмму протокола IP называют также пакетом.
В стеке TCP/IP принято называть кадрами (фреймами) единицы данных протоколов, на основе которых IP-пакеты переносятся через подсети составной сети. При этом не имеет значения, какое название используется для этой единицы данных в локальной технологии.
6. Сетевые анализаторы
Анализатор трафика, или сниффер (от англ. to sniff — нюхать) — сетевой анализатор трафика, программа или программно-аппаратное устройство, предназначенное для перехвата и последующего анализа, либо только анализа сетевого трафика, предназначенного для других узлов.
Сниффер может анализировать только то, что проходит через его сетевую карту. Внутри одного сегмента сети Ethernet все пакеты рассылаются всем машинам, из-за этого возможно перехватывать чужую информацию. Использование коммутаторов (switch, switch-hub) и их грамотная конфигурация уже является защитой от прослушивания. Между сегментами информация передаётся через коммутаторы. Коммутация пакетов — форма передачи, при которой данные, разбитые на отдельные пакеты, могут пересылаться из исходного пункта в пункт назначения разными маршрутами. Так что если кто-то в другом сегменте посылает внутри его какие-либо пакеты, то в ваш сегмент коммутатор эти данные не отправит.
|
|
Перехват трафика может осуществляться:
§ обычным «прослушиванием» сетевого интерфейса (метод эффективен при использовании в сегментеконцентраторов (хабов) вместо коммутаторов (свитчей), в противном случае метод малоэффективен, поскольку на сниффер попадают лишь отдельные фреймы);
§ подключением сниффера в разрыв канала;
§ ответвлением (программным или аппаратным) трафика и направлением его копии на сниффер;
§ через анализ побочных электромагнитных излучений и восстановление таким образом прослушиваемого трафика;
§ через атаку на канальном (2) (MAC-spoofing) или сетевом (3) уровне (IP-spoofing), приводящую к перенаправлению трафика жертвы или всего трафика сегмента на сниффер с последующим возвращением трафика в надлежащий адрес.
В начале 1990-х широко применялся хакерами для захвата пользовательских логинов и паролей, которые в ряде сетевых протоколов передаются в незашифрованном или слабозашифрованном виде. Широкое распространение хабов позволяло захватывать трафик без больших усилий в больших сегментах сети практически без риска быть обнаруженным.
Снифферы применяются как в благих, так и в деструктивных целях. Анализ прошедшего через сниффер трафика позволяет:
|
|
§ Обнаружить паразитный, вирусный и закольцованный трафик, наличие которого увеличивает загрузку сетевого оборудования и каналов связи(снифферы здесь малоэффективны; как правило, для этих целей используют сбор разнообразной статистики серверами и активным сетевым оборудованием и её последующий анализ).
§ Выявить в сети вредоносное и несанкционированное ПО, например, сетевые сканеры, флудеры, троянские программы, клиенты пиринговых сетей и другие (это обычно делают при помощи специализированных снифферов — мониторов сетевой активности).
§ Перехватить любой незашифрованный (а порой и зашифрованный) пользовательский трафик с целью получения паролей и другой информации.
§ Локализовать неисправность сети или ошибку конфигурации сетевых агентов (для этой цели снифферы часто применяются системными администраторами)
Поскольку в «классическом» сниффере анализ трафика происходит вручную, с применением лишь простейших средств автоматизации (анализ протоколов, восстановление TCP-потока), то он подходит для анализа лишь небольших его объёмов.
7. Меры защиты от снифферов
- настройка сетевого оборудования
- защита антиснифом
8. Безопасность протокола ARP
Методы защиты:
· Фиксация соответствий между IP и MAC адресами на каждом ПК сети при помощи скриптов из команд “ARP –s <IP address> <MAC address>”.
· Контроль соответствия сетевых пакетов при помощи ПО класса HIPS на каждом ПК сети.
· Контроль соответствия таблиц коммутации на уровне сетевых коммутаторов.
|
|
11. Атаки на протокол IP
Пассивные атаки на уровне TCP
При данном типе атак крэкеры никаким образом не обнаруживают себя и не вступают напрямую во взаимодействие с другими системами. Фактически все сводиться к наблюдению за доступными данными или сессиями связи.
Подслушивание
Атака заключаются в перехвате сетевого потока и его анализе (от англ. "sniffing"). Для осуществления подслушивания крэкеру необходимо иметь доступ к машине, расположенной на пути сетевого потока, который необходимо анализировать; например, к маршрутизатору или PPP-серверу на базе UNIX. Если крэкеру удастся получить достаточные права на этой машине, то с помощью специального программного обеспечения сможет просматривать весь трафик, проходящий через заданные интерфейс. Второй вариант -- крэкер получает доступ к машине, которая расположена в одном сегменте сети с системой, которой имеет доступ к сетевому потоку. Например, в сети "тонкий ethernet" сетевая карта может быть переведена в режим, в котором она будет получать все пакеты, циркулирующие по сети, а не только адресованной ей конкретно. В данном случае крэкеру не требуется доступ к UNIX -- достаточно иметь PC с DOS или Windows (частая ситуация в университетских сетях). Поскольку TCP/IP-трафик, как правило, не шифруется (мы рассмотрим исключения ниже), крэкер, используя соответствующий инструментарий, может перехватывать TCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователей и их пароли. Следует заметить, что данный тип атаки невозможно отследить, не обладая доступом к системе крэкера, поскольку сетевой поток не изменяется. Единственная надежная защита от подслушивания -- шифрование TCP/IP-потока (например, secure shell) или использование одноразовых паролей (например, S/KEY). Другой вариант решения - использование интеллектуальных свитчей и UTP, в результате чего каждая машина получает только тот трафик, что адресован ей. У каждой палки два конца. Естественно, подслушивание может быть и полезно. Так, данный метод используется большим количеством программ, помогающих администраторам в анализе работы сети (ее загруженности, работоспособности и т.д.). Один из ярких примеров -- общеизвестный tcpdump.
Активные атаки на уровне TCP
При данном типе атак крэкер взаимодействует с получателем информации, отправителем и/или промежуточными системами, возможно, модифицируя и/или фильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся технически сложными в реализации, однако для хорошего программиста не составляет труда реализовать соотвествующий инструментарий. К сожалению, сейчас такие программы стали доступны широким массам пользователей (например, см. раздел про SYN-затопление). Активные атаки можно разделить на две части. В первом случае крэкер предпринимает определенные шаги для перехвата и модификации сетевого потока или попыток "притвориться" другой системой. Во втором случае протокол TCP/IP используется для того, чтобы привести систему-жертву в нерабочее состоянии. Обладая достаточными привилегиями в Unix (или попросту используя DOS или Windows, не имеющие системы ограничений пользователей), крэкер может вручную формировать IP-пакеты и передавать их по сети. Естественно, поля заголовка пакета могут быть сформированы произвольным образом. Получив такой пакет, невозможно выяснить откуда реально он был получен, поскольку пакеты не содержат пути их прохождения. Конечно, при установке обратного адреса не совпадающим с текущим IP-адресом, крэкер никогда не получит ответ на отосланный пакет. Однако, как мы увидим, часто это и не требуется. Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак.
Предсказание TCP sequence number
Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в A Weakness in the 4.2BSD Unix TCP/IP Software Англоязычный термин -- IP spoofing. В данном случае цель крэкера - притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей -- например, для использовании SMTP жертвы для посылки поддельных писем.
Описание
Вспомним, что установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу sequence number (назовем его C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK) и собственный sequence number сервера (S-SYN). Теперь уже клиент должен выслать подтверждение (S-ACK). Схематично это можно представить так: После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для sequence number и acknowledge number. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи. Предположим, что крэкер может предсказать, какой sequence number (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет (возможно, с нескольких попыткок и с поправкой на скорость соединения) предсказать sequence number для следующего соединения. Если реализация TCP/IP использует специальный алгоритм для определения sequence number, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов. Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A"_ и оказаться на A, не вводя пароля. Предположим, что крэкер расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов. Первая задача крэкера - ввести систему B в состояние, когда она не сможет отвечать на сетевые запросы. Это может быть сделано несколькими способами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течении которых она будет неработоспособна, должно хватить. Другой вариант -- использование описанными в следующих разделах методов. После этого крэкер может попробовать притвориться системой B, для того, что бы получить доступ к системе A (хотя бы кратковременный).
- Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера.
- Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B.
- Система A отвечает пакетом с sequence number, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой sequence number был выслан системе B.
- Крэкер подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK(заметим, что если системы располагаются в одном сегменте, крэкеру для выяснения sequence number достаточно перехватить пакет, посланный системой A).
После этого, если крэкеру повезло и sequence number сервера был угадан верно, соединение считается установленным. Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла.rhosts или отправки /etc/passwd крэкеру по электронной почте.
Детектирование и защита
Простейшим сигналом IP-spoofing будут служить пакеты с внутренними адресами, пришедшие из внешнего мира. Программное обеспечение маршрутизатора может предупредить об этом администратора. Однако не стоит обольщаться - атака может быть и изнутри Вашей сети. В случае использования более интеллектуальных средств контроля за сетью администратор может отслеживать (в автоматическом режиме) пакеты от систем, которые в находятся в недоступном состоянии. Впрочем, что мешает крэкеру имитировать работу системы B ответом на ICMP-пакеты? Какие способы существуют для защиты от IP-spoofing? Во-первых, можно усложнить или сделать невозможным угадывание sequence number (ключевой элемент атаки). Например, можно увеличить скорость изменения sequence number на сервере или выбирать коэффициент увеличения sequence number случайно (желательно, используя для генерации случайных чисел криптографически стойкий алгоритм). Если сеть использует firewall (или другой фильтр IP-пакетов), следует добавить ему правила, по которым все пакеты, пришедшие извне и имеющие обратными адресами из нашего адресного пространства, не должны пропускаться внутрь сети. Кроме того, следует минимизировать доверие машин друг другу. В идеале не должны существовать способа, напрямую попасть на соседнюю машину сети, получив права суперпользователя на одной из них. Конечно, это не спасет от использования сервисов, не требующих авторизации, например, IRC (крэкер может притвориться произвольной машиной Internet и передать набор команд для входа на канал IRC, выдачи произвольных сообщений и т.д.). Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing'а (при условии, что используются криптографически стойкие алгоритмы). Для того, чтобы уменьший число таких атак, рекомендуется также настроить firewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющих адреса, не принадлежащие нашему адресному пространству. Это защитит мир от атак из внутренней сети, кроме того, детектирование подобных пакетов будет означать нарушение внутренней безопасности и может помочь администратору в работе.
IP Hijacking
Если в предыдущем случае крэкер инициировал новое соединение, то в данном случае он перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией "подслушивания" и IP spoofing'а.
Описание
Необходимые условия -- крэкер должен иметь доступ к машине, находящейся на пути сетевого потока и обладать достаточными правами на ней для генерации и перехвата IP-пакетов. Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов. Существует возможность ввести соединение в "десинхронизированное состояние", когда присылаемые сервером sequence number и acknowledge number не будут совпадать с ожидаемым значениеми клиента, и наоборот. В данном случае крэкер, "прослушивая" линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы. Метод позволяет полностью обойти такие системы защиты, как, например, одноразовые пароли, поскольку крэкер начинает работу уже после того, как произойдет авторизация пользователя. Есть два способа рассинхронизировать соединение:
Ранняя десинхронизация
Соединение десинхронизируется на стадии его установки.
- Крэкер прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии.
- Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента.
- Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN-пакет.
- Клиент игнорирует S-SYN-пакет, однако крэкер, прослушивающий линию, высылает серверу S-ACK-пакет от имени клиента.
- Итак, клиент и сервер находятся в состоянии ESTABLISHED, однако сессия десинхронизирована. Естественно, 100% срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие-то пакеты, посланные крэкером. Для корректной обработки этих ситуаций программа должна быть усложнена.
Десинхронизация нулевыми данными
В данном случае крэкер прослушивает сессию и в какой-то момент посылает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту (например, для telnet это может быть данные типа IAC NOP IAC NOP IAC NOP...). Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние.
ACK-буря
Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ... И так до бесконечности. К счастью (или к сожалению?) современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных, повторных передачи не происходит и "буря стихает". Как показали опыты, чем сильнее ACK-буря, тем быстрее она "утихомиривает" себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLIP - ненамного больше.
Детектирование и защита
Есть несколько путей. Например, можно реализовать TCP/IP-стэк, которые будут контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данному случае мы не застрахованы от крэкера, меняющего и эти значения. Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих ACK-бурь. Это можно реализовать при помощи конкретных средств контроля за сетью. Если крэкер не потрудиться поддерживать десинхронизированное соединение до его закрытия или не станет фильтровать вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство просто откруют новую сессию, не обращаясь к администратору. Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell) или на уровн протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP. Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на [rfc...], который требует молчаливого закрытия сесии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию. Для более глубокого ознакомления с этой атакой рекомендуется обратиться к IP Hijacking (CERT).
Пассивное сканирование
Сканирование часто применяется крэкерами для того, чтобы выяснить, на каких TCP-портах работают демоны, отвечающие на запросы из сети. Обычная программа-сканер последовательно открывает соединения с различными портами. В случае, когда соединение устанавливается, программа сбрасывает его, сообщая номер порта крэкеру. Данный способ легко детектируются по сообщениям демонов, удивленных мгновенно прерваным после установки соединением, или с помощью использования специальных программ. Лучшие из таких программ обладают некоторыми попытками внести элементы искуственного элемента в отслеживание попыток соединения с различными портами. Однако крэкер может воспользоваться другим методом -- пассивным сканированием (английский термин "passive scan"). При его использовании крэкер посылает TCP/IP SYN-пакет на все порты подряд (или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN/ACK-пакет, как приглашение продолжить 3-way handshake. Остальные вернут RST-пакеты. Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN/ACK-пакеты он может также ответить RST-пакетами, показывая, что процесс установки соединения продолжен не будет (в общем случае RST-пакетами автоматический ответит TCP/IP-реализация крэкера, если он не предпримет специальных мер). Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать:
- резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED. (при условии, что крэкер не посылает в ответ RST);
- прием от клиента RST-пакета в ответ на SYN/ACK.
К сожалению, при достаточно умном поведении крэкера (например, сканирование с низкой скоростью или проверка лишь конкретных портов) детектировать пассивное сканирование невозможно, поскольку оно ничем не отличается от обычных попыток установить соединение. В качестве защиты можно лишь посоветовать закрыть на firewall все сервисы, доступ к которым не требуется извне.
Затопление ICMP-пакетами
Традиционный англоязычный термин -- "ping flood". Появился он потому, что программа "ping", предназначенная для оценки качества линии, имеет ключ для "агрессивного" тестирования. В этом режиме запросы посылаются с максимально возможной скоростью и программа позволяет оценить, как работает сеть при максимальной нагрузке. Данная атака требует от крэкера доступа к быстрым каналам в Интернет. Вспомним, как работает ping. Программа посылает ICMP-пакет типа ECHO REQUEST, выставляя в нем время и его идентификатор. Ядро машины-получателя отвечает на подобный запрос пакетом ICMP ECHO REPLY. Получив его ping выдает скорость прохождения пакета. При стандартном режиме работы пакеты выслаются через некоторые промежутки времени, практически не нагружая сеть. Но в "агрессивном" режиме поток ICMP echo request/reply-пакетов может вызвать перегрузку небольшой линии, лишив ее способности передавать полезную информацию. Естественно, случай с ping является частным случаем более общей ситуации, связанный с перегрузкой каналов. Например, крэкер может посылать множество UDP-пакетов на 19-й порт машины-жертвы, и горе ей, если она, следуя общепринятым правилам, имеет на 19-м UDP-порту знакогенератор, отвечающий на пакеты строчками по 80 байт. Заметим, что крэкер может также подделывать обратный адрес подобных пакетов, затрудняя его обнаружение. Отследить его поможет разве что скоординированная работа специалистов на промежуточных маршрутизаторах, что практически нереально. Одной из вариантов атаки - посылать ICMP echo request-пакеты с исходным адресом, указывающем на жертву, на broadcast-адреса крупных сетей. В результате каждая из машин ответит на этот фальшивый запрос, и машина-отправитель получит больше количество ответов. Посылка множество broadcast-echo requests от имени "жертвы" на broadcast-адреса крупных сетей, можно вызвать резкой заполненение канала "жертвы". Приметы затопления - резко возросшая нагрузка на сеть (или канал) и повышение количество специфических пакетов (таких, как ICMP). В качестве защиты можно порекомендовать настройку маршрутизаторов, при которых они будут фильтровать тот же ICMP трафик, превышающие некоторую заданную заранее величину (пакетов/ед. времени). Для того, чтобы убедиться, что Ваши машины не могут служить источником ping flood'а, ограничьте доступ к ping.
Локальная буря
Сделаем небольшое отступление в сторону реализации TCP/IP и рассмотрим "локальные бури" на пример UDP-бури. Как правило, по умолчанию системы поддерживают работу таких UDP-портов, как 7 ("эхо", полученный пакет отсылается назад), 19 ("знакогенератор", в ответ на полученный пакет отправителю выслается строка знакогенератора) и других (date etc). В данном случае крэкер может послать единственный UDP-пакет, где в качестве исходного порта будет указан 7, в качестве получателя - 19-й, а в качестве адреса получателя и отправителя будут указаны, к примеру, две машины вашей сети (или даже 127.0.0.1). Получив пакет, 19-й порт отвечает строкой, которая попадает на порт 7. Седьмой порт дублирует ее и вновь отсылает на 19.. и так до бесконечности. Бесконечный цикл съедает ресурсы машин и добавляет на канал бессмысленную нагрузку. Конечно, при первом потерянном UDP-пакете буря прекратиться. Как недавно стало известно, данная атака временно выводит из строя (до перезагрузки) некоторые старые модели маршрутизаторов. Очевидно, что в бесконечный разговор могут быть вовлечены многие демоны (в случае TCP/IP может быть применен TCP/IP spoofing, в случае UDP/ICMP достаточно пары фальшивых пакетов). В качестве защиты стоит еще раз порекомендовать не пропускать в сети пакеты с внутренними адресам, но пришедшие извне. Также рекомендуется закрыть на firewall использование большинства сервисов.
Затопление SYN-пакетами
Пожалуй, затопление SYN-пакетами ("SYN flooding") - самый известный способ напакостить ближнему, с того времени, как хакерский электронный журнал "2600" опубликовал исходные тексты программы, позволяющие занятьсе этим даже неквалифицированным пользователям. Следует заметить, что впервые эта атака была упомянута еще в 1986 году все тем же Робертом Т. Моррисом. Вспомним, как работает TCP/IP в случае входящих соединений. Система отвечает на пришедший C-SYN-пакет S-SYN/C-ACK-пакетом, переводит сессию в состояние SYN_RECEIVED и заносит ее в очередь. Если в течении заданного времени от клиента не придет S-ACK, соединение удаляется из очереди, в противном случае соединение переводится в состояние ESTABLISHED. Рассмотрим случай, когда очередь входных соединений уже заполнена, а система получает SYN-пакет, приглашающий к установке соединения. По RFC он будет молча проигнорирован. Затопление SYN-пакетами основано на переполнении очереди сервера, после чего сервер перестает отвечать на запросы пользователей. Самая известная атака такого рода - атака на Panix, нью-йоркского провайдера. Panix не работал в течении 2-х недель. В различных системах работа с очередью реализована по разному. Так, в BSD-системах, каждый порт имеет свою собственную очередь размером в 16 элементов. В системах SunOS, напротив, такого разделения и нет и система просто располагает большой общей очередью. Соответственно, для того, что бы заблокировать, к примеру, WWW-порт на BSD достаточно 16 SYN-пакетов, а для Solaris 2.5 их количество будет гораздо больше. После истечение некоторого времени (зависит от реализации) система удаляет запросы из очереди. Однако ничего не мешает крэкеру послать новую порцию запросов. Таким образом, даже находясь на соединение 2400 bps, крэкер может посылать каждые полторы минуты по 20-30 пакетов на FreeBSD-сервер, поддерживая его в нерабочем состоянии (естественно, эта ошибка была скорректирована в последних версиях FreeBSD). Как обычно, крэкер может воспользоваться случайными обратными IP-адресами при формировании пакетов, что затрудняет его обнаружение и фильтрацию его трафика. Детектирование несложно -- большое количество соединений в состоянии SYN_RECEIVED, игнорирование попыток соединится с данным портом. В качестве защиты можно порекомендовать патчи, которые реализуют автоматическое "прорежение" очереди, например, на основе алгоритма Early Random Drop. Для того, что бы узнать, если к Вашей системе защита от SYN-затопления, обратитесь к поставщику системы. Другой вариант защиты - настроить firewall так, что бы все входящие TCP/IP-соединения устанавливал он сам, и только после этого перебрасывал их внутрь сети на заданную машину. Это позволит Вам ограничить SYN-затопление и не пропустить его внутрь сети.
12. Атаки ICMP
Протокол управляющих сообщений сети Интернет (ICMP – Internet Control Message Protocol) является популярным и широко используемым протоколом Интернета. Протокол обычно используется сетевыми компьютерами для отправки сообщений об ошибках.
Злоумышленники пытаются использовать уязвимости этого протокола в своих целях. Протокол ICMP разработан как средство передачи данных в одном направлении без аутентификации. Это позволяет злоумышленникам организовывать атаки типа «отказ в обслуживании» (DoS – Denial of Service).
Типичными примерами атак ICMP является множество пакетов ping, множество пакетов ICMP_ECHO или атака smurf. Компьютеры, подвергающиеся атаке ICMP, значительно замедляют свою работу (особенно это касается сетевых приложений), и у них возникают проблемы при установлении сетевых соединений.
13. Защита периметра
Первым уровнем обеспечения информационной безопасности, блокирующей несанкционированный доступ хакеров в корпоративную сеть, является межсетевой экран. Компания «Микротест» предлагает своим заказчикам межсетевые экраны различных производителей, нацеленных на защиту как небольших, так и крупных территориально-распределенных информационных систем. В зависимости от технологии обработки информации в организации межсетевые экраны (устройства защиты периметра) могут поставляться в различной комплектации и обеспечивать различный функционал, в том числе:
· Разграничение и контроль доступа, выполнение аутентификации пользователей, трансляция IP-адресов (NAT);
· Организация демилитаризованных зон;
· Построение различных типов VPN (IPSec и SSL VPN, в том числе сертифицированные по требованиям ФСБ России решения);
· Функционал контроля контента. Анализ трафика на прикладном уровне, защита трафика от вирусов и различных типов spyware и malware, защита от спама, URL-фильтрация, антифишинг, и пр;
· Функционал системы обнаружения и предотвращения сетевых атак и несанкционированной сетевой активности;
· Высокую доступность и кластеризацию;
· Балансировку нагрузки;
· Поддержка качества обслуживания (QoS);
· Механизмы аутентификации пользователей;
· Интеграцию с различными системами аутентификации и авторизации (RADIUS, TACACS+, LDAP и др);
· Управление списками контроля доступа маршрутизаторов;
· Ряд других возможностей.
Основным функционалом межсетевых экранов является разграничение и контроль доступа, трансляция адресов и сокрытие топологии вашей вычислительной сети от внешнего мира. Однако необходимо отметить, что межсетевые экраны главным образом осуществляют фильтрацию и анализ трафика на третьем и четвертом уровнях модели OSI, и лишь ограниченно - на более высоких уровнях.
Другим чрезвычайно важным функционалом межсетевых экранов является организация демилитаризованных зон. Это специально защищенные сегменты сети, к которым организован безопасный доступ из внешних сетей (Интернет) и в которых рекомендуется устанавливать сервера, взаимодействующие с внешними сетями - WEB, почтовый, DNS, и т.п.
Однако и сам межсетевой экран может служить мишенью для злоумышленников - так же, как и другие узлы вашей сети, начиная от серверов приложений и Web-серверов и заканчивая почтовыми узлами и базами данных. Для мониторинга и борьбы с атаками и несанкционированной сетевой активностью рекомендуется использовать специализированные продукты сетевые системы обнаружения и предотвращения атак (IDS/IPS). Данные системы позволяют отследить и зарегистрировать попытки несанкционированной сетевой активности и опционально блокировать атаки в режиме реального времени.
Максимально эффективно использовать данные, получаемые от сенсоров (серверов) обнаружения атак и от межсетевых экранов атаках (об отраженных ими атаках) позволяет использование системы мониторинга информационной безопасности. Система мониторинга ИБ позволяет свести все события и инциденты ИБ в единой консоли, выполняет интеллектуальный анализ атак и их последствий и помогает администраторам выработать контрмеры. Кроме этого, система мониторинга ИБ выполняет регистрацию и хранение всех событий информационной безопасности, что делает возможным использование полученного материала в качестве доказательного при выполнении расследований инцидентов и судопроизводстве.
Итак, базовые элементы защиты периметра - это межсетевые экраны (и VPN-серверы), системы обнаружения и предотвращения сетевых атак и системы мониторинга ИБ. Однако, как показывает практика, этих систем зачастую недостаточно для эффективной защиты от современных угроз они обеспечивают необходимый, но не достаточный уровень защищенности информационной системы. Существует ряд угроз и их становится все больше и больше, от которых указанные средства защиты малоэффективны. К таким угрозам относятся:
· проникновение червей, вирусов и другого вредоносного кода через электронную почту, web-сёрфинг и т.п. Как правило, данная зараза не определяется ни межсетевыми экранами, работающими на третьем уровне модели OSI, ни системами обнаружения сетевых атак. Ведь никакой атаки, например, в момент передачи файла, не производится;
· заражение пользовательских компьютеров, работающих через криптотуннель (например, внутри SSL-соединения с зараженным web-сервером или IPSec-соединения с зараженной сетью);
· атаки, использующие неизвестные уязвимости некоторых приложений.
По этим, и ряду других причин, для полноценной защиты корпоративной информационной системы недостаточно лишь межсетевых экранов (и систем обнаружения атак). В зависимости от особенностей конкретной защищаемой системы и требованиям к уровню защищенности, рекомендуется использовать и другие системы и методы защиты. Очень важно организовать эффективную защиту на уровне хостов (серверов и рабочих станций сети), контроль контента на периметре сети, контроль за утечкой конфиденциальной информации, и принять некоторые другие меры.
Более подробно о соответствующих технологиях, услугах и рекомендациях «Микротест» вы можете прочитать всоответствующих разделах нашего сайта.
Для чего?
Итак, защита периметра вычислительной сети с использованием предлагаемых компанией «Микротест» межсетевых экранов и систем обнаружения сетевых атак является базовой и необходимой защитой периметра информационной системы от посягательств злоумышленников, своеобразным "фильтром грубой очистки". Использование описанных технологий обеспечивает:
· Контроль и разграничение доступа на периметре сети;
· При необходимости аутентификацию пользователей;
· Сокрытие топологии и внутренней организации вашей вычислительной сети, что существенно усложняет задачи злоумышленников;
· Организация защищенного доступа внутренних пользователей во внешние сети и наоборот - пользователей внешних сетей к защищаемым внутренним ресурсам;
· Своевременное предотвращение, обнаружение и блокирование большей части атак, направленных на ресурсы информационной системы;
· Существенное повышение эффективности работы персонала, отвечающего за информационную безопасность, снижение издержек, возникающих от неэффективной работы;
· Масштабируемость инфраструктуры обеспечения информационной безопасности корпоративной сети;
· Централизованное управление средствами защиты, находящимися на различных участках корпоративной сети (в т.ч. и в удаленных филиалах);
· Качественный мониторинг и анализ событий информационной безопасности, облегчение работы специалистов по выработке ответных мер.
17. VPN
VPN (англ. Virtual Private Network — виртуальная частная сеть[1]) — обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет). Несмотря на то, что коммуникации осуществляются по сетям с меньшим неизвестным уровнем доверия (например, по публичным сетям), уровень доверия к построенной логической сети не зависит от уровня доверия к базовым сетям благодаря использованию средств криптографии (шифрования, аутентификации,инфраструктуры открытых ключей, средств для защиты от повторов и изменений передаваемых по логической сети сообщений).