+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Пинг Кнок

Пинг Кнок, RouterOS

coylh

Guest

25.04.2018 16:05:00

С появлением уязвимостей в протоколах управления появился интерес к технологии port knocking. Я поэкспериментировал с альтернативой, используя размеры ICMP-пакетов в качестве ключа. Называю это Ping Knocking.

# Выбираем случайные размеры ping-пакетов не менее 100 в качестве последовательности стуков.
# В firewall прибавляем 28 к размеру, чтобы компенсировать накладные расходы протокола.
# После совпадения последовательности стуков сервисы будут доступны в течение часа с вашего src IP.

/ip firewall filter
# Поместите это правило в начало списка.
add action=jump chain=input comment="Check port knock" icmp-options=8:0-255 jump-target=knock packet-size=!0-99 protocol=icmp

add action=accept chain=input comment="ACCEPT TLS after knock" dst-port=443 protocol=tcp src-address-list=KNOCK-SUCCESS
add action=accept chain=input comment="ACCEPT SSH after knock" dst-port=22 protocol=tcp src-address-list=KNOCK-SUCCESS

add action=return chain=knock comment="KNOCK FAILURE return" src-address-list=KNOCK-FAILURE

add action=add-src-to-address-list address-list=KNOCK-SUCCESS address-list-timeout=1h chain=knock comment="KNOCK 3rd - success 600" packet-size=628 src-address-list=KNOCK2
add action=return chain=knock comment="KNOCK 3rd - success return" src-address-list=KNOCK-SUCCESS

add action=add-src-to-address-list address-list=KNOCK-FAILURE address-list-timeout=1m chain=knock comment="KNOCK 3rd - failure" src-address-list=KNOCK2
add action=return chain=knock comment="KNOCK 3rd - failure return" src-address-list=KNOCK-FAILURE

add action=add-src-to-address-list address-list=KNOCK2 address-list-timeout=1m chain=knock comment="KNOCK 2nd - success 500" packet-size=528 src-address-list=KNOCK1
add action=return chain=knock comment="KNOCK 2nd - success return" src-address-list=KNOCK2

add action=add-src-to-address-list address-list=KNOCK-FAILURE address-list-timeout=1m chain=knock comment="KNOCK 2nd - failure" src-address-list=KNOCK1
add action=return chain=knock comment="KNOCK 2nd - failure return" src-address-list=KNOCK-FAILURE

add action=add-src-to-address-list address-list=KNOCK1 address-list-timeout=1m chain=knock comment="KNOCK 1st - success 400" packet-size=428
add action=return chain=knock comment="KNOCK 1st - success return" src-address-list=KNOCK1

add action=add-src-to-address-list address-list=KNOCK-FAILURE address-list-timeout=1m chain=knock comment="KNOCK 1st - failure"

Преимущество этой стратегии в том, что не нужно использовать специальное ПО для стука. Можно воспользоваться стандартной утилитой ping из командной строки или простым batch-файлом на Windows:

@echo off
set destination=%1

rem Команда для запуска: knock.bat hostname
ping -f -n 1 -l 400 %destination% >nul
ping -f -n 1 -l 500 %destination% >nul
ping -f -n 1 -l 600 %destination% >nul
echo Указанный адрес: %destination%

sindy

Guest

11.05.2018 19:27:00

Разные варианты — в этом и суть. Когда я в одной из своих домашних сетей, мне не нужны сложные настройки типа road warrior; а когда я в роуминге, я рад хоть какой-то связи — мобильная сеть, Wi-Fi в отеле и так далее, которые в разных уголках мира могут быть далеки от идеала.

coylh

Guest

11.05.2018 19:18:00

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

AlainCasault

Guest

01.06.2019 17:07:00

Всем привет, я знаю, что повторяю старую тему, но эта проблема меня озадачила. Я уже очень долго делаю одно и то же для демонстрации. Сегодня утром повторяю это снова — и ничего не работает. Немного покопавшись, я понял, что причина в ICMP-TIMEOUT в conntracking. Если я уменьшаю это время до 2 секунд и добавляю в свой батч-файл «ping 127.0.0.1 -n 5», то всё работает как надо. Два вопроса: 1. Что-то изменилось в последних версиях, и я это пропустил? 2. Есть ли последствия от сокращения ICMP-TIMEOUT? С уважением,

BRMateus2 Guest	#5 0 01.06.2019 17:29:00 Разве это не из-за того, что ты используешь connection-state=new?

AlainCasault

Guest

01.06.2019 18:21:00

Спасибо, что так быстро ответили. Я не использую это поле. Когда я смотрю таблицу conntrack, вижу там своё ICMP-соединение в течение 10 секунд, хотя мой ping отправил всего один пакет. Именно поэтому остальные pings не видны другим фильтрам — маршрутизатор считает, что это всё ещё одно и то же соединение. Я думал, что как только ping перестанет работать, соединение тоже завершится, но это не так. Спасибо!

sindy

Guest

01.06.2019 19:35:00

@AlainCasault, судя по тому, что ты написал, я тоже заподозрил, что что-то ещё должно было измениться. Таймаут (по умолчанию 10 секунд) нужен, чтобы можно было распознать запросы ping и ответы с одинаковым значением в поле идентификатора как принадлежащие одному и тому же соединению. Утилита ping в большинстве операционных систем по умолчанию посылает по одному запросу в секунду. Значит, при таймауте в 2 секунды в трекере соединений один потерянный запрос из цепочки может привести к тому, что соединение исчезнет из отслеживания, но это вызовет проблемы только в очень специфических случаях (не связанных с “постукиванием”).

Поскольку отдельный экземпляр утилиты ping запускается в пакете для каждого размера пакета, каждый должен посылать запрос с разным значением идентификатора. Так что, хотя запросы идут с одного и того же IP на тот же адрес, каждый должен создавать своё собственное отслеживаемое соединение — именно на этом строится автомат состояний @coylh. Хотя правила файервола, которые сопоставляют пакеты ping по размеру, явно не проверяют connection-state=new, они делают это косвенно, потому что идут после цепочки input с action=accept для connection-state=established, так что любой ICMP echo request, подходящий под уже установленное соединение, принимается этим правилом и не доходит до тех, что проверяют размер пакета.

Именно это, судя по всему, происходит в вашем случае и может зависеть от сокращения таймаута ICMP в настройках отслеживания соединений. Два варианта: либо ОС клиента начала посылать одинаковый ID во всех запросах, либо в Mikrotik connection tracking перестал проверять значение идентификатора.

Я провёл тест на версии 6.44.3, и выяснилось, что хотя трекинг соединений действительно проверяет значение идентификатора, “клиент” ping в RouterOS меняет (увеличивает) идентификатор только если не отправлял исходящий echo запрос около 15 секунд, и при пинге любого адреса переиспользует один и тот же идентификатор. Ещё в запросах номера последовательности не начинаются с единицы, но это, возможно, не ошибка — я не изучал RFC детально.

Повторное использование значения идентификатора — однозначно баг, который стоит заявлять. Так что согласно правилу “пострадал — заяви”, теперь ваша очередь проверить мои наблюдения и открыть тикет на support@mikrotik.com.

AlainCasault Guest	#8 0 02.06.2019 20:11:00 @sindy, спасибо за отзыв. Я проведу несколько тестов и отчитаюсь о результатах в тикете по проблеме. С наилучшими пожеланиями, AC

Jotne Guest	#9 0 23.07.2019 08:07:00 Интересная идея, но для порт-нокинга не нужна специальная программа. Чтобы сделать порт-нокинг на мой роутер, я просто по очереди открываю три веб-сайта. Номер порта — это просто пример. http://my-router-ip:44444 http://my-router-ip:33333 http://my-router-ip:22222 Это отлично работает и на моём телефоне. Использовать на телефоне команду ping -f -n 1 -l 400 %destination% >nul гораздо сложнее.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры