воскресенье, 8 января 2017 г.

11. Практическая безопасность сетей


1.2.7 Защита от Brute Force

Кроме упомянутых выше методов (выбор сложного пароля, нестандартной учетной записи и списков доступа) есть еще один способ, который позволит защититься от попытки взломать ваше устройство. Это так называемая защита от Brute Force (т.е. от перебора паролей).
Здесь я хотел бы сделать небольшое отступление и вспомнить один случай из жизни. Пару лет назад я помогал своему другу настроить Mikrotik в качестве пограничного маршрутизатора (т.е. он использовался для выхода в Интернет). Проделав базовые настройки мы организовали выход в Интернет буквально за 10 минут. После мы взяли по бутылочке пива и я в расслабленном режиме принялся ему рассказывать про Mikrotik, как его администрировать, где и что настраивать. Когда мы дошли до функции просмотра логов, то заметили странную вещь. Из внешней сети постоянно кто-то пытался подключиться к нашей “железке”. При этом в попытках использовались такие учетные записи как “root”, “admin”, “guest” и так далее (т.е. стандартные учетки). Посмотрев IP - адреса атакующих мы выяснили, что эта активность ведется из Китая. Но кому нужен наш Mikrotik? Немного “погуглив” и почитав форумы, мы поняли, что это обычные китайские боты, которые в автоматическом режиме по всему миру ищут уязвимые устройства и выполняют “атаку на дурака”. Естественно для них не представляет интерес какая-то наша личная информация (хотя кто знает?). С большой вероятностью им просто нужны взломанные устройства с помощью которых они смогут осуществлять массированные DDoS атаки (чуть позже мы обсудим этот тип атак). Именно поэтому не пренебрегайте ранее данными советами: 
1) Не используйте стандартные имена в учетных записях;
2) Придумывайте сложные пароли (мы обсудим каким образом выбирать пароль в следующей главе);
3) Ограничьте удаленный доступ с помощью списков доступа (для сети Интернет его лучше вообще выключить).

Однако бывают экзотические случаи, когда все же необходим доступ к оборудованию из сети Интернет. При этом нет возможности указать конкретный удаленный хост, с которого будет разрешен доступ. Да и кто даст гарантию, что внутри вашей сети нет зараженного компьютера, который будет пытаться подобрать пароли ко всем доступным хостам? Именно для таких случаев есть дополнительный уровень защиты - задержка между повторными вводами учетных данных. Настраивается это следующим образом:

R1(config)#login delay 5
R1(config)#login block-for 60 attempts 3 within 30

Первой командой мы указываем интервал в 5 секунд между повторными вводами паролей. Второй командой мы настраиваем блокировку входа на 60 секунд, если в течении 30 секунд было 3 попытки неудачного входа. Данный способ существенно ограничивает злоумышленников при подборе паролей. Получается, что они смогут подбирать всего 3 пароля в течении 15 секунд, а затем блокировка на 60 секунд. Даже если вы используете довольно простой пароль, у злоумышленников уйдет очень много времени на подбор, что становится совершенно нецелесообразно. При этом в консоли устройства вы увидите сообщение примерно следующего содержания:

*Mar 1 00:04:55.899: %SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 4 secs, [user: admin] [Source: 192.168.10.3] [localport: 23] [Reason: Login Authentication Failed] [ACL: sl_def_acl] at 00:04:55 UTC Fri Mar 1 2002
R1#
*Mar 1 00:05:03.491: %SEC-6-IPACCESSLOGP: list sl_def_acl denied tcp 192.168.10.3(62741) -> 0.0.0.0(23), 1 packet

Т.е. при 3-х неудачных попытках создается временный access-list, который блокирует дальнейшие попытки с определенного хоста. Максимальное время блокировки - 65535 секунд (т.е. примерно на 18 часов). Крайне не рекомендую выставлять такой интервал, т.к. вы и сами можете быть заблокированы если вдруг сделаете несколько неудачных попыток (перепутали пароль, русская раскладка клавиатуры, зажатый caps lock).
Для защиты от подбора паролей (Brute Force) настройте временную блокировку повторной аутентификации.
1.2.8 Идентификация устройства

Почти уверен, что в работе каждого сетевого администратора были моменты когда он нечаянно вводил команду “не на том” коммутаторе/маршрутизаторе после чего падала сеть, либо пропадал доступ к оборудованию. Наверняка многие сталкивались с ситуацией, когда зайдя на устройство было трудно понять куда именно вы попали. Все это также является аспектами безопасности вашей сети. Как вы уже наверно поняли, здесь пойдет речь о таких вещах, как hostname и login banner. Довольно часто про эти опции просто забывают.
Вообще говоря, многие начинают настройку устройства с имени - hostname. Это уже дело привычки. Имя должно быть осмысленным и однозначно определять предназначение устройства. Пример:
Коммутатор ядра - 4507_Core
Коммутатор доступа на втором этаже - 2960_2flor
Пограничный маршрутизатор - 1710_Edge
Это лишь примеры, которые отражают суть идеи. Естественно, что у каждого могут быть собственные стандарты. Сама настройка элементарна:

Router>enable
Router#conf t
Router(config)# hostname R1 /задаем имя
R1(config)# /имя изменено

Кроме имени есть еще одна полезная опция - login banner. Это сообщение которое мы видим при подключении к устройству. Пример:

User Access Verification
Username: admin
Password:

Test banner for netskills

R1>

Какую же информацию можно поместить в сообщение баннера? Как правило в нем указывают информацию об устройстве, о том, что нужно быть аккуратным при конфигурировании и о том, что нужно немедленно выйти если вы попали на это устройство случайно (такое все же иногда случается). Когда это может быть полезно? К примеру у вас несколько администраторов сети и не каждому позволено конфигурировать некоторые устройства. В этом случае, зайдя на устройство, можно однозначно увидеть предостережение и сделать вывод о “законности” дальнейшей настройки.
При этом у нас есть выбор когда показывать это сообщение - до аутентификации или уже после (как в примере выше). На мой взгляд гораздо логичнее это делать после, особенно если в сообщении содержится важная информация (например, что данный коммутатор является ядром сети). Настройка также элементарна:

R1(config)#banner exec c /начало баннера

Enter TEXT message. End with the character 'c'.
Test banner for NetSkills /сообщение
c /конец баннера
R1(config)#

Теперь при аутентификации на устройстве вы увидите сообщение “Test banner for NetSkills”. Если же есть необходимость использовать баннер до аутентификации, то используйте команду banner login вместо banner exec.
Задавайте имя устройства (hostname) и сообщение после аутентификации (banner exec), чтобы в будущем не “перепутать” оборудование.

3 комментария:

  1. Баннеры обязательно должны быть, к примеру, если я не ошибаюсь, в сша их обязательно прописывают и сообщение должно гласить что за какие-либо действия на оборудовании которое вам не пренадлежит вы несете ответственность по закону. Про китайцев интересно) не дадут спокойно жить безопастникам)

    ОтветитьУдалить
  2. А вот, кстати по второму пункту - про осмысленные имена устройств. В одном из cisco-вских курсов один наш бывший соотечественник, который нынче в Хайнане живет рассказывал, что "по фен-шую" нужно давать устройствам максимально "шифрованные" имена (понятные только вам) для того, чтобы как можно сильнее уменьшить возможности для анализа сети при возможном проникновении, ведь использование логически привязанных к устройствам имен (main-router, swich-1-floor, etc.) это практически готовая карта для злоумышленника.

    ОтветитьУдалить
    Ответы
    1. Да, есть такое дело. Здесь уже нужен баланс между удобством и безопасностью. Ваш вариант удобней когда в сети один-два админа. Если их много, то гораздо лучше дать понятные имена для всех, т.к. проблемы с сетью гораздо чаще возникают именно от своих же сотрудников, которые "перепутали" свич.

      Удалить

Блог развивается при поддержке

Блог развивается при поддержке
Защищаем настоящие ценности клиента

Translate

Популярные сообщения

Blog Archive

Технологии Blogger.

Google+ Followers