Блог о моих заметках.

Dynamic ARP Inspection — технология (by Cisco), позволяющая пропускать ARP-запросы только для тех адресов, которые были выданы по DHCP. Данная технология помогает защититься от атак с использованием протокола ARP (например, ARP-spoofing) и ограничивает пользователей в возможности указания IP адреса “вручную”.

Суть технологии сводится к двум этапам:
1) Перехват всех ARP-запросов и ARP-ответов прежде чем перенаправлять их;
2) Проверка соответствия MAC-адреса и IP-адреса из статической ARP таблицы, либо таблицы выданных адресов DHCP.

Как оказалось, в маршрутизаторах от Mikrotik нашлась возможность реализовать данную технологию.

Для настройки необходимо:
1. В конфигурации “IP -> DHCP Server” поставить галочку “Add ARP For Leases”. При выборе этой опции DHCP сервер будет автоматически добавлять записи в ARP-таблицу маршрутизатора;
2. В настройки интерфейса (бриджа) необходимо для ARP выставить reply-only. Эта опция переведет таблицу ARP на выбранном интерфейсе (бридже) в режим “только чтение” и не будет принимать ARP-запросы.

Таким образом, маршрутизатор будет коммутировать только те пакеты, для которых DHCP добавит ARP запись.

Допустим, вы настроили проброс портов на роутере MikroTik, и из внешней сети все прекрасно работает. Но иногда может возникнуть необходимость организовать доступ к компьютеру или серверу по внешнему IP-адресу не только извне, но и из локальной сети. В этом случае применяется так называемый Hairpin NAT или NAT LoopBack — прием-отправка пакетов через один и тот же интерфейс роутера, со сменой адресов с локального на внешний и обратно. Разберем нужные настройки.

Допустим у нас есть:

1. Роутер с внешним IP (WAN IP) 1.1.1.1.
2. Компьютер с локальным адресом 192.168.88.229, и запущенным на нем сервером, приложением и т. д. для доступа из внешней сети. В нашем случае для соединения используется порт 8080.
3. Компьютер в локальной сети с адресом 192.168.88.110.

У нас уже есть настроенное правило проброса порта 8080:

Но оно не будет срабатывать при обращении из локалки, так как настройки ориентированы на пакеты из внешней сети, через WAN-порт. Поэтому нам нужно прописать дополнительно еще 2 правила.

Настройка доступа из локальной сети по внешнему IP-адресу

1. Создаем правило для перенаправления обращений по внешнему IP из локальной сети.

Вкладка General.

Chain  — dstnat.

Src. Address — пишем здесь локальный адрес компьютера, с которого будем заходить по внешнему IP, или диапазон адресов, если такой доступ нужно предоставить нескольким компьютерам сети.

Dst. Address — указываем внешний адрес компьютера/ сервера и т. п., по которому будет осуществляться доступ из локалки.

Protocol,  Dst. Port — здесь прописываем параметры порта и протокола, которые соответствуют нашему соединению (те же, что и в пробросе портов).

Вкладка Action.

To Addresses — указываем локальный адрес нашего сервера, компьютера, на который мы заходим по внешнему IP-адресу.

To Ports — порт тот же самый, что на предыдущей вкладке, поэтому здесь можно ничего не указывать.

Теперь на компьютер 192.168.88.229 можно зайти из локальной сети по внешнему IP-адресу 1.1.1.1.

Но при попытке какого-то взаимодействия с ним ничего не получится. Почему? Посмотрим, что происходит.

• Наш компьютер (192.168.88.110) посылает пакет на внешний адрес сервера, который является и адресом роутера, соответственно — 1.1.1.1.
• Роутер добросовестно перенаправляет его по нашему правилу dst-nat на компьютер с адресом 192.168.88.229.
• Тот его принимает и отправляет ответ. Но так как он видит в качестве адреса источника локальный IP-адрес (ведь пакет поступил от компьютера в локальной сети), он отправляет ответ не на маршрутизатор, а напрямую получателю.
• Получатель же (192.168.88.10) отправляя данные по внешнему IP, и ответ также ожидает от внешнего IP. Получив пакет от локального 192.168.88.229, он его просто сбрасывает, как ненужный.

Поэтому нам нужно еще одно правило, которое будет подменять локальный адрес источника при отправке пакета на внешний IP.

2. Подменяем локальный адрес компьютера на внешний IP-адрес.

На вкладке Action выставляем маскарадинг (masquerade), т. е. подмену адреса источника на локальный адрес маршрутизатора.

На вкладке General прописываем правила, при которых он будет применяться:

Chain  — srcnat, т. е. при запросах из локальной сети.

Src. Address — пишем здесь локальный адрес компьютера, или диапазон адресов, с которых будут отправляться пакеты.

Dst. Address — здесь конкретизируем «адрес получателя», т. е. правило будет применяться только для пакетов, адресованных нашему серверу.

Protocol,  Dst. Port — здесь прописываем те же параметры порта и протокола.

Теперь, получив пакет из локальной сети, адресованный на внешний IP 1.1.1.1, маршрутизатор не только перенаправит его на 192.168.88.229 (по первому правилу), но и заменит в пакете адрес источника (192.168.88.110) на свой локальный адрес.

Ответ от сервера поэтому отправится не напрямую в локальную сеть, а на маршрутизатор, который, в свою очередь направит его источнику.

Второй способ Hairpin NAT MikroTik: 2 правила вместо 3

Можно сделать еще проще, заменив правило проброса портов первым правилом Hairpin NAT. В этом случае в настройках не нужно указывать In. Interface и Src Address, но нужно прописать адрес назначения.

Доступ на внешний IP адрес вашего сервера или компьютера с приложением будет открыт как для обращений извне, так и из локальной сети, с любых адресов, но только для пакетов с адресом назначения 1.1.1.1:80.

Теперь добавляете описанное выше правило srcnat, и все.  Можно добавить дополнительную фильтрацию, прописав в out-interface тот интерфейс, с которого будут осуществляться отправки пакетов, если есть такая необходимость.

Недостатком Hairpin NAT является только то, что нагрузка на роутер возрастает, ведь те обращения, что раньше проходили через локальную сеть непосредственно между компьютерами, теперь будут идти через маршрутизатор.

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

Оповещение администратора о входе в Mikrotik.

  Скрипт, который создан для обеспечения безопасности вашего устройства. Он анализирует логи Mikrotik, при наличии НОВЫХ записей входа (удачного или неудачного) на устройство — отсылает e-mail администратору. Сам скрипт можно настроить таким образом, что-бы он исключал «легитимные» входы с наших IP, а отсылал сообщения только тогда, когда входы совершаются с чужих адресов. Скрипт проверят наличие всех записей с последнего старта, и потом все найденые совпадения шлет на е-мейл. Проверен на 6.37rc5.
Переведу ключевые моменты.

  # BEGIN SETUP
# имя скрипта в scheduler
:local scheduleName «on_login»
# мыло на которое отправлять отчет
:local emailAddress «test@gmail.com»
# записи в логе по маске, которые попадают в отчет
:local startBuf [:toarray [/log find message~»logged in» || message~»login failure»]]
# слова-исключения. Сюда добавляем наши «легитимные» IP, или, например, сервисы по которым не хотим отслеживать подключения.
:local removeThese {«telnet»;»192.168.88.27″}
# smtp сервер
:local smtpserv [:resolve «smtp.yandex.ru»];
# мыло с которого будет все отправляться
:local email «mikrotik@yandex.ru»;
# пароль к мылу
:local pass SuperPass;
# END SETUP
# проверяем существует ли запись в планировщике, если нет — выдаем ошибку в лог
:if ([:len [/system scheduler find name=»$scheduleName»]] = 0) do={
/log warning «[LOGMON] ERROR: Schedule does not exist. Create schedule and edit script to match name»
}
# определяем последнее время запуска скрипта
:local lastTime [/system scheduler get [find name=»$scheduleName»] comment]
# for checking time of each log entry
:local currentTime
# log message
:local message

# вводим переменную output
:local output
:local keepOutput false
# if lastTime is empty, set keepOutput to true
:if ([:len $lastTime] = 0) do={
:set keepOutput true
}

:local counter 0
# loop through all log entries that have been found
:foreach i in=$startBuf do={

# loop through all removeThese array items
:local keepLog true
:foreach j in=$removeThese do={
#   if this log entry contains any of them, it will be ignored
:if ([/log get $i message] ~ «$j») do={
:set keepLog false
}
}
:if ($keepLog = true) do={

:set message [/log get $i message]
#   LOG DATE
#   depending on log date/time, the format may be different. 3 known formats
#   format of jan/01/2002 00:00:00 which shows up at unknown date/time. Using as default
:set currentTime [ /log get $i time ]
#   format of 00:00:00 which shows up on current day’s logs
:if ([:len $currentTime] = 8 ) do={
:set currentTime ([:pick [/system clock get date] 0 11].» «.$currentTime)
} else={
#     format of jan/01 00:00:00 which shows up on previous day’s logs
:if ([:len $currentTime] = 15 ) do={
:set currentTime ([:pick $currentTime 0 6].»/».[:pick [/system clock get date] 7 11].» «.[:pick $currentTime 7 15])
}
}

#   if keepOutput is true, add this log entry to output
:if ($keepOutput = true) do={
:set output ($output.$currentTime.» «.$message.»\r\n»)
}
#   if currentTime = lastTime, set keepOutput so any further logs found will be added to output
#   reset output in the case we have multiple identical date/time entries in a row as the last matching logs
#   otherwise, it would stop at the first found matching log, thus all following logs would be output
:if ($currentTime = $lastTime) do={
:set keepOutput true
:set output «»
}
}
#   if this is last log entry
:if ($counter = ([:len $startBuf]-1)) do={
#   If keepOutput is still false after loop, this means lastTime has a value, but a matching currentTime was never found.
#   This can happen if 1) The router was rebooted and matching logs stored in memory were wiped, or 2) An item is added
#   to the removeThese array that then ignores the last log that determined the lastTime variable.
#   This resets the comment to nothing. The next run will be like the first time, and you will get all matching logs
:if ($keepOutput = false) do={
#     if previous log was found, this will be our new lastTime entry
:if ([:len $message] > 0) do={
:set output ($output.$currentTime.» «.$message.»\r\n»)
}
}
}
:set counter ($counter + 1)
}
# If we have output, save new date/time, and send email
if ([:len $output] > 0) do={
/system scheduler set [find name=»$scheduleName»] comment=$currentTime
/tool e-mail send server=$smtpserv port=587 user=$email password=$pass start-tls=yes to=»$emailAddress» from=$email subject=»MikroTik alert $currentTime» body=»$output»
/log info «[LOGMON] New logs found, send email»
}

Сообщения приходят такого вида:

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

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

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

2) Отключаем ненужные сервисы, все нужные переводим на не стандартные порты! Список не зарезервированных портов можно найти в Википедии: Список портов TCP и UDP. Доступ из-вне отставляем только реально нужным сервисам. Если есть возможность, сервисы ограничиваем по подсетям.

3)  Отключаем «поиск соседей». MNDP (Neighbor Discovery Protocol) — протокол, с его помощью роутеры MikroTik получают информацию друг о друге и могут выполнить автоматическую настройку некоторых функций. Однако протокол MNDP передает информацию о версии операционной системы и функции, которые включены в роутере. Отключаем в ip/neighbors поиск на WAN-интерфейсе.

  4) Отключаем подключение к роутеру по MAC-адресу из-вне в Tools/MAC Server. На вкладках Telnet Interfaces и WinBox Interfaces добавляем интерфейс LAN, удаляем если есть любые другие интерфейсы и отключаем интерфейс «*all».

  Теперь идет настройка непосредственно firewall, правила имеют очередность, поэтому команды выполнять в последовательности. Перед началом работ сделайте бекап. И помните — удаленная настройка фаервола -к выезду!

5) Организовываем ловушку от перебора портов. Грубый метод. В пункте 8 будет представлено более утонченное решение. Но в нашем деле все методы хороши. Теория такова, если злоумышленник будет перебирать открытые порты вашего маршрутизатора, при попадании на определенный порт, этот IP попадет в блек-лист. Порт нужно выбирать осторожно, что бы он нигде в вашей конфигурации не использовался, и был свободен. После того как определились с портом, добавим 2 правила.

/ip firewall filter
add action=add-src-to-address-list address-list=perebor_portov_drop address-list-timeout=30m chain=input comment=Perebor_portov_add_list dst-port=22 in-interface=ether1-velton log=yes log-prefix=Attack protocol=tcp
add action=drop chain=input comment=Perebor_portov_list_drop in-interface=ether1-velton src-address-list=perebor_portov_drop

Первым правилом при обращении на порт 22 IP добавляем в дроп-лист «perebor_portov_drop». Вторым правилом — баним его. В последнем скриншоте этих правила нет, но они идут в начале списка в /ip firewall filter.
* На «MUM Москва 2016» докладчик рассказывал, что ловит злоумышленников в эту ловушку на популярные порты. Например SSH (22/TCP) или RDP (3389/TCP). Можно еще добавить SIP-порт (5060). Вероятность скана именно этих портов — велика. Если вы их не используете для доступа из-все (что разумно) — смело можно воспользоваться этим методом.

6) Ограничиваем количество ICMP-запросов (делаем защиту от флуд-пинг). Вводим дополнительное правило Drop для отслеживания ICMP Drop. Последнее правило не обязательно — нужно лишь для визуального представления администратору сколько пакетов словилось. Необязательное — потому-как в конце у нас все не разрешенные запросы с WAN — блокируются.

/ip firewall filter
add chain=input comment=Allow_limited_pings in-interface=ether1-velton limit=\
50/5s,2:packet protocol=icmp
add action=drop chain=input comment=Pings_Drop in-interface=ether1-velton \
protocol=icmp

  7) Ставим лимит входящих соединений. Если с одного IP адреса подключений больше лимита, то этот IP попадает в «черный список» и в дальнейшем блокируется. Например

/ip firewall filter add chain=input protocol=tcp connection-limit=LIMIT,32 \
action=add-src-to-address-list address-list=blocked-addr address-list-timeout=1d

Где LIMIT — максимальное количество соединений в определенного IP. Предел должен быть от 100 и выше, так как многие услуги, используют несколько соединений (HTTP, Torrent, и другие P2P-программы). После того как пакеты добавлены в address-list можно выставить их drop или опцию tarpit. Она позволяет вместо того чтобы просто удалять пакеты атакующего — захватить и удерживать соединения и с достаточно мощным маршрутизатором это может замедлить скорость атаки.

/ip firewall filter add chain=input protocol=tcp src-address-list=blocked-addr \
connection-limit=3,32 action=tarpit

  Но нам такие сложности не к чему, просто добавим правило с лимитом 200 соединений с одного IP и блоком на сутки:

/ip firewall filter
add action=add-dst-to-address-list address-list=connection-limit \
address-list-timeout=1d chain=input comment=Connection_limit \
connection-limit=200,32 in-interface=ether1-velton protocol=tcp
add action=drop chain=input comment=Adr_list_connection-limit_drop \
in-interface=ether1-velton src-address-list=connection-limit

  8) Включаем защиту от сканеров портов на WAN-интерфейсе:

/ip firewall filter
add action=drop chain=input comment=Port_scanner_drop src-address-list=\
«port scanners»
add action=add-src-to-address-list address-list=»port scanners» \
address-list-timeout=2w chain=input in-interface=ether1-velton protocol=\
tcp psd=21,3s,3,1
add action=add-src-to-address-list address-list=»port scanners» \
address-list-timeout=2w chain=input in-interface=ether1-velton protocol=\
tcp tcp-flags=fin,!syn,!rst,!psh,!ack,!urg
add action=add-src-to-address-list address-list=»port scanners» \
address-list-timeout=2w chain=input in-interface=ether1-velton protocol=\
tcp tcp-flags=fin,syn
add action=add-src-to-address-list address-list=»port scanners» \
address-list-timeout=2w chain=input in-interface=ether1-velton protocol=\
tcp tcp-flags=syn,rst
add action=add-src-to-address-list address-list=»port scanners» \
address-list-timeout=2w chain=input in-interface=ether1-velton protocol=\
tcp tcp-flags=fin,psh,urg,!syn,!rst,!ack
add action=add-src-to-address-list address-list=»port scanners» \
address-list-timeout=2w chain=input in-interface=ether1-velton protocol=\
tcp tcp-flags=fin,syn,rst,psh,ack,urg
add action=add-src-to-address-list address-list=»port scanners» \
address-list-timeout=2w chain=input in-interface=ether1-velton protocol=\
tcp tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg

9) Защищаем от перебора паролей подключения по нестандартному порту к WinBox и SSH из вне. Комментарии читать снизу-вверх.

/ip firewall filter
# все IP в black_list — отклоняем
add action=drop chain=input comment=Drop_winbox_black_list dst-port=5323,5324 \
in-interface=ether1-velton protocol=tcp src-address-list=black_list
# если новые подключения с адрес-листа Winbox_Ssh_stage3 продолжаются — заносим в новый адрес-лист black_list на 5 минут.
add action=add-src-to-address-list address-list=black_list \
address-list-timeout=5m chain=input comment=Winbox_add_black_list \
connection-state=new dst-port=5323,5324 in-interface=ether1-velton \
protocol=tcp src-address-list=Winbox_Ssh_stage3
# если новые подключения с адрес-листа Winbox_Ssh_stage2 продолжаются — заносим в новый адрес-лист Winbox_Ssh_stage3
add action=add-src-to-address-list address-list=Winbox_Ssh_stage3 \
address-list-timeout=1m chain=input comment=Winbox_Ssh_stage3 \
connection-state=new dst-port=5323,5324 in-interface=ether1-velton \
protocol=tcp src-address-list=Winbox_Ssh_stage2
# если новые(значит была неудачная попытка, например — неправильный пароль, и соединение разорвалось) подключения с адрес-листа Winbox_Ssh_stage1 продолжаются — заносим в новый адрес-лист Winbox_Ssh_stage2
add action=add-src-to-address-list address-list=Winbox_Ssh_stage2 \
address-list-timeout=1m chain=input comment=Winbox_Ssh_stage2 \
connection-state=new dst-port=5323,5324 in-interface=ether1-velton \
protocol=tcp src-address-list=Winbox_Ssh_stage1
# заносим все айпи, которые создали новые подключения на наши порты в адрес-лист на 1 минуту
add action=add-src-to-address-list address-list=Winbox_Ssh_stage1 \
address-list-timeout=1m chain=input comment=Winbox_Ssh_stage1 \
connection-state=new dst-port=5323,5324 in-interface=ether1-velton \
protocol=tcp
# разрешаем подключение к Winbox и Ssh по портам 5323 и 5324
add chain=input comment=Accept_Winbox_Ssh dst-port=5323,5324 in-interface=\
ether1-velton protocol=tcp

10) Блокируем bogon-сети. Это зарезервированные диапазоны IP адресов которые еще не были закреплены ни за одним провайдером в мире. Это свободные/пустые диапазоны. Частные сети прячутся от интернета средствами компании или провайдером. Поэтому если к вам вдруг прилетает пакет с сорсом из этих списков, ничего хорошего он принести не может. Bogon IP часто используют злые хакеры для своих вредоносных атак. Актуальный список сетей можно посмотреть тут: http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt.

/ip firewall address-list
add address=0.0.0.0/8 disabled=no list=BOGON
add address=10.0.0.0/8 disabled=no list=BOGON
add address=100.64.0.0/10 disabled=no list=BOGON
add address=127.0.0.0/8 disabled=no list=BOGON
add address=169.254.0.0/16 disabled=no list=BOGON
add address=172.16.0.0/12 disabled=no list=BOGON
add address=192.0.0.0/24 disabled=no list=BOGON
add address=192.0.2.0/24 disabled=no list=BOGON
add address=192.168.0.0/16 disabled=no list=BOGON
add address=198.18.0.0/15 disabled=no list=BOGON
add address=198.51.100.0/24 disabled=no list=BOGON
add address=203.0.113.0/24 disabled=no list=BOGON
add address=224.0.0.0/4 disabled=no list=BOGON
add address=240.0.0.0/4 disabled=no list=BOGON

Само запрещающее правило:

/ip firewall filter
add action=drop chain=input comment=Bogon_Wan_Drop in-interface=ether1-velton \
src-address-list=BOGON

11) Разрешаем все уже установленные подключения (connection state=established). Established — Существующее соединение. Пакет относится у уже установленному соединению, обрабатываемому в данный момент маршрутизатором.

add chain=input comment=Established_Wan_Accept connection-state=established

12) Разрешаем все зависимые подключения (connection state=related). Related – Связанное соединение. Пакет, который связан с существующим соединением, но не является его частью. Например, пакет, который начинает соединение передачи данных в FTP-сессии (он будет связан с управляющим соединением FTP), или пакет ICMP, содержащий ошибку, отправляемый в ответ на другое соединение.

add chain=input comment=Related_Wan_Accept connection-state=related

13) Блокируем все входящие соединения с WAN.

add action=drop chain=input comment=Drop_all_WAN in-interface=ether1-velton

——————-
Визуально последовательность правил выглядит так:

   Это минимальная настройка безопасности. Если вы хотите разрешить подключение VPN к роутеру, то как минимум нужно открыть порт. Например, для соединений по порту 1723 (PPTP):

/ip firewall filter
add chain=input dst-port=1723 protocol=tcp

Так же рекомендую использовать скрипт Оповещение администратора о входе в Mikrotik. Метод защиты сервисов, на которые проброшенные порты с Mikrotik описан в статье тут.

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

взято из инета.

  Наткнулся на сайт 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 дней.

Далее нужно добавить эти IP в drop правило Mikrotik. Создаем правило:

/ip firewall filter
add action=drop chain=input comment=»Drop new connections from blacklisted IP’s to this router» connection-state=new in-interface=ether1-niknet src-address-list=blacklist

Как видим все соединения с адрес-листа blacklist — блокируем. Joshaven Potter взял на себя сортировку IP в нужный нам формат, нам же остается только скачать готовый скрипт в формате .rsc с его сайта. Данные блэк-листов на сайте обновляются ежедневно. Файл-скрипт имеет вид:

OpenBL

Скрипт для вставки в терминал:

# Script which will download the OpenBL list as a text file & Script which will Remove old OpenBL records and add new one
/system script add name=»DownloadOpenBL_ReplaceOpenBL» source={
/tool fetch url=»http://joshaven.com/openbl.rsc» mode=http;
:log info «Downloaded openbl.rsc from Joshaven.com»;
:delay 40;
/ip firewall address-list remove [find where comment=»OpenBL»];
/import file-name=openbl.rsc;
:log info «Removed old OpenBL records and imported new list»;
}

Правило в Scheduler.

/system scheduler add comment=»Download openbl list_Apply openbl List» interval=3d name=»Download and Apply OpenBL_List» on-event=DownloadOpenBL_ReplaceOpenBL start-date=jan/01/1970 start-time=00:35:04

Фактически мы создаем скрипт, который закачает файл с сайта joshaven.com со списком IP, и добавит или заменит его в адрес-листе blacklist с комментарием каждой записи «OpenBL». И этот скрипт «обновления записей» поместим на выполнение каждые 3 дня.

Spamhaus

  Скрипт

# Script which will download the drop list as a text file & Script which will Remove old Spamhaus list and add new one
/system script add name=»DownloadSpamhaus_ReplaceSpamhaus» source={
/tool fetch url=»http://joshaven.com/spamhaus.rsc» mode=http;
:log info «Downloaded spamhaus.rsc from Joshaven.com»;
:delay 40;
/ip firewall address-list remove [find where comment=»SpamHaus»];
/import file-name=spamhaus.rsc;
:log info «Removed old Spamhaus records and imported new list»;
}

  Scheduler

# Schedule the download and application of the spamhaus list
/system scheduler add comment=»Download spamhaus list_Apply spamhaus List» interval=3d name=»DownloadSpamhausList and ApplySpamhausList» on-event=DownloadSpamhaus_ReplaceSpamhaus start-date=jan/01/1970 start-time=00:40:04

dshield.org

  Скрипт

# Script which will download the drop list as a text file & Script which will Remove old dshield list and add new one
/system script add name=»Download_dshield_Replace_dshield» source={
/tool fetch url=»http://joshaven.com/dshield.rsc» mode=http;
:log info «Downloaded dshield.rsc from Joshaven.com»;
:delay 40;
/ip firewall address-list remove [find where comment=»DShield»];
/import file-name=dshield.rsc;
:log info «Removed old dshield records and imported new list»;
}

  Scheduler

/system scheduler add comment=»DownloadDShieldList_InstallDShieldList» interval=3d name=»Download and Apply dshield_List» on-event=Download_dshield_Replace_dshield start-date=jan/01/1970 start-time=00:45:04

 malc0de.com

Скрипт

# Script which will download the malc0de list as a text file & Script which will Remove old malc0de list and add new one
/system script add name=»Download_malc0de_Replace_malc0de» source={
/tool fetch url=»http://joshaven.com/malc0de.rsc» mode=http;
:log info «Downloaded malc0de.rsc from Joshaven.com»;
:delay 40;
/ip firewall address-list remove [find where comment=»malc0de»];
/import file-name=malc0de.rsc;
:log info «Removed old malc0de records and imported new list»;
}

Scheduler

# Schedule the download and application of the malc0de list
/system scheduler add comment=»Download and Apply malc0de list» interval=3d name=»Downloadmalc0deList_Installmalc0deList» on-event=Download_malc0de_Replace_malc0de start-date=jan/01/1970 start-time=00:50:04

————————————-
Автор и владелец joshaven.com уверяет, что его сервер работает с высокой степенью доступности, имеет распределение нагрузки и резервирование каналов, поэтому списки с его серверов всегда доступны. Так же, если вы захотите формировать списки сами, он приводит скрипт, который вы можете поместить в cron у себя на сервере linux и выполнять по регламенту, а ваш микротик будет забирать эти списки локально:

Note: Please only use the following update scripts sparingly because the source sites don’t need a bunch of unnecessary traffic. Anyway, the following script will run on a Linux server (requires gawk & wget). I placed it in a file with 755 permissions in my /etc/cron.daily/ folder to be run daily.

#!/bin/sh
saveTo=/var/www
now=$(date);
echo «# Generated by Joshaven Potter on $now» > $saveTo/dshield.rsc
echo «/ip firewall address-list» >> $saveTo/dshield.rsc
wget -q -O — http://feeds.dshield.org/block.txt | awk —posix ‘/^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.0\t/ { print «add list=blacklist address=» $1 «/24 comment=DShield»;}’ >> $saveTo/dshield.rsc
echo «# Generated by Joshaven Potter on $now» > $saveTo/spamhaus.rsc
echo «/ip firewall address-list» >> $saveTo/spamhaus.rsc
wget -q -O — http://www.spamhaus.org/drop/drop.lasso | awk —posix ‘/[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\// { print «add list=blacklist address=» $1 » comment=SpamHaus»;}’ >> $saveTo/spamhaus.rsc
echo «# Generated by Joshaven Potter on $now» > $saveTo/openbl.rsc
echo «/ip firewall address-list» >> $saveTo/openbl.rsc
wget -q -O — http://www.openbl.org/lists/base_30days.txt.gz | gunzip | awk —posix ‘/^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}/ { print «add list=blacklist address=» $1 » comment=OpenBL»;}’ >> $saveTo/openbl.rsc
echo «# Generated by Joshaven Potter on $now» > $saveTo/malc0de.rsc
echo «/ip firewall address-list» >> $saveTo/malc0de.rsc
wget -q -O — http://malc0de.com/bl/IP_Blacklist.txt | awk —posix ‘/^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}/ { print «add list=blacklist address=» $1 » comment=malc0de»;}’ >> $saveTo/malc0de.rsc

  Напоследок хочу предостеречь, скачивая и выполняя .rsc файл с стороннего ресурса вы можете получить уязвимость в своей сети, поэтому принимайте взвешенные решения!

Настройка MikroTik в качестве OVPN-сервера с использованием клиентских сертификатов и списка отзыва.

Статья с хабра. Дополненная.
Передо мной возникла задача настроить MikroTik в качестве OVPN сервера с использованием клиентских сертификатов и возможностью их отзыва.

Использование PKI ROS
Касательно PKI есть два варианта:

1. С использованием встроенного в ROS PKI:

+ можем выдавать и отзывать сертификаты непосредственно на микротике, иначе нам придётся после каждого отзыва вручную обновлять crl на нём
— случайное удаление с микротика CA-сертификата, используемого для подписи и отзыва сертификатов — фатально, импорт ранее выгруженных сертификата и ключа CA не поможет, а дальнейшее использование будет возможно только с использованием openssl и ручной загрузкой crl после каждого отзыва (конечно, если у вас есть актуальный бэкап всего этого)
+ если мы бэкапим весь конфиг микротика, то вместе с ним бэкапится и CA

2. С использованием стороннего PKI — openssl, или windows server PKI (НЕ используйте доверенные CA типа StartSSL, они выдают клиентские сертификаты не только вам):

+ защищены от недостатка первого варианта
— в случае openssl необходимо вручную загружать crl на микротик после каждого отозванного сертификата
+ в случае windows server PKI теоретически можно реализовать проверку подлинности через механизм SCEP, но пока не проверял
— в случае windows server PKI нужен домен, без него этот самый PKI работать не будет

Я буду рассматривать только первый вариант, т.к., во-первых, он мне подходит, во-вторых, он более гибкий. Так же я не буду подробно останавливаться на параметрах сертификатов и прочих разных параметрах стандартных инструментов ROS, т.к. их исчерпывающее описание есть на официальной MikroTik Wiki.

Настраиваем OVPN-сервер на ROS
1. Настройка PKI
1.1. Сертификат CA:

/certificate add name=template-CA country=»» state=»» locality=»» organization=»» unit=»» common-name=»test-CA» key-size=4096 days-valid=3650 key-usage=crl-sign,key-cert-sign
/certificate sign template-CA ca-crl-host=127.0.0.1 name=»test-CA»

тут возможно подвисание микротика или надпись в консоль что типа таймаут.

Спокойно ждём. все подпишется.
Примечание: ca-crl-host= — обязательный параметр, иначе список отзыва не будет создан; полный путь к списку отзыва будет указан в параметрах сертификата, графа «[1]Точка распределения списка отзыва (CRL)»; в принципе, можно указать любой из ip-адресов нашего микротика, тот что укажем — и будет прописан в сертификате. Доменные имена параметром не поддерживаются, к сожалению.

1.2. Сертификат сервера:

/certificate add name=template-SRV country=»» state=»» locality=»» organization=»» unit=»» common-name=»test-srv-OVPN» key-size=4096 days-valid=1095 key-usage=digital-signature,key-encipherment,tls-server
/certificate sign template-SRV ca=»test-CA» name=»test-srv-OVPN»
Примечание: для сертификата сервера key-usage лучше не менять, почему так — описано здесь (а если очень хотим поменять — то там же написано что нужно прописать в конфиге клиента для этого).

Примечание: в отличие от SSTP — OVPN не проверяет соответствие common-name сертификата сервера fqdn’у этого сервера.

1.3. Шаблон для сертификатов клиентов:

/certificate add name=template-CL country=»» state=»» locality=»» organization=»» unit=»» common-name=»test-client-ovpn-template» key-size=4096 days-valid=365 key-usage=tls-client
1.3.1 Сертификат первого клиента:

/certificate add name=template-CL-to-issue copy-from=»template-CL» common-name=»test-client-ovpn-1″
/certificate sign template-CL-to-issue ca=»test-CA» name=»test-client-ovpn-1″
1.3.2. Сертификат второго и последующих клиентов:

См. п. 3.1, но меняем значение параметров.

common-name=»test-client-ovpn-1″
Для первой команды, это значение должно быть уникальным в пределах одного CA.

name=»test-client-ovpn-1″

Для второй команды, это значение должно быть уникальным в пределах одного микротика.

1.4 В будущем, для отзыва сертификатов используем команду:

certificate issued-revoke %cert-name%
Где %cert-name% — поле name= подписанного сертификата, то есть отображаемое PKI микротика.

2. Настройка OVPN сервера
Примечание: можно настроить в режиме tun («ip» в ROS), а можно в режиме tap («ethernet» в ROS). Режим tun — обычный туннель. Режим tap — эмуляция полноценного ethernet, в частности в режиме tap клиентов можно объединить в режим моста и они будут прекрасно друг друга видеть. В теории в режиме tap можно запустить DHCP-сервер, но в текущей версии ROS это не реализовано.

2tun. Режим tun
2tun.1. Задаём пул адресов для OVPN-клиентов (можно задать непосредственно в PPP-profile):

/ip pool add name=OVPN_srv_pool ranges=192.168.100.2-192.168.254
2tun.2. Создаём PPP-profile для OVPN-сервера:

/ppp profile add name=OVPN_server local-address=192.168.100.1 remote-address=OVPN_srv_pool
Опционально! Остальные параметры по вашему вкусу и в соответствии с вашими целями. Например: dns=192.168.100.1 use-ipv6=no

2tun.3. Настраиваем режим аутентификации пользователей:

/ppp aaa set accounting=yes
2tun.4. Добавляем пользователей:

/ppp secret add name=test-user-1 password=P@ssword1 service=ovpn profile=OVPN_server
/ppp secret add name=test-user-2 password=P@ssword2 service=ovpn profile=OVPN_server

2tun.5. Включаем OVPN-сервер:

/interface ovpn-server server set auth=sha1 cipher=blowfish128 default-profile=OVPN_server mode=ip netmask=24 require-client-certificate=yes certificate=test-srv-OVPN enabled=yes
2tap. Режим tap
2tap.1. Задаём пул адресов для OVPN-клиентов (можно задать непосредственно в PPP-profile):

/ip pool add name=OVPN_srv_pool ranges=192.168.100.2-192.168.254

2tap.1+. Создаём мост для OVPN-подключений:

/interface bridge add name=OVPN_bridge arp=enabled
Примечание: IP для моста назначать совершенно не обязательно, он и так имеется в PPP-profile (кроме того если указать адрес для моста, но не указать local-address= в PPP-profile, то клиент не подключится).

Примечание: arp должен быть включён, иначе клиенты друг-друга не увидят.

2tap.2. Создаём PPP-profile для OVPN-сервера:

/ppp profile add name=OVPN_server local-address=192.168.100.1 remote-address=OVPN_srv_pool bridge=OVPN_bridge
Опционально! Остальные параметры по вашему вкусу и в соответствии с вашими целями. Например: dns=192.168.100.1 use-ipv6=no

2tap.3. Настраиваем режим аутентификации пользователей:

/ppp aaa set accounting=yes
2tap.4. Добавляем пользователей:

/ppp secret add name=test-user-1 password=P@ssword1 service=ovpn profile=OVPN_server
/ppp secret add name=test-user-2 password=P@ssword2 service=ovpn profile=OVPN_server
2tap.5. Включаем OVPN-сервер:

/interface ovpn-server server set auth=sha1 cipher=blowfish128 default-profile=OVPN_server mode=ethernet netmask=24 require-client-certificate=yes certificate=test-srv-OVPN enabled=yes
Примечания для обоих режимов:

1. Наличие пользователя является обязательным, даже не смотря на авторизацию по сертификатам; можно создать одного пользователя на всех клиентов и прописать один и тот же логин/пароль в конфигах клиентов, но это лишает возможности отследить подключение и действия конкретного пользователя — неудобно, несколько небезопасно.

2. RADIUS-аутентификацию я не рассматриваю просто потому, что не тестировал. Могу лишь предположить, что работать она будет только для username/password, а сертификаты будут всё так же проверяться на микротике.

3. Следите за тем, что бы пул адресов соответствовал подсети, указываемой в настройках OVPN-сервера. ROS’овский OVPN-сервер не будет разбираться принадлежат ли одной сети local-address= сервера и назначаемый из пула адрес клиента, более того, если, к примеру, использовать маску 29, а в качестве пула прописать ranges=192.168.100.0/29, клиенту может быть в лёгкую назначен броадкастовый 192.168.100.7, как это было у меня. Точно такая же ситуация может возникнуть, если указанный пул больше, чем подразумевает маска — только проблема выявится не сразу, а чуть погодя.

Важный момент. Для того чтобы прописать маршруты(чтобы компы из подсети где сервер увидели компы в подсети клиента нужно настроить маршрутизацию) Для этого нужно чтобы клиент получал из vpn  пула один и тот же адрес. На сервере в профиле пользователя нужно задать параметр remote address из пула подсети vpn сервера(OVPN_srv_pool).

/ppp secret print

Пример: test-user-1 ovpn P@ssword1 OVPN_server 192.168.100.100

3. Экспорт сертификатов для настройки клиентов
3.1. Экспорт сертификата CA:

/certificate export-certificate test-CA export-passphrase=»»
Примечание: Нам нужен только сам сертификат, закрытый ключ НЕ нужен, поэтому параметр export-passphrase=»» должен быть пустым.

3.2. Экспорт сертификатов клиентов:

/certificate export-certificate test-client-ovpn-1 export-passphrase=private-key-password1
/certificate export-certificate test-client-ovpn-2 export-passphrase=private-key-password2
Примечание: export-passphrase= — обязательный параметр для экспорта закрытых ключей; используем для каждого клиента свой пароль; НЕ используем тот же самый пароль, который указывали в пунктах 2.4 для пользователей!

3.3. Извлекаем полученные файлы сертификатов и ключей из микротика любым удобным способом (как правило, я таскаю туда-сюда файлы прямо из винбокса).

Настройка Windows-клиента
1. Получаем OVPN-дистрибутив с openvpn.net.
2. Устанавливаем, все опции оставляем по-умолчанию, в том числе tap-интерфейс, который понадобится для любого режима настройки.
3. Идём в OpenVPN\config (по-умолчанию C:\Program Files\OpenVPN\config) и создаём там файл client.ovpn (или копируем из OpenVPN\sample-config).
4. Создаём конфигурацию клиента, или вносим правки с sample-config.

Содержимое client.ovpn с небольшими комментариями
# Режим, в котором работает OVPN сервис
client

# Внимание! Указываем только один параметр из двух
# Для режима tun указываем параметр
dev tun
У нас tun
# Для режима tap указываем параметр
dev tap

# Этот параметр указываем только в случае использования режима tap, а вместо MyTap подставляем имя tap интерфейса в windows (ipconfig /all, или сетевые подключения в панели управления)
dev-node MyTap

# Используемый протокол. ROS’овский OVPN-сервер работает только в режиме tcp
proto tcp

# Адрес сервера, к которому будем подключаться, и порт. Вместо ovpn.my.domain — dns-имя или же ip-адрес. Можно указать несколько серверов.
remote ovpn.my.domain 1194
;remote my-server-2 1194

# Этот параметр нужен только в случае использования более чем одного сервера; При указании этого параметра при подключении клиент случайном образом выбирает один из указанных серверов
;remote-random

# Тайм аут между попытками определить ip-адрес по указанному DNS-имени сервера, в секундах (или бесконечность — infinite)
resolv-retry infinite

# Если указан этот параметр, то клиент будет использовать динамический исходящий порт для подключения
nobind

# Разрешают клиенту сохранять настройки туннеля при переподключении, а так же не перечитывать файлы ключей
persist-key
persist-tun

# Настройки прокси
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Отключает сообщения о повторяющихся пакетах
;mute-replay-warnings

# Пути к файлам сертификатов
# ca — сертификат CA, которым выданы сертификат клиента И сертификат сервера
# cert — сертификат клиента
# key — закрытый ключ сертификата клиента
ca cert_export_test-CA.crt
cert cert_export_test-client-ovpn-1.crt
key cert_export_test-client-ovpn-1.key

auth-user-pass сообщает клиенту, что он должен использовать имя пользователя и пароль для аутентификации (но не вместо сертификатов, а вместе с сертификатами)
# user-pwd.txt указывает на файл, в котором хранятся логин и пароль; первая строка в файле — логин, вторая — пароль; при отсутствии этого аргумента логин и пароль будут запрашиваться каждый раз при подключении(всё это из пункта 2tun.4. Добавляем пользователей)
Пример:
auth-user-pass user-pwd.txt
# Примечание: В случае использования сертификата с закрытым ключом, к которому и так нужно вводить ключ при каждом подключении, я не считаю необходимым заставлять пользователя помнить ещё и логин с паролем
auth-user-pass user-pwd.txt

# Сообщает клиенту, что он должен проверять сертификат сервера на предмет правильности используемых key-usage
remote-cert-tls server

# Ключ для шифрования начала процесса аутентификации (handshake), дополнительная мера безопасности. Имеет смысл при использовании только логина/пароля, без сертификатов.
;tls-auth ta.key 1

# Задание особого метода шифрования, по-умолчание используется blowfish128.
;cipher x

# Использование lzo-сжатия. Не поддерживается OVPN на ROS.
;comp-lzo

# Уровень лога. Чем больше значение — тем подробнее.
verb 3

# Блокирование повторяющихся сообщений в логе
;mute 20

# Выше были приведены параметры, которые присутствуют в «родном» примере конфига для клиента + 1 необходимый нам параметр
# Ниже я приведу ещё несколько, на мой взгляд, полезных параметров.

# Маршрут, устанавливаемый при запуске подключения
# Маршрут указывает не на шлюз, а непосредственно на подключение
route 192.168.88.0 255.255.255.0

# Пауза перед установкой маршрутов после установления подключения (в секундах)
route-delay 5

# Если мы хотим задать OVPN-подключение в качестве основного шлюза
route-gateway 192.168.100.1
redirect-gateway def1 //Спасибо пользователю @bibliary за правку. Согласно докам этот вариант верен, но протестировать на момент редактирования не имею возможности.

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

Примечание: список большинства параметров здесь но он несколько устаревший.

Настройка MikroTik-клиента
1 Импорт сертификатов
1.1 Кладём в микротик файл сертификата CA и файл сертификата и файл ключа клиента любым удобным способом

1.2 Импортируем сертификат CA

/certificate import file-name=cert_export_test-CA.crt passphrase=»»
1.3 Импортируем сертификат и ключ клиента

/certificate import file-name=cert_export_test-client-ovpn-1.crt passphrase=»»
/certificate import file-name=cert_export_test-client-ovpn-1.key passphrase=private-key-password1
2. Настраиваем клиент

/interface ovpn-client add name=OVPN_client connect-to={ovpn.my.domain|xxx.xxx.xxx.xxx} port=1194 mode={ip|ethernet} user=test-user-1 password=P@ssword1 profile=default certificate=<cert_export_test-client-ovpn-1> auth=sha1 cipher=blowfish128 add-default-route={no|yes} disabled=no
Значения в {} указываете в соответствии с предыдущими настройками и вашими потребностями.