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

понедельник, 30 апреля 2018 г.

Защита NAT на Mikrotik.

  У нас есть Mikrotik за ним вроде защищенная сеть. Теперь читаем это:


  Потом читаем это:

  И напоследок смотрим это:


  Bogon-сети мы конечно запретили из WAN, но чем черт не шутит. На выходе получаем настройку защиты наших внутренних устройств от внешних запросов которые могут попасть под NAT:
/ip firewall filter
add action=accept chain=forward comment=Accept_Established&Related_forward connection-state=established,related,untracked
add action=drop chain=forward comment=Drop_Invalid_forward connection-state=invalid
add action=drop chain=forward comment=Drop_New_no_dstnat_forward connection-nat-state=!dstnat connection-state=new in-interface-list=wan

среда, 15 февраля 2017 г.

Защита Wi-Fi в Mikrotik.

Версия RoS 6.39rc27 

  За защиту WiFi сети в Mikrotik отвечают три вкладки: Access List (/interface wireless access-list), Connect List (/interface wireless connect-list), Security Profiles (/interface wireless security-profiles).


  Access List - список правил, которые ограничивают соединения других устройств к вашей точке, а также служат для управления параметрами подключения. (режим ap mode). 
  Пример: вы хотите ограничить подключение к вашей точке доступа по MAC-адресам.
  Connect List - список правил, которые ограничивают соединение вашего устройства к другим точкам доступа (режим station mode). 
  Пример: вы хотите автоматически подключать свою клиентскую станцию к точке доступа с максимальным уровнем сигнала (при наличии нескольких базовых станций).
  Security Profiles - настраиваются профили методов защиты и, непосредственно, ключи защиты беспроводной сети.

понедельник, 6 февраля 2017 г.

Защита SIP-порта. Часть 2: анализ пакетов.

  Для защиты SIP-порта можно использовать анализ пакетов с помощью опции "content" в Firewall Mikrotik. Но, для начала, нам нужно узнать, что именно посылает наш сервер телефонии на неправильный логин и пароль. Для примера возьмем самый популярный сервер телефонии - Asterisk с веб-интерфейсом FreePBX. Перво-наперво можно изучить, какие именно стандартные ответы дает SIP-сервер:
SIP/2.0 400 Bad Request - запрос не понят из-за синтаксических ошибок в нем, ошибка в сигнализации, скорее всего что-то с настройками оборудования
SIP/2.0 401 Unauthorized - нормальный ответ сервера о том, что пользователь еще не авторизировался; обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль
SIP/2.0 401 Expired Authorization - время регистрации истекло
SIP/2.0 402 Payment Required - требуется оплата (зарезервирован для использования в будущем)
SIP/2.0 403 No Such User - нет такого пользователя, ошибка в номере, логине или пароле
SIP/2.0 403 User Disabled - пользователь отключен
SIP/2.0 403 Wrong Guess - ошибка в пароле
SIP/2.0 403 Conflict - такой SIP-номер уже используется
SIP/2.0 403 Forbidden - абонент не зарегистрирован
SIP/2.0 403 Empty Route Set - нет ни одного шлюза в роутинге
SIP/2.0 403 Caller Not Registered - нет такого пользователя
SIP/2.0 403 Out of Look-Ahead Retries - перебор узлов закончен
SIP/2.0 403 Invalid Phone Number - нет такого направления
SIP/2.0 403 No Money Left on RFC Account - на счету нет денег для совершения звонка
SIP/2.0 404 Not found - вызываемый абонент не найден, нет такого SIP-номера
SIP/2.0 404 Undefined Reason - неопределенное направление
SIP/2.0 404 Unknown user account - логин и пароль не найдены
SIP/2.0 404 Out of Order - в заявке на маршрутизацию по этому направлению нет ни одного шлюза, проверьте настройку маршрутизации по этому направлению.
SIP/2.0 405 Method Not Allowed - метод не поддерживается, может возникать если пользователь пытается отправлять голосовую почту и т.п.
SIP/2.0 406 No codecs match - неправильная конфигурация кодеков
SIP/2.0 406 Not Acceptable - пользователь не доступен
SIP/2.0 407 Proxy Authentication Required - необходима аутентификация на прокси-сервере
SIP/2.0 408 Request Timeout - время обработки запроса истекло: Абонента не удалось найти за отведенное время
SIP/2.0 408 Login timed out - за отведенное время не получен ответ от сервера на запрос авторизации
SIP/2.0 410 No Route - вариант SIP/2.0 403 Empty Route Set; нет доступа к ресурсу: Ресурс по указанному адресу больше не существует
SIP/2.0 413 Request Entity Too Large - размер запроса слишком велик для обработки на сервере
SIP/2.0 415 No Media - звонок совершается неподдерживаемым кодеком
SIP/2.0 416 Unsupported Scheme - сервер не может обработать запрос из-за того, что схема адреса получателя ему непонятна
SIP/2.0 420 Bad extension - неизвестное расширение: Сервер не понял расширение протокола SIP
SIP/2.0 421 Extension Required - в заголовке запроса не указано, какое расширение сервер должен применить для его обработки
SIP/2.0 423 Interval Too Brief - сервер отклоняет запрос, так как время действия ресурса короткое
SIP/2.0 480 Invalid Phone Number - неправильный номер телефона, не соответствует к-во цифр или неправильный код страны или города
SIP/2.0 480 Destination Not Found In Client Plan - направления нет в тарифном плане абонента
SIP/2.0 480 Wrong DB Response - проблемы с центральной базой сети
SIP/2.0 480 DB Timeout - проблемы с центральной базой сети
SIP/2.0 480 Database Error - проблемы с центральной базой сети
SIP/2.0 480 Codec Mismatch - несоответствие кодеков
SIP/2.0 480 No Money Left on RFC Account - нет денег на счету, обратитесь к администратору сети!!!
SIP/2.0 480 Empty Route Set - пустое направление, нет принемающих шлюзов
SIP/2.0 480 No money left - недостаточно денег на счете
SIP/2.0 480 Temporarily Unavailable - временно недоступное направление попробуйте позвонить позже
SIP/2.0 481 Call Leg/Transaction Does Not Exist - действие не выполнено, нормальный ответ при поступлении дублирующего пакета
SIP/2.0 482 Loop Detected - обнаружен замкнутый маршрут передачи запроса
SIP/2.0 483 Too Many Hops - запрос на своем пути прошел через большее число прокси-серверов, чем разрешено
SIP/2.0 484 Address Incomplete - принят запрос с неполным адресом
SIP/2.0 485 Ambiguous - адрес вызываемого пользователя не однозначен
SIP/2.0 486 Busy Here - абонент занят
SIP/2.0 487 Request Terminated - запрос отменен, обычно приходит при отмене вызова
SIP/2.0 488 Codec Mismatch - нет шлюзов с поддержкой заказанного кодека
SIP/2.0 488 Private IP Address - адрес RTP media из сетей RFC1918
SIP/2.0 491 Request Pending - запрос поступил в то время, когда сервер еще не закончил обработку другого запроса, относящегося к тому же диалогу
SIP/2.0 493 Undeciperable - сервер не в состоянии подобрать ключ дешифрования: невозможно декодировать тело S/MIME сообщения
SIP/2.0 499 Codec Mismatch - отсутствует кодек

пятница, 3 февраля 2017 г.

Защита SIP-порта с помощью Mikrotik.

  Иногда нужно выбросить наружу SIP-порт для клиентов, которые подключаются к вашей IP-телефонии. Открытый SIP-порт, особенно стандартный (5060 UDP), очень уязвим и рано или поздно вас начнут взламывать, подбирать пароли и т.д. Это чревато не только возможностью угадать пароль, но и нагрузкой на ваш сервер телефонии и интернет-канал. Есть несколько рекомендаций для защиты.
  Общая рекомендация - не использовать стандартный порт. В дополнение, на стандарнтый порт можно повесить ловушку:
/ip firewall filter
add action=add-src-to-address-list address-list=sip_drop address-list-timeout=30m chain=input comment=sip_add_list dst-port=5060 in-interface=ether1-wan log=yes log-prefix=Sip-Attack protocol=udp
add action=drop chain=input comment=sip_list_drop in-interface=ether1-wan src-address-list=sip_drop

понедельник, 9 января 2017 г.

Подключение к веб-интерфейсу Mikrotik используя ssl протокол.

  Выставляя в "мир" нужные нам сервисы мы всегда рискуем. Поэтому желательно по-максимуму защитить наше оборудование. Удаленное подключение к нашим маршрутизаторам следует оставлять только с определенных подсетей, оставляя минимум сервисом, меняя стандартные логины и применяя сложные пароли с регулярной сменой. Так-же в обязательном порядке менять порты сервисов по-умолчанию. Можно организовать открытие портов через определенный порядок действий (например, технология port knocking).
  Незащищённое http-соединение опасно тем, что любой, кто слушает трафик, прекрасно видит все данные, которые вы передаете на сайт, по протоколам POST или GET. Так как мы не хотим, что-бы злоумышленники получили доступ к нашему роутеру - для этого нам необходим специальный сертификат. Как правило, сертификаты подтверждают центры сертификации. Но мы можем сгенерировать сертификат самостоятельно - такой сертификат называется самоподписанным, так как его подтверждаете лично вы. Для сайтов самоподписанный сертификат, конечно, не подойдет, но для личных целей вполне будет достаточно.
  Обращаю ваше внимание на то, что при использовании самоподписного сертификата вы будете видеть окно: "Сертификат безопасности сайта не является доверенным", что может быть не очень понятно неосведомленным пользователям.
 Сейчас я хочу описать как можно сгенерировать самоподписанный сертификат и включить безопасное соединение www-ssl для управления нашим роутером.
  Открываем System/Certificates, добавляем новый сертификат.


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

Защита Mikrotik. Часть 2: Мания преследования.

  В дополнение к основной статье Защита WAN-интерфейса в Mikrotik хочется отметить несколько важных моментов в безопасности вашего маршрутизатора. Описанные тут пункты не имеют критически важное значение в защите роутера Mikrotik, но, в комплексе, помогают защитить маршрутизатор еще лучше. Я специально буду продолжать пункты, описанные в предыдущем материале, что бы подчеркнуть - эта статья является продолжением и дополнением первой и отдельно рассматриваться не может.
  Не смотря на запрещающее правило в пункте 13 ("add action=drop chain=input comment=Drop_all_WAN in-interface=ether1-velton")  в конце первой статьи, рекомендую проверить активность сервисов. Если какой-то сервис не используется - в целях безопасности его отключить.

14) Проверяем сервис SNMP в IP/SNMP. По-умолчанию он выключен. Если мы его не используем - проследите что-бы не стояла галочка Enabled. Если используем - позаботитесь о его защите.


среда, 5 октября 2016 г.

Защищаем сервер FTP за Mikrotik анализируя пакеты опцией "content".

  Недавно в статье "Защита WAN-интерфейса в Mikrotik" я рассказывал как защитить наше устройство и минимизировать атаки из-вне. Но почти во всех конфигурациях мы используем пробросы портов для предоставления сервисов нашим клиентам или для личного пользования. Пробросив порт, защиту мы возлагаем на наш внутренний сервис. Но Mikrotik довольно универсально устройство, которое позволяем защитить даже наши внутренние сервисы, к которым мы можем подключиться из-вне. В текущей статье, на примере FTP-сервера, я покажу вариант такой реализации.
  Имеем FTP-сервер Serv-U File Server, на который проброшен порт 21 с WAN-интерфейсов (их 2) Mikrotik. Сразу скажу, я никогда не использую дефолтный порт, так как это небезопасно, но для примера подойдет.
  Правило проброса порта:
/ip firewall nat
add action=dst-nat chain=dstnat comment=ftp dst-address-list=wan dst-port=21 protocol=tcp to-addresses=10.2.0.7
  Где "wan" - адрес лист наших wan-интерфейсов (их два, с обоих сервер доступен), 10.2.0.7 - адрес нашего ftp-сервера.
  После этого мы попробуем защитить ftp от перебора паролей. Для этого воспользуемся опцией "content" в правилах /ip firewall. Эта опция позволяет проанализировать пакеты которые входят\проходят\выходят из маршрутизатора и найти текстовые соответствия в этих пакетах - если соответствие найдено - выполняется определенное действие.


вторник, 6 сентября 2016 г.

Как оградить MikroTik от хакеров и спамеров.

  Думая о том, как защитить маршрутизатор от внешних вторжений пришла в голову мысль о том, что не только один я сталкиваюсь с этой проблемой. Поэтому я начал искать в интернете сервисы, которые помогают компаниям с выявлением угроз. В интернете есть ряд сайтов, которые отслеживают злоумышленников, спамеров, брутфорсеров и заносят их IP в некие "черные" списки. Происходит это автоматически, и частота обновления этих списков довольно частая (часы, сутки). Почему бы не воспользоваться этими списками для составления адрес-листов в RouterOS.
  Фактически реализовать это не сложно. Списки в основном представлены в виде txt файлов, автоматически загрузив которые, через "/tool fetch", можно с ними оперировать. Для начала извлечь IP в address-list немного поработав над обработкой структуры файла (а она для каждого сервиса разная). Этим я решил и заняться, вопрос решаем... Но, чисто случайно, наткнулся на сайт joshaven.com, где Joshaven Potter уже это все реализовал, и любезно поделился со всеми. Мало того, даже создал собственную платформу для преобразования IP-листов, и дал доступ к этим спискам. За что ему огромное человеческое спасибо!

  Итак, разберем что-же нам предлагают. Предлагается вариант с добавлением "черных IP" с сервисов:

  • OpenBL - сервис, ранее известен как SSH blacklist, выявляет различные виды угроз в Интернет. Сервис содержит ряд хостов, в которых мониторятся разные порты: 21 (FTP), 22 (SSH), 23 (TELNET), 25 (SMTP), 110 (POP3), 143 (IMAP), 587 (Submission), 993 (IMAPS) и 995 (POP3S) на наличие брутфорс атак, а также анализирует запросы на порты 80 (HTTP) и 443 (HTTPS) для "левых", явно представляющих угрозу, подключений (атака на PHPMyAdmin и другие веб-сервисы).
  • Spamhaus - сервис предоставляющий списки адресов, которые используются известными спамерами и хакер-группировками. Так же сюда попадают списки адресов и автономных систем которых "хакнули" и с помощью их распространяют вредоносное ПО или производят атаки.
  • dshield.org - сервис предоставляет топ 20 IP класса C (/24) подсетей, с которых были атаки, за последние 3-е суток.
  • malc0de.com - блэклист обновляется ежедневно. Туда заносятся опасные IP, с которых были документированные атаки (или распространение вредоносного ПО) за последние 30 дней.

воскресенье, 7 августа 2016 г.

Защита WAN-интерфейса в Mikrotik.

  После первоначальной настройки роутера Mikrotik его нужно защитить от сканирования и атак из WAN-интерфейса. Это нужно делать обязательно, во избежания неприятностей. Защиту внутри локальной сети тоже нужно производить, но она не так критична, хотя и важна. Сами методы разделю по пунктам.

  1) Отключаем учетную запись admin. Создаем новую учетную запись, Имя должно быть не общепринятое, что-бы комбинация логин-пароль служила доп. защитой. Не используйте имена user, guest, admin и другие стандартные. Не используйте пароли 12345, qwerty и тому подобные, а также совпадающие с логином. Пароль должен быть не меньше 8 символов, содержать буквы верхнего и нижнего регистров, цифры и, в идеале, символы.


четверг, 14 января 2016 г.

Port knocking Mikrotik используя Web Proxy.

  Я думаю все знают что такое port knocking, но на всякий случай напишу. Port knocking - метод внешнего открытия портов путем обращения к маршрутизатору генерируя определенные пакеты на известные открытые порты. Играет роль именно последовательность отосланных пакетов, их размер и порт на который они обращаются. Иными словами, порт является по-умолчанию закрытым, но  только до тех пор, пока на него не поступит заранее определённая последовательность пакетов данных, которая "заставит" порт открыться.
  Основная цель - предотвратить злоумышленнику сканирование вашего устройства на наличие потенциально пригодных для использования уязвимостей, делая сканирование порта.  И только из-за того, что злоумышленник не посылает правильную последовательность - защищенные порты остаются закрыты.
  Естественно, в Mikrotik такую возможность реализовать можно, в интернете по этому поводу написано много статей. Например, официальная WiKi приводит в пример эту статью. Они предлагают для доступа на ваш маршрутизатор постучать последовательно по 9000, а потом по 6000 порту для открытия доступа к маршрутизатору. Постучать можно через nmap command, установив knockd package в linux или через браузер. В других статьях описывается открытие портов через протокол icmp, используя ICMP-пакеты (пинг) разных размеров пакета в определенной последовательности. Метод довольно защищенный, но достаточно неудобен. Вообщем, использование Port knocking сводится к настройке, пару-тройку дней тестирования, и отключения, т.к. он требует дополнительных манипуляций до подключения, времени на который, как правило нет. ICMP запросы требуют командной строки или спец-по, простукивания по разным портам - аналогично. 
  Задача у меня стояла такая - сделать безопасный доступ к роутеру Mikrotik с любой точки планеты, с любого компьютера, смартфона, планшета, с любого интернета, будь то HOTSPOT в аэропорту, или любая другая сеть. Для этого был выбран сервис www-ssl.

пятница, 13 ноября 2015 г.

Маскируем наш роутер в сети провайдера от TTL-фильтра.

   Теория:
  В IPv4 TTL представляет собой восьмиразрядное поле IP-заголовка.
 Определяет максимальное количество хопов (hop, то есть прыжок, участок между маршрутизаторами), которые пакет может пройти. Наличие этого параметра не позволяет пакету бесконечно ходить по сети. Каждый маршрутизатор, при маршрутизации должен уменьшать значение TTL на единицу, но некоторые шлюзы можно настроить, чтобы игнорировать это. Пакеты, не достигшие адресата, но время жизни которых стало равно нулю, уничтожаются, а отправителю посылается сообщение ICMP Time Exceeded. Если требуется, чтобы пакет не был маршрутизирован (то есть принят только в своём сегменте), то выставляется TTL=1. На отправке пакетов с разным временем жизни основана трассировка их пути прохождения (traceroute). Максимальное значение TTL=255. Обычное начальное значение TTL=64 (зависит от ОС).

   Добавим правило в Mikrotik,  что бы с имитировать конечное устройство:
/ip firewall mangle add action=change-ttl chain=prerouting new-ttl=increment:1 passthrough=yes