Показаны сообщения с ярлыком LAN. Показать все сообщения
Показаны сообщения с ярлыком LAN. Показать все сообщения

воскресенье, 23 декабря 2012 г.

Алгоритмы защиты 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
—————————————————————–
Дальнейшее – за гуру скриптинга. Скрипткидди, проходьте мимо!
 




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

пятница, 21 декабря 2012 г.

Модернизация локальной сети.


Довольно часто возникает необходимость в модернизации локальной сети предприятия. Но к ней необходимы объективные предпосылки, тем более если в локальной сети насчитывается несколько сот рабочих станций ;-) Т. е. необходимо предварительное исследование сети, выявление узких мест, а также необходим мониторинг производительности серверов баз данных, контроллеров домена, samba серверов.
Лучше всего для получения статистики здоровья сети воспользоваться средствами, предоставляемыми самим активным оборудованием, которое, как правило, поддерживает SNMP, средствами которого и предлагаю воспользоваться. Некоторое активное оборудование умеет отображать собственную статистику в разрезе времени, при доступе к нему через веб-интерфейс, но лучше все же воспользоваться SNMP, т. к. активное сетевое оборудование могут отключить и статистика потеряется. А информации, полученная по протоколу SNMP станцией управления сетью сохранится. Лучше всего выбрать статистику за один месяц и изучить результаты. Сразу станет понятно какие места в сети являются узкими и для которых необходима последующая модернизация.
Стоит отметить, что ядро сети необходимо организовать из одного – двух (в стеке) высокопроизводительных коммутаторов, к которым лучше всего напрямую подключить сервера организации. Следует также учесть запас пропускной способности в выявленных узких и остальных узлах сети, который не должен быть меньше 40%. Такой запас необходим для возможного будущего роста локальной сети предприятия. При наличии силовых кабелей в местах прокладки кабеля стоит выбрать экранированную витую пару. Также стоит проверить заземление на всех ключевых узлах локальной сети, т. к. его отсутсвие может привести в будущем к неприятным последствиям.
Сервера должны быть подключены к ядру сети по высокроизводительным магистралям, например, по 1Gbit Ethernet и выше. Для серверов также возможно кратное увеличение пропускной способности магистралей, если имеется программное обеспечение производителя сетевых адаптеров по агрегированию каналов связи.
Но все это должно быть обосновано на основе данных собранной статистики, а также с учетом дальнейшего расширения отдельных сегментов сети (по возможности).




https://nikitushkinandrey.wordpress.com/2012/05/11/%d0%bc%d0%be%d0%b4%d0%b5%d1%80%d0%bd%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d1%8f-%d0%bb%d0%be%d0%ba%d0%b0%d0%bb%d1%8c%d0%bd%d0%be%d0%b9-%d1%81%d0%b5%d1%82%d0%b8/

Использование динамической адресации (DHCP/D/).

Использование динамической адресации в домене MS Windows и сетях Linux дает улучшение общей управляемостью в сети, т. к. отпадает необходимость в дополнительных издержках, например, при смене адресации. Но при этом следует учесть и требования безопасности, налагаемые на задействование DCHP адресации. А именно, крайне желательно иметь активное сетевое управляемое оборудование, которое позволяет автоматически переадресовывать DHCP запросы непосредственно на легальный сервер DHCP, это так называемая функция DHCP redirect у управляемых коммутаторов. Задействование данной функции позволит минимизировать негативные последствия в случае появления в сети ложного DHCP сервера. Кроме того, следует запретить получение данных для DHCP клиентов и сервера (-ов) от нелегитимных источников (IP адресов), для чего можно воспользоваться средствами фильтрации трафика IPSec/iptables по портам для клиентов DHCP и серверов DHCP. От пролучения пакетов, созданных генераторами пакетов это не защитит, при умелой генерации, но таких профессионалов среди народных умельцев, как правило, не наблюдается в локальных сетях. Но и от этой напасти есть весьма простой и действенный способ – всегда имеется возможность перезапустить службу DHCP. Еще больше усилит безопасность клиентов и серверов при динамической адресации использование возможностей изоляции доменов для сетей Windows и аналогичные возможности IpSec в сетях Linux. В этом случае извне никто не сможет нарушить сетевую безопасность, просто подключившись к локальной сети организации. А вычисление народных умельцев, которые хулиганят в рабочее время, станет лишь делом техники, а точнее умелого использования сочетания средств управления сетью и средств мониторинга сети.



https://nikitushkinandrey.wordpress.com/2012/05/11/%d0%b8%d1%81%d0%bf%d0%be%d0%bb%d1%8c%d0%b7%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-%d0%b4%d0%b8%d0%bd%d0%b0%d0%bc%d0%b8%d1%87%d0%b5%d1%81%d0%ba%d0%be%d0%b9-%d0%b0%d0%b4%d1%80%d0%b5%d1%81%d0%b0%d1%86%d0%b8/

вторник, 18 декабря 2012 г.

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: Обращаю внимание, что данный алгоритм позволяет выявлять и такой бич вычислительных сетей, как генераторы пакетов, с точностью до сегмента, а затем до порта (поиск в сегменте труда не составит, если задействовать зеркалирование трафика на управляемом оборудовании или даже вручную). ;-) Есть и другие применения данного алгоритма, которые позволяют вывести уровень защиты вычислительных сетей на качественно новый уровень. Но об этом позже.


http://nikitushkinandrey.wordpress.com/2011/03/10/ttl-%d0%bb%d0%be%d0%b2%d0%b8%d0%bc-%d0%bd%d0%b0%d1%80%d1%83%d1%88%d0%b8%d1%82%d0%b5%d0%bb%d0%b5%d0%b9-%d0%bf%d0%b5%d1%80%d0%b8%d0%bc%d0%b5%d1%82%d1%80%d0%b0-%d1%81%d0%b5%d1%82%d0%b8-%d0%b8/
http://nikitushkinandrey.wordpress.com