Записки IT специалиста
Межсетевой экран, он же брандмауэр или файрвол — важнейшая служба вашего роутера, отвечающая как за его безопасность, так и за безопасность всей сети. Мы до сих пор не рассматривали базовую настройку брандмауэра в отрыве от общей настройки роутера, но как показала практика, многие администраторы откровенно плавают в этом вопросе и имеют некорректно или не оптимально настроенные системы. Как минимум это выливается в повышенную нагрузку на оборудование, а в самом плохом варианте ставит под угрозу безопасность всей сети. Поэтому давайте отдельно разберемся в этом вопросе.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Общие принципы построения брандмауэра
Существует два основных типа настройки брандмауэра: нормально открытый брандмауэр и нормально закрытый. В первом случае разрешено все, что явно не запрещено, во втором случае — запрещено все, что явно не разрешено.
Возможно, для кого-то будет новостью, но оба этих подхода обычно гармонично сочетаются в рамках одного устройства. Нормально открытый брандмауэр применяется для внутренних сетей и исходящих соединений, а нормально закрытый — для все остальных соединений из внешних сетей. Это позволяет достичь простоты и удобства для собственных пользователей и в тоже время надежно защититься от внешнего мира.
Любое новое соединение первоначально находится в статусе нового (new) и мы должны принять решение: одобрить его или запретить. Для этой задачи и предназначены создаваемые нами правила, в нормально закрытом брандмауэре мы описываем, какие соединения и по каким критериям следует разрешить. Если же пакет не соответствует ни одному правилу, то мы запрещаем такое соединение.
После того, как соединение было установлено — оно переходит в состояние установлено (established), при этом специальный механизм ядра Connection Tracker отслеживает все проходящие пакеты и сопоставляет их соединениям, поэтому мы можем спокойно оперировать именно состоянием соединения, не задумываясь над техническими тонкостями работы.
Нужно ли каждый раз отслеживать пакеты уже установленного соединения вновь и вновь гоняя их по цепочке правил? Конечно же нет, если мы одобрили соединение, то в последующем можем и должны одобрять все его пакеты автоматически, это снижает нагрузку на устройство и позволяет использовать различные приемы, вроде Port Knocking или противодействия перебору паролей.
Очень часто одни соединения, будучи установленными, создают другие, которые называются связанными (related), как пример можно привести хорошо известные FTP или PPTP, которые имеют управляющее соединение и соединение(я) для передачи данных. Они могут использовать динамические порты и поэтому их также следует автоматически разрешать, если мы разрешили основное соединение.
Поэтому в любом корректно настроенном брандмауэре самым первым правилом должно находиться разрешающее установленные и связанные соединения, а только после него мы уже должны анализировать новые подключения.
В роутерах Mikrotik существует еще один тип соединения — неотслеживаемое (untracked), такие соединения не отслеживаются Connection Tracker, что позволяет существенно снизить нагрузку на устройство. Для чего это может быть нужно? Допустим, в фильтруемом вами трафике есть значительная доля принадлежащая доверенным узлам, для которых можно четко прописать критерии, в этом случае можно пометить их неотслеживаемыми и добавить их одобрение в самое первое правило, к уже установленным и связанным.
Таким образом, одним единственным правилом мы будем сразу пропускать подавляющую долю трафика, а к затратным операциям анализа будут доходить только новые пакеты.
Но тут самое время вспомнить еще про одно состояние соединения — недействительное (invalid), это пакеты не являющиеся новыми, но не принадлежащие никакому установленному соединению, такие пакеты могут использоваться для атак и поэтому их следует блокировать в первую очередь, сразу после того, как мы одобрили установленные и связанные соединения и до того, как приступили к анализу новых пакетов.
Ну и завершающим правилом в цепочке должно стоять запрещающее, отсекающее все соединения, которые не попали под разрешающие правила и не являются уже установленными или связанными с ними.
Конфигурация брандмауэра по умолчанию
Прежде всего рассмотрим конфигурацию, предлагаемую производителем по умолчанию. Многие считают ее наиболее оптимальной и безопасной, но это не так, конфигурация по умолчанию направлена на универсальность и совместимость с различными пользовательскими сценариями, не позволяя ему наделать грубых ошибок, которые могут фатально сказаться на безопасности.
Все правила сгруппированы в две цепочки: input — для входящего трафика самого роутера и forward — для транзитного, между интерфейсами роутера. Сразу напомним, что у роутеров Mikrtoik нет жестко заданных «внешних» и «внутренних» интерфейсов, и вообще все эти понятия находятся исключительно у нас в голове, согласно логическому плану сети.
В конфигурации по умолчанию также присутствует два списка интерфейсов: WAN — куда включен порт, настроенный как внешний, обычно ether1 и LAN, в состав которого входит мост, объединяющий оставшиеся порты. и эти списки активно применяются в правилах.
Самих правил немного, всего 11 штук: 5 для input и 6 для forward.
Рассмотрим их подробнее. Правило с нулевым номером в расчет не берем, это пустышка для вывода счетчиков Fasttrack. Начнем с первых двух, это классическая связка, о которой мы говорили выше: разрешаем established, related и untracked для всех входящих соединений, без привязки к интерфейсам. Затем запрещаем invalid, вполне очевидно, что далее пройдут только пакеты соединений в состоянии new.
Третье правило разрешает входящий ICMP, у многих администраторов с ним напряженные отношения, часто его блокируют полностью, чтобы устройство не пинговалось, но так делать не нужно, протокол ICMP важен для нормальной работы сети. Либо фильтровать нужные его типы выборочно, что выходит за рамки данной статьи.
Следующее правило весьма специфично, оно разрешает входящие на петлевой интерфейс, точнее адрес 127.0.0.1, поскольку интерфейс петли явно в RouterOS не доступен, а также снабжено комментарием, что это для CAPsMAN. Его смысл станет понятен чуть ниже.
И завершает цепочку input блокирующее правило:
Которое блокирует входящие подключения для всех, кроме интерфейса LAN, а так как локальная петля туда не входит, то выше потребовалось отдельное правило.
Как видим конфигурация слегка избыточна, но при этом универсальна. А блокировка входящих по такой широкой маске — все, кроме локальной сети — позволяет сохранить должный уровень безопасности, даже если пользователь подключит другие внешние сети, скажем VPN.
А где же здесь размещать свои собственные правила? А вот здесь:
Теперь о цепочке forward, самыми первыми здесь теперь добавлены два правила, разрешающие транзит соединений, подпадающих под действие политик IPsec. Это связано с тем, что IPsec сегодня применяется все чаще, но правильно настроить правила для него умеют не все пользователи. Поэтому появились эти правила, обеспечивающие гарантированное прохождение любых соединений, использующих IPsec через роутер в любом направлении.
Затем идет правило, включающее Fasttrack для всех установленных и связанных соединений. Подробнее про Fasttrack мы писали в нашей статье:
Если коротко, то Fasttrack значительно снижает нагрузку на оборудование, но фактически пускает трафик в обход брандмауэра. Но так как фильтровать established и related нам не надо, то почему бы и не пустить их коротким путем?
Далее та же самая классика: разрешаем established, related и untracked, запрещаем invalid. Для всех направлений без разбора.
Ну и, наконец, запрещающее правило, оно тоже интересно:
Оно запрещает транзит только новым соединениям, только с внешнего списка интерфейсов, кроме соединений прошедших через DNAT. А так как DNAT обычно используется для проброса портов, то таким образом мы избегаем необходимости создавать для них разрешающие правила.
Да, опять очень и очень общие критерии, но в состоянии абсолютной неопределенности возможных конфигураций это, пожалуй, лучшее решение. Особенно если роутер будет использоваться вместе с UPnP, где сетевые приложения могут самостоятельно пробрасывать произвольные порты.
Поэтому мы еще раз повторимся, что конфигурация по умолчанию не является самой оптимальной или самой безопасной, но она наиболее универсальна, одновременно закрывая самые разные сценарии использования роутера.
Куда добавлять собственные правила? Да вот сюда:
Стоит ли оставлять и использовать конфигурацию по умолчанию? Да, если вы еще не уверены в собственных силах, плохо понимаете работу межсетевого экрана или вам нужно просто быстро настроить роутер для типовых задач.
Собственная конфигурация брандмауэра
В среде опытных пользователей Mikrotik принято сбрасывать устройство и настраивать конфигурацию с нуля. Для этих целей мы используем следующую конфигурацию брандмауэра, она во многом повторяет стандартную, но имеет ряд отличий. В плане именования интерфейсов мы также будем использовать листы WAN и LAN, с таким же набором интерфейсов.
При построении данного набора правил мы исходили из соображений, что администратор представляет как устроена его сеть, каким службам нужен доступ извне, какие сети являются внешними, а какие внутренними. При этом всеми силами старались избегать широких критериев в правилах, так как «проходной двор», даже вроде-бы в довольно безопасных вещах, таких как IPsec или DNAT может иногда сыграть злую шутку. Все мы помним, что если на стене висит ружье, то оно обязательно выстрелит.
Правил в нашем варианте меньше, всего 9, из них 4 для input и 5 для forward.
Набор правил для input приведем сразу и целиком, здесь тот же самый классический набор, но за одним исключением: мы знаем, какие сети являются внешними и фильтруем только подключения из них. Это упрощает конфигурацию и снижает нагрузку. При этом в каждом правиле мы четко указываем список входящих интерфейсов.
Мы точно также разрешаем установленные и связанные, запрещаем invalid, разрешаем ICMP. Можно заметить, что у нас нет untracked, это сознательное решение, если мы будем использовать неотслеживаемые соединения — то всегда можем добавить этот параметр, но сделаем это осознанно. Собственные правила мы можем добавлять выше запрещающего весь остальной трафик с внешних интерфейсов.
Также следует отметить несколько иную политику блокировки остального трафика. Стандартная конфигурация подходит достаточно радикально, запрещая все, кроме LAN. Мы же используем более мягкий подход, и блокируем только внешние сети — WAN. Это позволяет сделать конфигурацию проще и не прописывать дополнительные правила для того же CAPsMAN, при этом мы помним, что администратор знает какие сети являются внутренними, а какие нет и контролирует актуальность списков.
Перейдем к forward, в нашей базовой конфигурации правил для IPsec нет, опять-таки осознанно, по причине их ненужной избыточности. Как появится IPsec — так и создадим правила, а просто так нечего им небо коптить.
А вот к Fasttrack у нас подход другой. В стандартной конфигурации он включен для всех established и related, вне зависимости от направления. Это здорово разгружает роутер, но со временем у вас неизбежно появятся туннели, VPN, прочие сети и Fasttrack будет там чаще мешать, чем помогать, порой приводя к неожиданным результатам. Поэтому четко указываем, что применяем коротки путь только для соединений из локальной сети наружу и извне в локальную сеть. Часто можно даже отойти от использования списков и просто указать интерфейсы.
Кстати, внимательный читатель может заметить, что комментарий стоит только у одного правила, первого. Это сделано специально. Для чего? Посмотрите на скриншот выше, там комментарий отделяет сразу два правила.
Ну и дальше все тоже самое. Разрешаем established и related, запрещаем invalid и обязательно указываем, что это именно для внешних сетей, ниже запрещаем все остальное, также для внешних интерфейсов.
Что касается DNAT, то мы не сторонники давать доступ в сеть самыми широкими мазками. Если появляется проброс — создаем отдельное правило под проброс. Может это и увеличивает количество работы, но дает более читаемую и безопасную конфигурацию брандмауэра, когда вы явно видите кому и что разрешено без изучения дополнительных разделов.
Но если вы используете роутер дома и самый широкий набор приложений пробрасывает порты при помощи UPnP, то последнее правило действительно будет удобнее заменить на:
Данный набор правил является базовым костяком нормально настроенного брандмауэра и должен присутствовать по умолчанию на любом устройстве. Уже потом он будет обрастать дополнительными правилами, но общий принцип построения защиты должен неукоснительно соблюдаться. Это позволит вам достичь высокого уровня безопасности при небольшой нагрузке на устройство.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
MikroTik Настройка Firewall
За несколько лет работы, мы для себя нашли некоторую золотую середину в настройке Firewall MikroTik, и естественно хотим поделиться ею с вами.
MikroTik Firewall Filter
Хочу признаться мне не очень нравиться дефолтный конфиг Firewall, но я прекрасно понимаю, что тем кто его придумал, была задача найти условно общую конфигурацию которая бы подходила к большинству и покрывала решение зада большинства, но мы не большинство, и будем “лепить” свой конфиг.
Естественно чистим конфигурацию или просто очищаем полностью Filter Firewall-а.
В первую очередь мы должны защитить наш маршрутизатор от условных проблем, атак или злоумышленников из сети интернет.
Interface List ISP
В моём случае для примера у меня три провайдера ether1, ether2, ether3 и поверх ether3 запущен PPPoE туннель для получения доступа к интернету.
Создадим лист интерфейсов в котором перечисляем все интерфейсы подключенные к сетям провайдеров. Причём неважно один или два или десять у вас таковых интерфейсов.
Как вы его назовёте, не имеет значения, главное чтобы вам был понятен смысл имени и наверное очень важно, то чтобы было понятно любому другому человеку который взглянет на ваши настройки. Ведь согласитесь если вы его назовёте “Bla-bla-bla” смысл для любого человека будет непонятен, хотя возможно для вас он и будет иметь сакральный смысл.
Я предпочитаю называть данный лист ISP, что обозначает Internet Service Provider.
Соответственно добавляем в данный лист все интерфейсы провайдеров.
Обратите вниманию я добавил ether3 и PPPoE интерфейс которые поднят через него же. По поводу наименование PPPoE туннеля не удивляйтесь у меня есть привычка использовать в наименовании интерфейсов точку в случае если данные интерфейс является sub интерфейсом другого интерфейса. К примеру если у меня будет vlan 100 на первом интерфейсе его имя будет ether1.100.
Настройка MikroTik
Закажи настройку MikroTik непосредственно сейчас, поможем в поиске решения по любому кейсу связанному с MikroTik.
Предоставляю гарантию две недели на свою работу, оплата постфактум, работаю как с юридическими, так и физическими лицами.
На данный момент мы закончили с настройкой листа ISP и может приступить непосредственно к настройке Firewall.
Firewall Filter
Начнём непосредственно настраивать наш filter.
Firewall Filter Input
Первым делом мы будем настраивать трафик, который пришёл на маршрутизатор, и является потенциально опасным для маршрутизатора.
Все дальнейшие правила мы делаем в разделе фильтра, я не буду указывать в приведённых примерах.
Самым первым правилом отправляем весь трафик с интерфейсов провайдеров в кастомную цепочку (custom chain) с помощью jump.
С этого момента мы будем работать ТОЛЬКО с цепочкой ISP-Input , про цепочку input можете пока забыть, хотя она нам ещё понадобится.
Следующим правило мы разрешаем, пакеты established которые возвращаются на уже установленное соединение, такие пакеты необходимо разрешать.
Обратите внимание, что я не указываю ни интерфейсы, ни список интерфейсов, нам нет необходимости этого делать, так как самое первое правило отправило в данную цепочку только трафик которые приходит с интерфейсов провайдеров перечисленных в листе ISP.
Следующее правило разрешаем related , это пакеты, которые создали вторичное соединение, такие пакеты помечаются когда на основании какого либо payload создаются новые соединения, например если вы используете NAT-helper ftp или SIP. Также related в некоторых случаях это ICMP ответ маршрутизатора.
Мы часто используем возможность снижение нагрузки на connection-tracker с помощью исключения пакетов с помощью raw untracked, также используется для обхода NAT в случае когда необходимо исключить процедуру изменения заголовка пакета.
Кто-то из вас скажет, “Стоп-стоп, но ведь мы можем все эти три последние правила описать одним, просто перечислив состояния через запятую. Зачем создавать три правила?!” Да можем, но моя задача, во-первых, показать вам все правила наглядно, а во вторых у нас появляется возможность видеть количество трафика и нагрузку pps по каждому конкретному типу пакетов, и в случае необходимости изменить порядок для оптимизации.
Настала пора создать наше первое запрещающее правило, мы должны запретить пакеты с состоянием invalid , таким состоянием помечаются пакеты в нескольких случаях:
- Если на вашем маршрутизаторе закончится память и connection-tracker не сможет создать запись для соединения, но это редкий случай.
- Если пакет принадлежит к одному из протоколов GRE , ICMP или TCP , то RouterOS умеет понимать по-содержимому пакетов данные протоколов должен являться данный пакет частью существующего соединения или нет. Если по признакам он является частью соединения, но соединения нет в connection-tracker, то такой пакет помечается как invalid . Пример на маршрутизатор пришёл один пакет TCP с флагами syn и ack , т.е. Какой-то хост “по идеи” ответил на посылку syn пакета, но если соединения нет, то нам такой пакет не нужен. Также это простая защита от TCP RST Flood.
Как вы наверное знаете в RouterOS с включенным connection-tracker существует пять состояний пакетов, четыре из которых мы описали, а так как правила в firewall терминирующие, т.е после срабатывания правила пакет прекращает обработку в filter. У нас остаётся всего один тип пакетов это new это те самые пакеты которые создают соединения, другими словами когда кто-то инициализирует соединение к маршрутизатору такой пакет имеет состояние new . Но так как мы описали четыре состояния, нет смысла указывать состояние, так как подразумевается по остаточному принципу, что в следующем правиле и так будут только new .
Мне часто приходится настраивать RouterOS под проекты, и зачастую я подготавливаю оборудование так, чтобы с ним было комфортно работать заказчику, так как со временем у заказчика могут появиться дополнительные кейсы, и чтобы было однотипность в настройках мы поступаем следующим образом.
Выносим все разрешающие правила в отдельную цепочку например с именем ISP-Input-Allow . В таком случае нет необходимости думать в каком месте по порядку разместить правила, чтобы они были правильно расположены относительно всех других правил.
Следующим правилом мы запрещаем все остальные пакеты, которые дошли до следующего правила. Будьте аккуратны, возможно если вы подключены через провайдера к маршрутизатору, вы не сможете подключиться к маршрутизатору в случае разрыва соединения.
Ну вот пожалуй с каркасом закончили, теперь нам необходимо разрешить какой-то трафик на сам маршрутизатор.
Для закрепления результата представим, что у нас поднят на RouterOS l2tp сервер и мы хотим иметь возможность подключаться по ssh, а также маршрутизатор должен отвечать на запросы icmp.
Мы будем использовать кастомную цепочку ISP-Input-Allow и порядок правил в нём не важен, а также неважно расположение правил в этой цепочке относительно всех других правил, хоть в разнобой, хоть в конце, хоть в начале. Это не принципиально. Наверное всё-таки для удобства желательно расположить их по порядку и в одном месте. Но это только для тех кто использует winbox для настроек, а для тех кто используется CLI или как-то оркестратор типа ansible, как раз проявляется удобство в том, что вам не надо думать о прядке правил.
Опишу правила одним блоком
Если пакет которых поступает в данную цепочку дойдёт до конца её, то он перейдёт на следующее правило после которого он попал в данную цепочку.
Вот таким образом у вас должен выглядеть filter в winbox.
Я отформатировал вывод убрав отображение некоторых столбцов.
А теперь давайте посмотрим как будут работать данные правила, при поступлении рафика в цепочку INPUT.
Первый пример HOST 5.5.5.5 хочет установить соединение с SSH MikroTik с адресом 2.2.2.2.
Хост 5.5.5.5 отправляет syn пакет для установления соединения с ssh сервером на MikroTik
Такой пакет первым же правилом попадает под jump и отправляется к custom chain ISP-Input
Далее маршрутизатор находит все правила в кастомной цепочке ISP-Input перебирать соответствию пакета для правила
В первых 4 правилах в цепочке ISP-Input он не найдёт соответствия, а вот в пятом правиле сделает jump на ещё одну цепочку. Соответственно выберет все правила из новой цепочке ISP-Input-Allow
И будет снова сверять по порядку, соответствия пакета правилу.
Как только найдено терминирующее правило, а в нашем случае это accept, маршрутизатор заканчивает обработку данного пакета в filter firewall и отправляет пакет в Local Process.
SSH сервер ответит пакетом TCP c флагами syn,ack после получения такого пакета клиент отправит пакет с флагом ACK и такой пакет уже будет обрабатываться как established .
Но первым же правилом в цепочке ISP-input у нас есть разрешающее терминирующее правило для пакетов с состоянием established. Такой пакет сразу отправиться в Local Process.
А теперь давайте попробуем разобраться, что будет если хост отправит пакет на порт Winbox TCP 8291, который мы явно не запрещали.
Начало будет одинаковое
Когда пакет будет проверяться соответствиям правилам в цепочке ISP-Input-Allow, для него не найдётся, не одного подходящего правила.
В этом случае произойдёт автоматически return, и обработка выйдет из цепочки ISP-Input-Allow и продолжит обрабатываться в цепочке ISP-Input а у нас есть правило, которое отбрасывает все пакеты DROP всё, такой пакет не когда, не попадёт в Local Process.
Т.е если в custom chain не найдено соответствие, не с одним правилом, то обработка такого пакета возвращается и продолжает обработку по порядку со следующего правила места входа.
Для удобства восприятия поставил слева номера, чтобы был понятен порядок обработки
И ещё раз порядок правил имеет значения только для каждой отдельной цепочки, а не относительно всех цепочек.
На этом этапе мы закончили работу с трафиком Input и переходим к Forward.
Firewall Filter Forward
Естественно нам необходимо защитить трафик, который проходит со стороны провайдеров через маршрутизатор.
Многие наверное скажут, а зачем его защищать, ведь трафик нельзя отправить через маршрутизатор, для этого необходимо адрес маршрутизатора прописать как шлюз, что в свою очередь говорит о том, что маршрутизатор должен находится в Connected сети.
Вот вам маленькая история.
Мне провайдер выдаёт внутренней адрес из сети /22 и со всеми соседями я нахожусь в одном Broadcast домене. Получилось так, что пропустил платёж и мне провайдер на шлюзе зарезал интернет, но он не отключил порт на коммутаторе, и мне всё также была доступна внутренняя сеть. Запустил LLDP на интерфейсе провайдера и увидел что со мной в одной сети находятся как минимум пять маршрутизаторов MikroTik. И логика была у меня такая:
По умолчания в RouterOS на первом порту отключен LLDP, а если я вижу это значит что-либо конфигурации была сброшена либо используется порт не ether1. Соответственно возможно, что на нём неправильно настроен firewall.
Так и получилось я на своём маршрутизаторе прописал адрес MikroTik первого из списка и у меня появился интернет, да с другого IP адреса, но этого достаточно. Сразу скажу, что на всех пяти MikroTik-ах которые я видел, и кстати до сих пор я наблюдаю в сети данные MikroTik c таким образом настроенным Firewall, что я в любой момент могу получить доступ в интернет через них.
Вот именно от таких ситуаций нам необходимо защититься.
И опять же мы будем использовать custom цепочку.
Первым правилом мы отправляем весь проходящий forward трафик с интерфейсов провайдеров в цепочку ISP-Forward.
Следующие правила вам должны быть уже знакомы. Не буду повторять описание
Единственно, что необходимо уточнить, это то что в случае если вы используете BGP или асинхронную маршрутизацию. То вам необходимо разрешать трафик invalid. Но в большинстве случаев это не так.
Далее вы помните, что по типу исключения у нас остаётся только пакеты, которые имеют состояние new, и если подумать то такие пакеты могут проходить через маршрутизатор со стороны провайдера только если они попадают под процедуру изменения адреса назначения.
Поэтому нам необходимо разрешить пакеты new которые попадают под dst NAT.
И последний правилом мы закрываем доступ из вне всем отвальным пакетам.
Давайте взглянем на наши правила.
Соответственно, если вам необходимо разрешить подключаться к маршрутизатору, будь то по VPN или ещё как-то, вы всегда можете добавить правило в цепочку ISP-Input-Allow и не думать о порядке правил.
Mikrotik Firewall: повышаем безопасность при работе с VPN L2TP, PPTP и PPPoE, оптимизация правил файрволла
Во многих предыдущих версиях RouterOS используются правила Firewall с прямым указанием названий интерфейсов для некоторых правил.
Рассмотрим ситуацию на примере старенького RB951Ui-2HnD, для которого в одной из предыдущих версий RouterOS производителем заданы следующие правила по-умолчанию:
Правила относятся к стандартной конфигурации (defconf), поэтому не будут меняться при простом обновлении версии RouterOS, во всяком случае при обновлении до 6.42.1 правила не меняли своего вида. Возможно, изменения будут при полном сбросе.
Как видим, для двух правил используется прямое указание внешнего WAN-интерфейса – ether1-gateway. Для других моделей RouterBOARD может применяться название eth1, ether1 или eth1-gateway, общей сути это не меняет.
В частности, речь идет о правилах «drop input» и «drop not-dstnatated», которые обеспечивают защиту вашей внутренней сети. Вышеприведенные настройки Firewall вполне корректны для типа подключения «Automatic» (DHCP), когда вы не используете классический VPN (l2tp, pptp) или PPPoE.
Как это понимать?
Все дело в том, что при использовании VPN, интернет предоставляется непосредственно внутри тоннеля, а сам клиент при этом может находится в локальной сети провайдера (NAT с авторизацией). Иногда в домашних маршрутизаторах данный тип подключения производители называют как Russian L2TP, Russian PPTP или Dual Access.
В данном случае, приведенные правила Firewall, для которых указан «in-interface=ether1-gateway», имеют отношение исключительно к локальной сети провайдера и при этом не затрагивают vpn-туннель, ведь, по сути, для маршрутизатора это уже отдельный интерфейс. Ситуация усугубляется в тех случаях, когда внутри VPN пользователь получает реальный внешний IP, открывающий доступ к устройству со всего мира.
- 10.0.0.0 — 10.255.255.255
- 100.64.0.0 — 100.127.255.255
- 172.16.0.0 — 172.31.255.255
- 192.168.0.0 — 192.168.255.255
Откройте раздел «Interfaces» (интерфейсы), в нем перейдите на вкладку «Interface List» (списки интерфейсов), нажимаем в верхней части кнопку «Lists» (списки) и создаем новый список под названием WAN.
После создания нового списка интерфейсов, добавляем в него основной физический WAN-интерфейс и PPPoE/VPN-подключение. Например:
После того, как мы создали отдельный список для WAN-интерфейсов, можно приступить к изменению правил Firewall.
Собственно здесь все очень просто. Там, где явно указан in-interface=ether1-gateway, следует его убрать и назначить вместо него параметр in-interface-list=WAN.
После подобного изменения правило будет срабатывать для всех интерфейсов, которые включены в список WAN-интерфейсов.
Данный метод служит также оптимизацией, уменьшающей количество правил Firewall. В противном случае, вам бы пришлось создавать дублирующие правила для каждого WAN-интерфейса, и в конкретно этом примере это были бы лишние 2 правила.
Видеокурс «Настройка оборудования MikroTik» (аналог MTCNA)
Учитесь работать с MikroTik? Рекомендую видеокурс «Настройка оборудования MikroTik». В курсе разобраны все темы из официальной учебной программы MTCNA и много дополнительного материала. Курс сочетает теоретическую часть и практику – настройку маршрутизатора по техническому заданию. Консультации по заданиям курса ведет его автор Дмитрий Скоромнов. Подойдет и для первого знакомства с оборудованием MikroTik, и для систематизации знаний опытным специалистам.
Firewall в Mikrotik
У микротик нет понятия внешней и внутренней сети. В нем есть различные интерфейсы, и мы можем строить правила сетевой безопасности относительно этих интерфейсов.
Относительно входящих (in interface) и исходящих (out interface) интерфейсов.
Всё это находится в разделе IP — Firewall – Filter, на что мы сейчас и посмотрим.
Если мы берем SOHO (small office home office) устройство, которое предназначено для домашнего использования, то в его конфигурации по умолчанию мы увидим стандартный Firewall. Он защищает нашу сеть достаточно хорошо от внешних угроз при условии, что у нас есть внешняя сеть. Также мы можем посмотреть на наш стандартный Firewall, выполнив команду (В левой колонке необходимо нажать «New Terminal»):
И здесь мы можем посмотреть наш стандартный Firewall.
Если вы по какой-то причине удалите эти правила из раздела IP Firewall, то вы можете вернуться к ним в любой момент выполнив команду:
Скопировав необходимый блок в вашу текущую конфигурацию. Либо же скопировав из приведенного выше кода.
На этом базовый осмотр Firewall в Mikrotik закончен. В следующих видео мы продолжим работу с Firewall.