RSS

Архив метки: локальная сеть

Алгоритмы защиты 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

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

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

Реклама
 

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

STP или защита от закольцовки локальной сети.


Иногда случается ситуация, когда народные таланты начинают пакостить в сети, закольцовывая отдельные ее сегменты отдельным кабелем (при топологии типа “звезда”).

Но и от этого есть защита – STP (Spanning Tree Protocol), сетевой протокол, работающий на втором уровне модели OSI. Основан на одноимённом алгоритме, разработчиком которого является «Мама Интернета» — Радья Перлман (англ. Radia Perlman).

Более подробно русскоязычные читатели могут ознакомиться с описанием данного протокола по нижеприведенной ссылке: http://ru.wikipedia.org/wiki/STP

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

НО!

Как я уже не раз повторял: “К безопасности в любой вычислительной сети необходимо подходить комплексно! Так как даже при реализации STP есть возможность деструктивного программного воздействия на компьютерную сеть (у каждой палки 2 конца! 😉 )! Не оставляйте дырок компьютерным хулиганам!”

Данная заметка посвящается системным администраторам и инженерам, которые не понимают сути данного протокола, впрочем, также как и моя статья о VLAN.

Мне приходилось встречать на своем жизненном пути таких “ортодоксов”, не приемлющих никаких новшеств и средств защиты. А почему не использовать то, что уже предоставляется бесплатно оборудованием?

 

Метки: , ,

Выявление ARP злодеев в локальной сети.


Довольно часто в локальных сетях предприятий появляются любители пошалить с дублированием ARP адресов. К чему это приводит? Приводит к недоступности части локальной подсети, организованной на свитчах (коммутаторах). Наиболее ощутимый вред наносит дублирование MAC адресов самих коммутаторов, оставляя отключеными от сети всех, кто подключен к скомпроментированному коммутатору. Т. е. возникает ситуация, когда, как иногда говорят, сеть “висит”.
Выявить такого вредителя не так уж и сложно, достаточно установить станцию управления сетью, которая будет нам собирать статистику по протоколу SNMP, причем саму станцию и коммутаторы, которые она мониторит логически выделяем в отдельную подсеть с использованием VLAN. Это необходимо для того, чтобы при любой ситуации (дублирование ARP-адресов) статистика с коммутаторов приходила на станцию управления. Анализируя такую статистику мы сможем найти злоумышленника (порт к кторому подключена машина с дубликатом MAC адреса) по информации об MAC адресах на портах нашего коммутатора.
Отдельного разговора залуживает ARP-спуфинг в локальных сетях, с которым бороться сложно, но отследить нарушителя все равно возможно. Для этого необходимо регулярно использовать анализатор сети, желательно на компьютере, подключенном к ядру сети (центральному коммутатору). При подозрении на ARP-спуфинг делаем фильтрацию по скомпроментированному MAC адресу и смотрим, с какого IP адреса пришел пакет и идем к нарушителю. Но только в том случае, если не использовался при этом специальный генератор пакетов, с помощью которого можно подменить адреса отправителя и получателя (тут, как говорится, уже без вариантов, концов можно и не найти).

 

Метки: ,

Маркировка кабельной системы локальной сети.


Часто возникает необходимость в проведении маркировки кабельной системы предприятия, т. к. зачастую кабельные сети у нас до сих пор все еще не маркированы и администраторы даже не подозревают где и как проложена кабельная система, что несомненно наносит вред информационной безопасности предприятия и не позволяет оперативно решать те или иные повседневные задачи.
Я опишу наиболее действенный способ маркировки кабельной системы, который был мною реализован с помощью сотрудников ИТ-отдела. У каждого способа есть свои вариации, так что дерзайте! 😉
Итак, вначале необходимо задействовать станцию управления сетью, использующую протокол SNMP для сбора информации с активного сетевого оборудования, о чем мною писалось несколько ранее. Задействование такой станции нам позволит визуально оценить текущую структуру нашей локальной сети и даст представление о том, какой компьютер к какому порту какого коммутатора подключен, а также оценить здоровье сети. Далее берем, чертим таблицы для каждого компутатора, в которых записываем к каким портам данного коммутатора подключен(-ны) тот (те) или иной(-ые) компьютер (-ы). Далее модифицируем коммутацию кабельной системы нужным нам, предварительно согласованным с руководством, образом. В том случае, если к какому-либо порту коммутатора подключен(-ы) еще неуправляемые коммутаторы и нет возможности оценить разводку кабельной системы с помощью тестера сети, рекомендую задействовать дополнительный управляемый коммутатор, который временно включается взамен неуправляемого и с него снимаем дополнительную информацию станцией управления.
Если нет возможности выяснить пути прокладки кабеля визульными методами, то имеется возможность выявить данный кабель по кабельной маркировке, а именно, по маркировке производителя (уникальна для каждой бухты кабеля), а также по маркерам метража кабеля. Отмечаем себе маркировку производителя и метраж кабеля, а дальше ище по кабельканалам нужный нам кабель и смотрим как он проложен.
И, конечно же, используем кабельные тестеры для контроля разводки. Для связи с помощниками во время проведения такой маркировки удобно использовать обыкновенные туристические рации.
Маркировку коммутаторов, портов коммутаторов и розеток лучше всего производить по заранее оговоренному числовому или буквенно-числовому коду. И не забываем записывать все производимые изменения в наши таблицы (что, куда и как перекоммутировали). После полной перекоммутации составляем чистовые таблицы (разводку) нашей кабельной системы. Затем с помощью станции управления сетью еще раз сверяем наши таблицы с реальной структурой сети, выдаваемой станцией управления.
Все! Теперь вы и сотрудники ИТ-отдела знаете, куда и как идет тот или иной кабель на вашем предприятии. А это дает возможность заняться непосредственно улучшением здоровья вашей локальной сети на основании статистики, собираемой станцией управления сетью. Например, на основании большого количества потерянных пакетов на том или ином порту коммутаора можно сделать вывод о том, что что-то не в порядке у цепочки адптер-кабель-порт. И не забываем использовать кабельные тестеры для проверки таких цепочек, желательно умеющие определять длину кабеля, т. к. большое количество потерянных пакетов может говорить и об излишне длинном кабеле. SNMP также предоставляет оценить приблизительную длину кабеля от порта коммутатора до адаптера, но для этого, зачастую, требуется подгрузка соответствующей mib для данного управляемого активного сетевого оборудования.
Удачи вам! 😉

 

Метки: , ,

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


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

 

Метки: , , ,

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


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

 

Метки: , ,