Блог Андрея Никитушкина Голосов: 0 Адрес блога: http://andreynikitushkin.blogspot.com/ Добавлен: 2012-12-24 18:38:37

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

2012-12-21 16:31:23 (читать в оригинале)


Довольно часто возникает необходимость в модернизации локальной сети предприятия. Но к ней необходимы объективные предпосылки, тем более если в локальной сети насчитывается несколько сот рабочих станций Т. е. необходимо предварительное исследование сети, выявление узких мест, а также необходим мониторинг производительности серверов баз данных, контроллеров домена, 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/).

2012-12-21 16:30:34 (читать в оригинале)

Использование динамической адресации в домене 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/

---

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

2012-12-21 16:29:29 (читать в оригинале)


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


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

---

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

2012-12-21 16:28:32 (читать в оригинале)


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

https://nikitushkinandrey.wordpress.com/2012/05/11/%d0%b2%d1%8b%d1%8f%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-arp-%d0%b7%d0%bb%d0%be%d0%b4%d0%b5%d0%b5%d0%b2-%d0%b2-%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/

---

Организация защиты NetBIOS, SMB и выявление злодеев. ;-)

2012-12-21 16:27:26 (читать в оригинале)




Портами, используемыми NetBIOS, SMB, являются:
138 – NetBIOS Datagram;
137 – NetBIOS Name Resolution;
139 – NetBIOS Session;
445 – SMB.
Данные порты используются также протоколом RPC и различными сетевыми сервисами. Поэтому слудет быть осторожными с блокированием данных портов.
Обращаем внимание на то, что любая сессия начинается с netbios-запроса, задания ip-адреса и определения tcp-порта удаленного объекта, далее следует обмен NETBIOS-сообщениями, после чего сессия закрывается. Сессия осуществляет обмен информацией между двумя netbios-приложениями. Длина сообщения лежит в пределах от 0 до 131071 байт. Допустимо одновременное осуществление нескольких сессий между двумя объектами.
При организации IP-транспорта через NETBIOS IP-дейтограмма вкладывается в NETBIOS-пакет. Информационный обмен происходит в этом случае без установления связи между объектами. Имена Netbios должны содержать в себе IP-адреса. Так часть NETBIOS-адреса может иметь вид, ip.**.**.**.**, где IP указывает на тип операции (IP через Netbios), а **.**.**.** – ip-адрес. Система netbios имеет собственную систему команд (call, listen, hang up, send, receive, session status, reset, cancel, adapter status, unlink, remote program load) и примитивов для работы с дейтограммами (send datagram, send broadcast datagram, receive datagram, receive broadcast datagram). Все оконечные узлы netbios делятся на три типа:
широковещательные (“b”) узлы;
узлы точка-точка (“p”);
узлы смешанного типа (“m”).
IP-адрес может ассоциироваться с одним из указанных типов. B-узлы устанавливают связь со своим партнером посредством широковещательных запросов. P- и M-узлы для этой цели используют netbios сервер имен (NBNS, WINS) и сервер распределения дейтограмм (NBDD, Browser).
Кроме того “обозревателей” сети (браузеров) в локальной сети может быть несколько. Применительно к домену MS Windows одним из обозревателей (браузеров) в локальной сети должен выступать один из контроллеров домена. Но главным обозревателем (мастер броузер) должен быть только один из хостов. Количество браузеров в сети зависит от размеров данной сети.
Итак, прочитав вышеизложенное, возможно сделать следующие умозаключения для защиты сервисов NetBIOS, SMB от злоумышленников:
1. Однозначно прописывать адреса WINS серверов на хостах сети;
2. Жестко прописывать адреса критически важных узллов сети в файлах hosts, lmhosts на хостах сети, чтобы не было искажения (или минимизация искажения) информации в результате спуфинга адресации;
3. Запретить в правилах фильтрации трафика получение пакетов на вышеуказанные порты от недоверенных адресов по протоколу UDP , разрешив при этом получение пакетов на данные порты только с WINS, SMB (SAMBA) серверов, а также задействовать защиту от ARP спуфинга (если эту опцию поддерживает фильтр пакетов);
4. Настроить периодический перезапуск службы NetBIOS с очисткой кеша, для предотвращения отравления кеша службы;
5. Для серверов служб имен можно посоветовать более частое безопасное обновление зон.
6. В правилах фильтрации сетевого фильтра (стороннего) необходимо также задействовать защиту от ARP спуфинга и IP спуфинга.
Это не защитит от наиболее изощеренных методов атак, но абсолютное большинство умельцев отучит от вредительских действий. Оставшаяся часть, продвинутых в данном направлении, пользователей будет уже нам знакома.
Вот такой небольшой план решения большой проблемы. Удачи вам, читатели, надеюсь данная статья поможет вам бороться со злодеями в локальных сетях.


https://nikitushkinandrey.wordpress.com/2012/05/11/%d0%be%d1%80%d0%b3%d0%b0%d0%bd%d0%b8%d0%b7%d0%b0%d1%86%d0%b8%d1%8f-%d0%b7%d0%b0%d1%89%d0%b8%d1%82%d1%8b-netbios-smb-%d0%b8-%d0%b2%d1%8b%d1%8f%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b5-%d0%b7%d0%bb%d0%be/