RSS

Архив метки: guard

Мой рецепт по детектированию и блокированию аномального сканирования средствами iptables в Linux


Давно не писал сам, хочу исправиться.

Сегодня речь пойдет о детектировании и блокировки аномального сканирования средствами iptables в операционной системе Linux.

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

Нижеописанные правила собраны мною из различных, не русскоязычных, источников, но все вместе, в том виде, в котором они будут приведены мною, вы не найдете ни на одном ресурсе в сети Интернет. Впрочем информация, приведенная по тьюнингу сетевого стека Windows в разделе MS Platforms на данном сайте, также уникальна и нигде не встречается в том виде, в котором она дается мною.

Не буду зазря лить воду, перейдем к делу.

Предлагаю внести следующие изменения в ваши таблицы iptables:

iptables -A INPUT -p tcp —tcp-flags ALL NONE -j LOG —log-prefix «Stealth scan: 0STEAL «
iptables -A INPUT -p tcp —tcp-flags ALL NONE -j STEAL
iptables -A INPUT -p tcp —tcp-flags ALL ALL -j LOG —log-prefix «Stealth scan: 1STEAL «
iptables -A INPUT -p tcp —tcp-flags ALL ALL -j STEAL
iptables -A INPUT -p tcp —tcp-flags ALL FIN,URG,PSH -j LOG —log-prefix «Stealth scan: 2STEAL «
iptables -A INPUT -p tcp —tcp-flags ALL FIN,URG,PSH -j STEAL
iptables -A INPUT -p tcp —tcp-flags ALL SYN,RST,ACK,FIN,URG -j LOG —log-prefix «Stealth scan: 3STEAL «
iptables -A INPUT -p tcp —tcp-flags ALL SYN,RST,ACK,FIN,URG -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,RST SYN,RST -j LOG —log-prefix «Stealth scan: 4STEAL «
iptables -A INPUT -p tcp —tcp-flags SYN,RST SYN,RST -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,FIN SYN,FIN -j LOG —log-prefix «Stealth scan: 5STEAL «
iptables -A INPUT -p tcp —tcp-flags SYN,FIN SYN,FIN -j STEAL
iptables -A INPUT -p tcp —tcp-flags FIN,ACK FIN -j LOG —log-prefix «6Stealth scan»
iptables -A INPUT -p tcp —tcp-flags FIN,ACK FIN -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK,URG,PSH PSH -j LOG —log-prefix «7Abnormal steal»
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK,URG,PSH PSH -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK,URG URG -j LOG —log-prefix «8Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK,URG URG -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK FIN -j LOG —log-prefix «A9bnormal scan»
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK FIN -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK NONE -j LOG —log-prefix «10Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK NONE -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK,URG,PSH SYN,FIN,URG,PSH -j LOG —log-prefix «11Abnormal sc$
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK,URG,PSH SYN,FIN,URG,PSH -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK,URG,PSH FIN,URG,PSH -j LOG —log-prefix «12Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,ACK,URG,PSH FIN,URG,PSH -j STEAL
iptables -A INPUT -p tcp —tcp-flags ACK,URG URG -j LOG —log-prefix «13Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags ACK,URG URG -j STEAL
iptables -A INPUT -p tcp —tcp-flags ALL FIN -j LOG —log-prefix «14Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags ALL FIN -j STEAL
iptables -A INPUT -p tcp —tcp-flags FIN,RST FIN,RST -j LOG —log-prefix «15Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags FIN,RST FIN,RST -j STEAL
iptables -A INPUT -p tcp —tcp-flags ACK,PSH PSH -j LOG —log-prefix «16Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags ACK,PSH PSH -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,ACK,FIN,RST SYN -j LOG —log-prefix «17Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags SYN,ACK,FIN,RST SYN -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,URG SYN,URG -j LOG —log-prefix «18Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags SYN,URG SYN,URG -j STEAL
iptables -A INPUT -p tcp —tcp-flags FIN,SYN,RST,ACK SYN -j LOG —log-prefix «19Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags FIN,SYN,RST,ACK SYN -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,PSH SYN,FIN,PSH -j LOG —log-prefix «20Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,PSH SYN,FIN,PSH -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST SYN,FIN,RST -j LOG —log-prefix «21Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST SYN,FIN,RST -j STEAL
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,PSH SYN,FIN,RST,PSH -j LOG —log-prefix «22Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags SYN,FIN,RST,PSH SYN,FIN,RST,PSH -j STEAL
iptables -A INPUT -p tcp —tcp-flags ALL SYN,PSH -j LOG —log-prefix «23Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags ALL SYN,PSH -j STEAL
iptables -A INPUT -p tcp —tcp-flags ALL SYN,ACK,PSH -j LOG —log-prefix «24Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags ALL SYN,ACK,PSH -j STEAL
iptables -A INPUT -p tcp —tcp-flags ACK,FIN FIN -j LOG —log-prefix «25Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags ACK,FIN FIN -j STEAL
iptables -A INPUT -p tcp —tcp-flags ALL RST -j LOG —log-prefix «26Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags ALL RST -j STEAL
iptables -A INPUT -p tcp —tcp-flags ALL RST,ACK -j LOG —log-prefix «27Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags ALL RST,ACK -j STEAL
iptables -A INPUT -p tcp —tcp-flags ALL ACK,PSH,RST -j LOG —log-prefix «28Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags ALL ACK,PSH,RST -j STEAL
iptables -A INPUT -p tcp —tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j LOG —log-prefix «29Abnormal scan»
iptables -A INPUT -p tcp —tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j STEAL

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

Не стоит также забывать о способах тmюнига сетевого стека средствами sysctrl, которые более богато представлены, по сравнению с возможностями сетевого стека MS Windows. С помощью средств sysctrl вы сможете еще более защитить ваш дефолтный тюкс.

Обещаю вам еще чем-нибудь порадовать в будущем.

Удачи! И до новых встреч!

P.S.: STEAL уже не используется в последних векрсиях ntfilter, а жаль, поэтому надо заменить на DROP. Также разумным было бы заменить iptables -A INPUT на iptables -t filter -A INPUT. 😉

Реклама
 

Метки: , , , , , , , , , , ,

Алгоритмы защиты ARP


Algorithm 1 update arp cache
1: if DHCP packet is received then
2: if message type is DHCPACK then
3: IP ← ‘your IP address’ field value
4: if IP != server’s IP then
5: MAC ← ‘client’s hardware address’ field value
6: Add (IP, MAC) to server’s ARP cache
7: Add (IP, MAC) to backup file
8: end if
9: else if message type is DHCPRELEASE then
10: IP ← ‘your IP address’ field value
11: if IP != server’s IP then
12: Remove (IP, ?) from server’s ARP cache
13: Remove (IP, ?) from backup file
14: end if
15: else if message type is DHCPDECLINE then
16: IP ← ‘requested IP address’ options field value
17: if IP != server’s IP then
18: Remove (IP, ?) from server’s ARP cache
19: Remove (IP, ?) from backup file
20: end if
21: else
22: NOOP
23: end if

24:end if

Algorithm 2 send arp reply
1: if ARP message is received then
2: if operation field = REQUEST then
3: TPA ← Target Protocol Address field value
4: Create an ARP REPLY message
5: Sender Protocol Address field ← TPA
6: if TPA = server’s IP address then
7: SHA ← server’s MAC address
8: else
9: Find (TPA, MAC) mapping in ARP cache
10: if (TPA, MAC) does not exist then
11: return //No response is sent
12: end if
13: SHA ← MAC address in (TPA, MAC)
14: end if
15: Sender Hardware Address field ← SHA
16: Send ARP response to requesting host
17: end if
18:end if

——————————————————————

Дальнейшее — за гуру скриптинга. Скрипткидди, проходьте мимо!

 

Метки: , , , , , , , , , , , , ,

TTL – ловим нарушителей периметра сети или развенчиваем мифы.


Доброго времени суток всем тем, кто сегодня читает данную статью!

Я не нашел во всемирной сети Интернет упоминания о возможности использования поля TTL (time to live /время жизни пакета данных в протоколе IP/) таким образом, о котором пойдет речь.
Данного функционала мною не найдено ни в одной общеизвестной коммерческой или Open Source реализации системы безопасности локальных и глобальных сетей.
Между тем возможности по использованию данного поля при обеспечении информационной безопасности локальных и глобальных сетей довольно широки, т. к. имеется возможность с большой степенью достоверности (не совсем верно при использовании генераторов пакетов) определять нарушителей периметра локальной сети или сегмента любой другой сети, а также выполнять достаточно точную идентификацию регионального расположения пользователей в глобальных сетях. Сегодня пойдёт речь лишь об одном из вариантов использования поля TTL для систем безопасности локальной сети, обещаю через некоторое выставить на ваше обозрение материал об использовании поля TTL в целях идентификации пользователей в глобальных сетях.
Начнём, алгоритм с использованием которого возможно выявление компьютерных хулиганов/нарушителей периметра безопасности сети:
1. Устанавливаем для хостов в нашей локальной сети периодически меняющиеся значение поля TTL. На платформах MS Windows данное значение возможно выставить использованием локальных, групповых политик безопасности, либо изменением параметра реестра [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters] «DefaultTTL»=dword:00000063; для платформ на основе операционных систем Linux данное значение возможно изменить с помощью модификации соответствующего параметра сетевого стека “echo 120 > /proc/sys/net/ipv4/ip_default_ttl”. Изменение данных параметров возможно реализовать в виде соответствующих скриптов на VBScript для MS Windows с последующим добавлением в GPO и bash (shell) для Linux платформ, а также последующим добавлением данных заданий в планировщик задач (шедулер, cron) для периодического выполнения данных скриптов. Возможно и единоразовое изменение параметра TTL по возникшей потребности в выявлении нарушителя периметра сети. Нарушение периметра безопасности сети возможно по различным причинам, в т. ч. и в результате действия инсайдеров.
2. Периодически изменяющиеся значение поля TTL, отличное от значения TTL для других хостов, имеет смысл установить особенно для хостов, которым не разрешен выход в сеть интернет через шлюз организации, что позволит отслеживать пользователей, которые нарушают систему безопасности организации, т. к. логично предположить, что данные нарушители получили тем или иным способом административные права на своем хосте (при аутентификации на шлюзе по паре MAC-IP) и/или кто-то по доброте душевной сообщил другому сотруднику свой пароль авторизации на шлюзе доступа в сеть интернет. Для таких хостов, которым не разрешен выход в интернет, устанавливаем значение поля TTL в несколько единиц, такое значение позволит пройти пакетам только через несколько маршрутизаторов (-р) и не даст нарушителям доступа к ресурсам сети интернет.
3. После таких нехитрых приготовлений мы получим в итоге известные значения TTL для нашей подсети (сети), которые меняются со временем. Согласитесь, что нарушителю об этом не будет известно, а это дает возможность выявить такого непрошенного гостя по значению его TTL. Значение TTL нарушителя будет отличным от известных нам в текущий момент значений TTL для нашей подсети (сети).
4. Остается дело техники. 🙂 Для мониторинга значений TTL в сети можно воспользоваться различным программным обеспечением (анализаторы пакетов с фильтрацией по известным нам значениям полей TTL; IDS, IPS с соответствующим написанным дополнением), которое будет отслеживать не валидные значения поля TTL в пакетах и сообщать нам информацию о нарушителе, а также будет иметься возможность по автоматической блокировке нарушителя со стороны средств превентивного реагирования. Дополнительная фильтрация осуществляется: по флагу SYN (TCP) или по запросу на соединение (NEW); для UDP по запросу на соединение NEW, для валидного диапазона сети.
5. После выявления нарушителя можно воспользоваться станцией управления сетью (SNMP) для поиска оного на портах наших коммутаторов по значениям его MAC и IP адресов.
6. Идем к нарушителю и вершим суд праведный.

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

Это вся информация, которой я хотел поделиться с вами, уважаемые читатели моего блога.

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

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

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

UPD2: Обращаю внимание, что данный алгоритм позволяет выявлять и такой бич вычислительных сетей, как генераторы пакетов, с точностью до сегмента, а затем до порта (поиск в сегменте труда не составит, если задействовать зеркалирование трафика на управляемом оборудовании или даже вручную). 😉 Есть и другие применения данного алгоритма, которые позволяют вывести уровень защиты вычислительных сетей на качественно новый уровень. Но об этом позже.

 

Метки: , , , , , , ,