Pull to refresh
6
0
Yevgeniy Valeyev @MaZaY_Dead

User

Send message
Что значит «всё»?
8.8.8.8 прекрасно работает.
К сожалению, товарисч не понимает разницы. :)
Да тут важно даже не то что это выгоднее, а то что надёжнее. Казахстанские хостеры (да и не только они) — это что-то с чем-то…
Причем тут DynDNS?

Действительно, не причём. Прошу прощения за оффтоп.

Почему KazNIC продляет годовую подписку по 3400 тг.?

Наверное потому что для Вас это приемлемая цена. :) А если серьёзно — вопрос не по адресу.
Однако домены не всегда покупаются под коммерческие проекты и тут цена*2 может сыграть большую роль.
Поэтому все, кто может, уедут в европейские зоны или куда-нибудь ещё, тем более с ограничениями по поводу хостинга:
Обязан законодательно, т.к. клиентам нужен домен KZ или КАЗ, в то время как закон не разрешает хостить ресурсы с таким доменным именем вне страны.


А хостинг у нас наверное самый дорогой и по качеству самый «лучший».
О каком развития КазНета эти люди вообще говорят, я не понимаю.
1700 тг. — это не дёшево, а нормально.
Именно столько я плачу за домен .org.
Чем .kz лучше? :)
На текущий момент у меня мало правил, всего парочка дропов, а штук 10 правил в цепочке dstnat.

То есть Вы открыты всему свету за исключением «избранных», чьи коннекты дропаются?

По хорошему у Вас должно быть как-то так:
# Дропаем невалидные форварды
chain=forward action=drop connection-state=invalid
# Аналогичные 10 правил, только в цепочке forward, например SSH
chain=forward action=accept protocol=tcp in-interface=Internet dst-port=22

# Разрешаем форвардинг и локальной сети в Интернет
chain=forward action=accept in-interface=bridge-local out-interface=Internet
# Дропаем все остальные форварды
chain=forward action=drop
# Закрываем наш микротик от внешнего мира
chain=input action=drop connection-state=invalid in-interface=Internet
# Разрешаем ICMP, если надо
chain=input action=accept protocol=icmp in-interface=Internet
chain=input action=accept connection-state=established in-interface=Internet
chain=input action=accept connection-state=related in-interface=Internet
# Остальное дропаем
chain=input action=drop in-interface=Internet

Пока-что нагрузка в среднем 1-5% на проц. Я не представляю как я буду разруливать не то что 100 тысяч, я не представляю как я буду разруливать 100-200 правил (я все-таки программист, а не админ).

Так Вы и подойдите к этому делу как программист :D
Напишите пару правил-функций и пуска в них попадают коннекты по определённому признаку, например из определённого списка.
Данное решение не работает, если атакующий будет совершать 1 попытку в минуту, он не поднимется выше списка ssh_stage1.
Удалось пощупать данную железку, в целом впечатления приятные, расстроило только одно обстоятельство — отсутствует поддержка VLAN, а иногда очень надо подать именно тэгированный трафик.
Имеется схожий по характеристикам микротик — RB2011UaS-2HnD. Настроено 35 различных фильтров, 15 правил для пометки соединений/пакетов (mangle) в зависимости от адреса/порта назначения, с большими (очень большими) списками адресов, для последующей приоритезации трафика (simple queue). Так же добавлено 18 правил в цепочку NAT.

В пиках роутер пропускает порядка 80Mbit, при этом загрузка ЦПУ поднимается до 80-90%, в штатном режиме — 20-30Mbit ЦПУ загружен на 30%. ОЗУ используется на 30% при любом количестве трафика.

Хотелось бы уточнить, допустим Вы добавили 100 тысяч фильтров и всё работает нормально. Как Вы потом будете это администрировать?
Обычно создаются какие-то общие правила, при необходимости добавляются списки адресов для разрешения/запрещения трафика.
Лучше всё же сюда :)
Это конечно все хорошо, но меня, как пользователя микротика, интересует один вопрос: какое количество filter-rules микротик может обработать без напряга? После какого числа он начнет напрягаться? 10 тысяч, 100 тысяч, 10 миллионов записей?

Это зависит от конфигурации Вашего роутера, объёма ОЗУ, ЦПУ, количества пропускаемого трафика, типов используемых фильтров, погоды за бортом, влажности, и т.д. и т.п.

Ну и второй вопрос… Можно ли как-нибудь заставить микротик (желательно именно его) добавлять в блэклист (допустимо добавление даже на час), в случае если с определенного IP прилетает очень много коннектов (брутфорсят SSH) за короткий промежуток времени?

Теоретически следующие правила должны это сделать, практически — надо тестировать.
Первое правило добавляет IP адреса в список BLACKLIST есть количество коннектов равно, либо превышает 100, второе правило блокирует коннекты для IP адресов находящихся в списке BLACKLIST. Повторюсь схема теоретическая, нужно тестирование.
add action=add-src-to-address-list address-list=BLACKLIST chain=forward connection-limit=100,32 dst-port=22 in-interface=Internet protocol=tcp address-list-timeout=1h comment="Limit SSH connections" tcp-flags=syn
add action=drop chain=forward comment="Drop SSH connections for blacklisted hosts" dst-port=22 in-interface=Internet protocol=tcp src-address-list=BLACKLIST
Мы пошли другим путём, собрали модуль chan_sccp и завели данное чудо техники по протоколу Skinny (SCCP).
Даже не знаю кому было больнее решать эту задачу, Вам или мне :)

Information

Rating
Does not participate
Location
Караганда, Карагандинская обл., Казахстан
Date of birth
Registered
Activity