а я бы просто взад майкротика поставил opnsense (неважно, на железе или на виртуалке) и на нем все вопросы закрыл чего зверушку мучить-то несвойственной ей работой

On Wed, 13 Feb 2019 at 09:50, Volodymyr Litovka wrote:

Я ж сразу сказал - защита на пакетном уровне.

Так и это тоже да.

Потому что application / stateful inspection для хотя бы гигабитной производительности (жалкий микрот за $60) потребует сервера в 20-40 раз дороже,

Ой да вы шо правда шоле? Я б если сам не делал, то може и поверил бы. Подсказка. Атом возьми б/у, в мелком плоском корпусе. Зато сразу совершенно другой уровень полезности. Серьезно.

к тому же с местом для него в ряде ситуаций могут быть проблемы.

Ну мне трудно представить ситуацию, когда микротик поместился а рядом с ним атом в плоской коробочке вдруг нет.

On Thu, 14 Feb 2019 at 12:14, Volodymyr Litovka wrote:

Ну вот у меня вызывает вопросы именно ситуация: зачем ставить внешнюю пасочку на задачи, с которыми естественным образом справляется Микрот,

Ну вот вопрос - если приходится танцы с бубном и советоваться, то это "справляется" или нет? Может по процессору-то он и справляется, а вот по usability и maintainability так кажись шо не очень.

и какова производительность Атома на задачах фильтрации, которые Микрот делать не умеет?

Атом х64 с 4 гигами рамы 1Gbps - без проблем. Оговорки: 1) я напрочь не помню какие там стояли Ethernet-чипы, видимо что-то приличное оба 2) не встречал случая, когда требовалось бы задействовать более 1/3-1/2 функциональных возможностей opnsense единовременно Он очень много всего умеет, все сразу как правило просто некуда (и незачем) применить. И очень полированная штука. Highly recommended. REST APIs и вебсервера им в частности прикрывать хорошо, TLS Offloading умеет, HA умеет, много чего умеет. Но и просто юзеровскую сетку прикрыть нормально - тоже Ок. https://docs.opnsense.org/manual.html Можно (и наверное и хорошо) первичную дубовую и незатейливую фильтрацию сделать на микроте в простейшем ее варианте, а интеллектуальное все уже делать на opnsense включенном микроту в зад. К слову у меня ощущение, что ASA до opnsense несколько того... не дотягивает, а с учетом цены так и подавно. Естественно, this is my humble, biased, personal and highly subjective opinion. С наилучшими, я

Карточки - строго Intel, при чём те, которые имеют несколько очередей. Потому как в один поток оно точно не прожуётся. Такой конфиг не прожуёт всё, что связано с conntrack (NAT, stateful firewall). Ну и огромные таблицы iptables тоже. Можно выкрутиться с помощью ipset, если критично. 14.02.19 17:24, Stesin пише:

On Thu, 14 Feb 2019 at 12:14, Volodymyr Litovka wrote:

...

Ну вот у меня вызывает вопросы именно ситуация: зачем ставить внешнюю пасочку на задачи, с которыми естественным образом справляется Микрот,

Ну вот вопрос - если приходится танцы с бубном и советоваться, то это "справляется" или нет? Может по процессору-то он и справляется, а вот по usability и maintainability так кажись шо не очень.

...

и какова производительность Атома на задачах фильтрации, которые Микрот делать не умеет?

Атом х64 с 4 гигами рамы 1Gbps - без проблем. Оговорки:

1) я напрочь не помню какие там стояли Ethernet-чипы, видимо что-то приличное оба 2) не встречал случая, когда требовалось бы задействовать более 1/3-1/2 функциональных возможностей opnsense единовременно

Он очень много всего умеет, все сразу как правило просто некуда (и незачем) применить. И очень полированная штука. Highly recommended. REST APIs и вебсервера им в частности прикрывать хорошо, TLS Offloading умеет, HA умеет, много чего умеет. Но и просто юзеровскую сетку прикрыть нормально - тоже Ок. https://docs.opnsense.org/manual.html

Можно (и наверное и хорошо) первичную дубовую и незатейливую фильтрацию сделать на микроте в простейшем ее варианте, а интеллектуальное все уже делать на opnsense включенном микроту в зад. К слову у меня ощущение, что ASA до opnsense несколько того... не дотягивает, а с учетом цены так и подавно.

Естественно, this is my humble, biased, personal and highly subjective opinion. С наилучшими, я _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

В конечном итоге, имеет смысл творчески осмыслить дефолтные правила, а также https://wiki.mikrotik.com/wiki/Drop_port_scanners https://wiki.mikrotik.com/wiki/DDoS_Detection_and_Blocking и можно делать отстрел неудачных попыток установления соединения (для постоянных соединений) типа такого (ну и обязательно менять стандартные порты на любые другие) add comment="5 rules to drop ssh brute forcers" chain=input action=drop protocol=tcp src-address-list=ssh_blacklist dst-port=22 log=no log-prefix="" add chain=input action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=ssh_stage3 address-list=ssh_blacklist address-list-timeout=1w3d dst-port=22 log=no log-prefix="" add chain=input action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=ssh_stage2 address-list=ssh_stage3 address-list-timeout=1m dst-port=22 log=no log-prefix="" add chain=input action=add-src-to-address-list connection-state=new protocol=tcp src-address-list=ssh_stage1 address-list=ssh_stage2 address-list-timeout=1m dst-port=22 log=no log-prefix="" add chain=input action=add-src-to-address-list connection-state=new protocol=tcp address-list=ssh_stage1 address-list-timeout=1m dst-port=22 log=no log-prefix="" add comment="Accept SSH" chain=input action=accept protocol=tcp dst-port=22 log=no log-prefix="" On 12/17/18 5:30 PM, Victor Cheburkin wrote:

Hi!

Вот так чтобы best practice чтобы оно охватывало, по сути, трафик кучи openvpn (который на mikrotik кастрирован), боюсь что и не будет. Самый best practice, по-моему (хотя я не очень специалист) - дефолтовый конфиг + набор разрешающих правил и адрес-листов к ним, остальное отсечется правилами 7 и 11. Думаю, конкретно в твоем случае, возможно, нужен адрес лист для 5 правила. Еще, возможно, стоит посмотреть в настройках IP на тему RP Filter, accept redirect, tcp syn cookies. И учти, что некоторые фишки с fasttrack несовместимы, к примеру -- ограничение траффика. Думаю, ты и сам все это уже сделал, но раз очень просишь, то вот ;-)

...

17 дек. 2018 г., в 15:26, Volodymyr Litovka mailto:doka.ua@gmail.com> написал(а):

Привіт,

Що, немає best practices?

On Sat, Dec 15, 2018, 01:00 Volodymyr Litovka mailto:doka.ua@gmail.com wrote:

Привет,

подскажите, пожалуйста, свои best practices для защиты локальной сети на _пакетном уровне_. Есть микрот, подключенный к инету, который строит несколько VPN-линков к удаленным площадкам. Локальная сеть ходит в интернет через WAN (ether1) и на удаленные площадки - через VPN-линки. NAT настроен на out-interface:ether1, трафик по VPN-линкам не натится.

На микроте есть вот такие правила фильтров (бОльшая их часть - default rules, я добавил только правила 4,5,6) и у меня вопрос - достаточно-ли этого, чтобы быть более-менее спокойным относительно пакетной безопасности локальной сети? То есть, фактически: input безусловно разрешает только ICMP и SSH, ограничивает winbox внутренними портами, остальное - рубится. Форвард на WAN-интерфейсе - только для соединений, инициированных изнутри. Форвард с VPN-линков не регулируется. Посоветуйте, нужно-ли и, если да, то как эти правила можно допараноить :) Мне оно выглядит вроде достаточным, но я херовый безопасник :)

Спасибо.

  0  D ;;; special dummy rule to show fasttrack counters        chain=forward action=passthrough

  1    ;;; defconf: accept established,related,untracked        chain=input action=accept connection-state=established,related,untracked

  2    ;;; defconf: drop invalid        chain=input action=drop connection-state=invalid

  3    ;;; defconf: accept ICMP        chain=input action=accept protocol=icmp

  4    ;;; Allow SSH from everywhere        chain=input action=accept protocol=tcp dst-port=[...] log=no log-prefix=""

  5    ;;; Allow OSPF on VPN links only        chain=input action=accept protocol=ospf in-interface-list=VPN log=no log-prefix=""

  6    ;;; Allow Winbox on LAN/VPN only        chain=input action=accept protocol=tcp in-interface-list=LAN dst-port=[...] log=no log-prefix=""

  7    ;;; defconf: drop all        chain=input action=drop log=no log-prefix=""

  8    ;;; defconf: fasttrack        chain=forward action=fasttrack-connection connection-state=established,related

  9    ;;; defconf: accept established,related, untracked        chain=forward action=accept connection-state=established,related,untracked

10    ;;; defconf: drop invalid        chain=forward action=drop connection-state=invalid

11    ;;; defconf:  drop all from WAN not DSTNATed        chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN

-- Volodymyr Litovka    "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua mailto:uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Victor Cheburkin VC319-RIPE, VC1-UANIC

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison