Конфликт IP адресов?
Почему роутер выдает уже занятые адреса?
В каком смысле адреса из белого диапазона?
Александр Бавтюк: WiFi раздает этот же роутер? Точно нет в сети другого dhcp сервера? Посмотрите кем выдан адрес.
АртемЪ: WiFi раздает этот же роутер?
да, тот же роутер, конечно
Точно нет в сети другого dhcp сервера?
В сети другого нету.
Адреса выдал Mikrotik.
По поводу белого адрес я вас понял, спасибо
Кто мешает поделить пул адресов на три части?) Статичная например 172.16.34.1-10
Назначит первому дхцп 172.16.34.2 и дать ему раздавать 34.11-100. А второму 34.3 и раздавать 34.101-200?) а принтер засунуть тоже в статичные
А ответ прост. Они в душе не ипут что есть другие дхцп сервера). Ой я думал у тебя два роутера. Тогда все ещё проще. Поставь статику на арендованный айпи принтером и не люби мозг)
Mikrotik и ARP таблицы
Что такое ARP и зачем это нам
ARP (“Address Resolution Protocol” — протокол определения адреса) — использующийся в компьютерных сетях протокол низкого уровня, предназначенный для определения адреса канального уровня по известному адресу сетевого уровня. Наибольшее распространение этот протокол получил благодаря повсеместности сетей IP, построенных поверх Ethernet, поскольку практически в 100 % случаев при таком сочетании используется ARP.
ARP протокол работает с MAC адресами. Свой индивидуальный MAC адрес есть у каждой сетевой карты.
MAC-адрес (“Media Access Control” — управление доступом к среде) — это уникальный идентификатор, сопоставляемый с различными типами оборудования для компьютерных сетей. Большинство сетевых протоколов канального уровня используют одно из трёх пространств MAC-адресов, управляемых IEEE: MAC-48, EUI-48 и EUI-64. Адреса в каждом из пространств теоретически должны быть глобально уникальными. Не все протоколы используют MAC-адреса, и не все протоколы, использующие MAC-адреса, нуждаются в подобной уникальности этих адресов.
Чем может быть полезен ARP протокол для нас. Предположим, нам пощасливилось купить Mikrotik RouterBoard 1100. Мы прочли статью, как настроить mikrotik, и все легко настроили. Но вот случилось … пользователь переустанавливал операционную систему или случайно сбил сетевые настройки. Пытаясь их вспомнить, он вводит ошибочный IP адрес, и в сети появляется два одинаковых IP адреса. Таким образом, возникает конфликт IP адресов, которые будут бороться между собой. Чтобы этого избежать, в ARP протоколе существуют ARP таблицы.
ARP-таблица для преобразования адресов
В Mikrotik ARP таблицу можно увидеть в разделе IP ARP.
Рис.1. Путь к ARP таблице.
Рис.2. ARP таблица.
На Рисунке 2 мы видим ARP таблицу. В ней три записи, они добавляются автоматически и имеют следующую структуру. IP Adress – это, собственно, IP адрес компьютера сети, MAC Adress – это mac адрес этого же компьютера, и Interface, который указывает за каким интерфейсом находится данный компьютер. Обратите внимание, что напротив всех записей есть буква D. Она означает то, что эта запись динамическая и будет изменена, если изменятся какие-то данные. То есть, если пользователь случайно введет неправильный IP адрес, то просто изменится запись в ARP таблице и больше ничего. Но нам это не подходит. Нам нужно застраховаться от таких случаев. Для этого в ARP таблицу вносятся статические записи. Как это сделать? Существует два способа.
Рис.3. Добавляем Статическую запись первым способом.
Способ первый. Как обычно нажимаем красный плюс. В появившемся окне вводим IP адрес, MAC адрес и выбираем интерфейс, за которым находится данный компьютер.
Рис.4. Добавляем Статическую запись вторым способом.
Способ второй. Выбираем нужную запись, кликаем два раза левой клавишей мыши, в появившемся окне нажимаем кнопку Make Statik. Статическая запись добавлена.
Рис.5. Таблица со статическими записями.
Как видно на рисунке 5 – напротив добавленной записи отсутствует буква D. Это говорит о том, что запись статическая.
Теперь, если пользователь случайно введет не свой адрес, Mikrotik, проверив соответствие IP и МАС адреса в ARP таблице и, не найдя нужной записи, не даст пользователю выйти в интернет, тем самым наведет пользователя на мысль о том, что он, возможно, был не прав и надо бы позвонить администратору.
Еще на что хотелось бы обратить ваше внимание: эти записи применяются для пакетов проходящих через router.
Маршрутиза́тор или роутер — сетевое устройство, которое принимает решения о пересылке пакетов сетевого уровня (уровень 3 модели OSI) между различными сегментами сети на основании информации о топологии сети и определённых правил.
Если нужно, чтобы правила применялись к Bridge(бридж), то в Bridge нужно включить функцию Use IP Firewall (рис.6.).
Бридж — это способ соединения двух сегментов Ethernet на канальном уровне, т.е. без использования протоколов более высокого уровня, таких как IP. Пакеты передаются на основе Ethernet-адресов, а не IP-адресов (как в маршрутизаторе). Поскольку передача выполняется на канальном уровне (уровень 2 модели OSI), все протоколы более высокого уровня прозрачно проходят через мост.
Рис.6. Включение функции Use IP Firewall.
Мой MikroTik – моя цифровая крепость (часть 1)
1. Введение
В комментариях опубликованной ранее статьи один из пользователей спросил: «А можно добавить раздел про то, как нужно защитить свой, микротик чтобы управление им не ушло на сторону?». Один из пользователей написал на это следующее: «Универсальных принципов для любого сетевого устройства два – администрирование только с внутреннего интерфейса (снаружи закрыто все) и регулярно обновлять прошивку» (сохранена авторская орфография). А мы сразу поняли, что одним коротким ответом здесь не обойтись, и этот вопрос заслуживает полноценного отдельного рассмотрения с учётом широких возможностей операционной системы RouterOS, а также сопрягаемых с ней opensource решений, комплексно завершающих проблемный вопрос информационной безопасности. Кроме непосредственно настройки безопасности доступа до маршрутизатора, необходимо использовать его как полноценный барьер для разноуровневых атак, которые могут быть нацелены на защищаемую сеть. Технологий реализации этого достаточно много, поэтому разделим применяемые возможности на логические уровни и представим предметные рекомендации по администрированию сетей на базе оборудования MikroTik.
2. Общие рекомендации
Первое, что мы всегда делаем с железкой — это обновляем прошивку:
Далее смотрим, сколько создано пользователей, лишних удаляем. Ставим пароли, соответствующие политике информационной безопасности компании, если такая есть, если нет, тогда просто посильнее:
Если паранойя зашкаливает, тогда используем SSH вход без ввода пароля (и пользователя admin можно заменить на другого). Сгенерим пару RSA ключей, размер укажем 4096 бит, что уж мелочиться:
На выходе будет закрытый ключ test_user:
И открытый ключ test_user.pub:
Привяжем открытый ключ к пользователю RouterOS:
Добавляем хардкор, запретив логиниться по паролю:
Важно отметить, что если есть пользователь, для которого не импортирован публичный ключ, то, несмотря на вышепоказанную настройку, RouterOS сохраняет возможность логиниться под ним с помощью пароля. С учётными записями разобрались, далее выключаем серверы различных протоколов управления, в том числе небезопасные, разумеется, есть ли они вам не нужны:
Можно поменять прослушиваемый порт для SSH сервера. Особенно на значение, не входящее в сканируемые по умолчанию nmap-ом, но мы в этом защиты не видим, скорее маскировка:
Сканируем роутер и видим, что всё работает корректно. Сервер SSH будет недоступен, пока на роутер не пройдут попытки установления соединения на 28 порт, затем в течение 30 секунд на 29 порт, затем в течение 30 секунд на 30 порт. Если последовательность обращений верна и временные лимиты соблюдены, то IP адрес источника сможет в течение 30 секунд установить SSH сессию, а иначе drop:
Необходимо отметить, что если вы укажете порты стука примерно в таком порядке: 21, 80, 443, а прослушиваемый SSH порт перенесете на значение 8080 (все четыре входят в список по умолчанию для сканирования nmap), то ваш секретный порт 8080 определится при первом же сканировании. Если вы действительно хотите использовать технологию port knocking, то выбирайте порты в порядке уменьшения, а сами значения портов на «не сканируемые» nmap-ом: ни в режиме top 100, ни в режиме top 1000. Кроме этого, можно ограничить IP адреса, с которых доступны протоколы управления, на диапазон доверенных:
Таким образом, несмотря на то, что 22 порт готов принимать TCP соединение, однако с не доверенных IP адресов оно будет сброшено SSH сервером:
Как общие рекомендации, лучше не использовать протоколы, не имеющие шифрования для передачи защищаемой информации. Если такой возможности нет, тогда старайтесь пускать трафик по шифрованным VPN туннелям. Но лучше даже внутри таких соединений использовать безопасные протоколы, ведь VPN сеть может уходить далеко за пределы периметра, контролируемого вами. Если есть возможность, не используйте протоколы pap, http (в том числе при реализации API), ftp, smtp и т.д. Всегда используйте их безопасные аналоги: chap, mschap2, https, smtps.
Делайте регулярные резервные копии конфигураций ваших устройств. В RouterOS есть два типа backup: бинарный *.backup
и текстовый конфигурационный файл *.rsc
Первый рекомендуется откатывать только на полностью идентичных устройствах, и не подлежит редактированию (при откате восстанавливается точный образ операционной системы). Второй же, наоборот, можно вручную контролируемо построчно обрабатывать (до получения необходимо результата), однако он может содержать чувствительную информацию (если не делать /export hide-sensitive), поэтому рекомендуем обезопасить хранение такого рода backup файлов. Ставить ли регулярный backup в планировщик заданий, или нет, тут уже каждый решает сам. Главное — не запутаться во всех резервных копиях и не передавать их на удалённый сервер по открытому интернет каналу посредством ftp.
3. Защита L1
Писать правила про установку сетевого оборудования в серверных помещениях, в защищённых телекоммуникационных ящиках, сейфах и т.д. мы не будем, это не тема статьи. Для защиты L1 на оборудовании MikroTik будет достаточно программно отключить не используемые сетевые интерфейсы:
Сюда же пойдёт организация безопасности беспроводных соединений. В идеале, конечно, следует настроить WPA2-Enterprise (подробно о настройке RADIUS сервера мы напишем во второй части статьи), так как реальных угроз безопасности таких сетей пока не известно:
Если такой вариант вам не подходит, тогда используйте WPA2-PSK со словарно неподбираемым паролем, который держите в тайне от третьих лиц, и отключённый PMKID:
Ещё можно запретить подключаться к точке доступа с низким уровнем сигнала, т.е. физически удалённым пользователям, которые, можно предположить, находятся за контролируемым периметром и не легитимны:
На этом свои рекомендации по поводу L1 безопасности остановим и перейдём к более интересным вещам.
4. Защита L2
Для начала ограничим работающие сервисы уровня L2:
Первый скрипт позволяет осуществлять mac-ping только для внутренней сети. Второй ограничивает L2 подключение посредством службы Winbox:
RouterOS поддерживает работу таких протоколов, как CDP, LLDP и MNDP. Чтобы не осуществлять широковещательную рассылку пакетов указанных протоколов во все стороны, ограничиваем их работу:
Чтобы со стороны провайдера не догадывались, что у вас стоит роутер MikroTik, можно сменить MAC адрес WAN интерфейса, но это скорее баловство:
Если в вашем L2 сегменте появится второй или более незаконный DHCP сервер, то это может здорово навредить работе всей сети. Так в примере видно, что работают две указанные службы (192.168.1.1 и 192.168.3.1), раздавая по факту разные сетевые настройки:
Для защиты от такого рода атак (ведь хакер может назначить и своё устройство в качестве шлюза) существует технология «DHCP snooping». После её активации бридж пропускает DHCP пакеты только в доверенную сторону:
Защита оконечных устройств выходит за рамки данной статьи, но декларируем, что многие антивирусы справляются с этой задачей, детектируя манипуляции с ARP пакетами. На скрине видно, что действиями выше мы организовали MITM для хоста 192.168.1.3 и перехватили его HTTP запросы:
В следующем примере показаны ложные записи ARP таблицы маршрутизатора, а ведь так намеренно можно заполнить весь имеющейся пул и втупить работу легитимного DHCP сервера:
Для защиты от таких действий в RouterOS необходимо, первым делом, настроить DHCP сервер, что позволит активировать функцию заполнения ARP таблицы, либо в результате его работы, либо в ручном режиме:
После этого настраиваем бридж, переводя маршрутизатор в режим только ответа на ARP запросы (если у вас работает hotspot, то от этой идеи придётся отказаться, так как он перестанет нормально функционировать), таким образом, сторонние манипуляции будут бессильны:
Дополнительно следует выключить режим обучения портов MAC адресам:
Если ваш маршрутизатор гоняет пакеты для логически разделённых сетей, в том числе с точки зрения безопасности, то их следует разнести по различным VLAN. Важно понимать, что если через ваше устройство проходят несколько VLAN, то в случае несанкционированного доступа к роутеру или коммутатору, могут быть скомпрометированы устройства во всех этих подсетях. Здесь всё понятно. Дополнительно можно указать устройству проверять tag трафика и дропать пакеты, у которых VLAN ID не найден в его таблице VLAN:
5. Заключение
На этой админской ноте прервём наши рассуждения, которые отображают подходы, применяемые нами в построении реальных сетей и обеспечении их информационной безопасности. Никакие ноухау статья не раскрывает, но в определённой мере систематизирует имеющиеся возможности и показывает их практическое применение. Дальше будет интереснее…
Mikrotik конфликт ip адресов
Далее было принято решение запустить поверхностный скан локальной подсети местного провайдера (пара подсетей 192.168.х.х). То, что я увидел, меня шокировало — 58 устройств с критическими проблемами безопасности. Сам софт сканирует уязвимость не только микротиков, но и других устройств.
Структура проблемных устройств, которые мне удалось обнаружить в локальной сети, следующая:
Второе место по количеству уязвимых устройств занимает Mikrotik. Забавно, правда? И корень проблемы даже не в баге RouterOS. К сожалению, большинство пользователей попросту не разбираются в правилах Firewall.
Чаще всего пользователи довольствуются стандартными правилами Firewall и настройками RouterOS, они самодостаточные и не допускают доступ извне к панели управления.
Многие из тех, кто считают себя «продвинутыми» пользователями, начинают бороздить просторы интернета в поисках «идеальных» и «правильных» правил для Firewall. В процессе такой настройки пользователи сносят стандартную конфигурацию, заменяя её правилами из публикаций. Зачастую пользователи даже не понимают суть правил, которые добавляют. Как итог, пользователь получает открытые наружу порты WebFig и winbox! Неожиданно, правда?
Ради интереса я зашел на несколько устройств, найденных софтом — все учетные данные давали успешный вход. Наибольший интерес у меня вызвали устройства с нестандартными логинами и очень сложными паролями для входа. Владельцы данных устройств явно имеют более высокий уровень понимания RouterOS.
Идея обращения к провайдеру была отброшена сразу, провайдер попросту не даст личные данные клиентов по IP, а сам заниматься данным вопросом не станет.
Какими могли быть последствия? Как минимум, некий школьник мог без проблем сбросить конфигурацию — потеря не велика и клиент списал бы все на ошибку ПО. Мог быть и другой сценарий — настройка прокси-сервера, подмена DNS, перехват личных данных и слив файлов на внешнем накопителе (если он подключен к Mikrotik). При желании, злоумышленник может даже поднять VPN-сервер, настроить маршрутизацию и заходить в вашу сеть.
Худший сценарий? Злоумышленник выгружает конфигурацию в RSC-файл и начинает изучение. Что интересного можно найти в файле конфигурации? Очень много… в том числе пароль для PPP-подключения, статические маршруты в удаленную сеть, DNS-записи при их наличии.
Все это было в конкретном случае — и данные VPN, и записи DNS для доступа к сервисам компании в удаленной сети, и все маршруты. По сути, сочетание неправильных правил Firewall и баг в RouterOS позволили бы потенциальному злоумышленнику получить полный доступ в удаленную сеть предприятия.
При этом абсолютно не имеет значения, насколько хорошо защищен главный шлюз предприятия, ведь дыра в безопасности находится на удаленном рабочем месте, у кого-то из сотрудников.
Владелец был незамедлительно уведомлен, после чего выполнил обновление ROS и полную смену паролей.
Я привел лишь единичный пример всего на одном устройстве, хотя из 16 обнаруженных, функционал PPP использовался, по меньшей мере, на 5.
Сейчас вы, наверное, подумаете, мол, это локальная сеть (все устройства за NAT провайдера) и тут никто не станет рисковать, да и в случае чего злоумышленника можно вычислить по логам. Во-первых, если к WAN есть доступ из локальной сети, значит при использовании «белого IP», будет доступ из Интернет, c любой точки мира. Во-вторых, при перезагрузке RouterOS по-умолчанию очищает логи, если не указано хранение на диск, либо не настроена выгрузка на внешний сервер.
Осознаете суть и масштаб проблемы?
В этом плане провайдеры, предоставляющие выход в сеть через NAT хотя-бы частично защищают клиента, те же клиенты у кого на WAN-интерфейсе сразу белый IP — могут рассчитывать только на себя.
Вот пример сканирования внешней подсети того же провайдера:
Авто блокировка MAC в mikrotik за конфликт IP возможна? и как связано с этим видеонаблюдение?
Может ли микротик заблокировать устройства по MAC адресам в случае если сразу 4 устройства находились в сети с одним IP?
Сама сеть выглядит следующим образом. Есть два здания.
В диспетчерской 1го здания стоит микротик и неуправляемый POE свитч для расширения кол-ва портов микротика и запитывания камер по POE. Туда воткнут регистратор и камеры первого здания. Так же от этого свитча идет кабель во второе здание общей протяженностью более 100 метров, но по середине всего маршрута стоит устройство выполняющее роль рипитера. Во втором здание стоит так же POE свитч неуправляемый, в который и воткнуты эти 5 камер из которых 4 не определяются в сети.
И есть еще один момент, все концы кабеля витой пары каким то умником, который собственно видимо все это и монтировал знакомым, обжаты не по стандарту. Вместо обжима по B схеме. Все концы начиная с кабеля идущего от первого здания до второго обжаты в следующем порядке:
1. бело-оранжевый,
2. оранжевый,
3. бело-синий,
4. синий
5. бело-зеленый
6. зеленый
7. бело-коричневый
8. коричневый
В принципе вроде бы это и не должно влиять, ведь на всех концах так криво обжато одинаково. Следовательно перекрестий никаких нет. Но 3 и 6 контакты не по парным жилам идут. Может быть это и есть всему причиной? Переобжимать как положено пока не пробовали, т.к. эти 4 камеры находятся не на легко доступной высоте над землей с улицы.
Индикаторы сети в свитче при включение этих камер горят/моргают.
