VP
Я могу поспорить. Я пользуюсь сервисами с определённых IP, мне большего и не надо (пока).
Пользоваться можно, но нужно понимать нюансы такого использования. На мой взгляд недостатки перевешивают. Могу аргументировать.
Size: a a a
2020 December 23
AK
Пользоваться можно, но нужно понимать нюансы такого использования. На мой взгляд недостатки перевешивают. Могу аргументировать.
Давайте )
ВС
Пользоваться можно, но нужно понимать нюансы такого использования. На мой взгляд недостатки перевешивают. Могу аргументировать.
Да, конечно, мне интересны аргументы,.
AK
Зависит от задач. Но, спорьте - на то и чатик. )
замена ип - аддрессес - это файрвол.
Есть машины на которых не настраивают файрвол.
Есть машины на которых не настраивают файрвол.
AK
ЕК
Не очень мудро делать ограничения в сервисах. Можно, но не хорошо.
С точки зрения производительности - да.
VP
Да, конечно, мне интересны аргументы,.
1. Безопасность. В различных сервисах регулярно находят различные зиродэй уязвимости. Делеко ходить не нужно - уязвимость винбокса в микротике. Фаерволл в этом плане надежнее.
2. Нагрузка на ресурс. Все соединения приходящие на ACL целевого сервиса, будут проходить через нетфильтр, контрак и уже потом обрабатываться сервисом. Т.е. каждое новое соединение будет грузить всю цепочку. Поэтому при мало-мальской атаке на сервис роутеру будет туго.
2. Нагрузка на ресурс. Все соединения приходящие на ACL целевого сервиса, будут проходить через нетфильтр, контрак и уже потом обрабатываться сервисом. Т.е. каждое новое соединение будет грузить всю цепочку. Поэтому при мало-мальской атаке на сервис роутеру будет туго.
ВС
1. Безопасность. В различных сервисах регулярно находят различные зиродэй уязвимости. Делеко ходить не нужно - уязвимость винбокса в микротике. Фаерволл в этом плане надежнее.
2. Нагрузка на ресурс. Все соединения приходящие на ACL целевого сервиса, будут проходить через нетфильтр, контрак и уже потом обрабатываться сервисом. Т.е. каждое новое соединение будет грузить всю цепочку. Поэтому при мало-мальской атаке на сервис роутеру будет туго.
2. Нагрузка на ресурс. Все соединения приходящие на ACL целевого сервиса, будут проходить через нетфильтр, контрак и уже потом обрабатываться сервисом. Т.е. каждое новое соединение будет грузить всю цепочку. Поэтому при мало-мальской атаке на сервис роутеру будет туго.
на счёт первого не совсем понял, я говорил о том же самом, фаервол обрезает соединения с левых адресов, а второе вытекает из первого, или я что-то не так понимаю?
VP
на счёт первого не совсем понял, я говорил о том же самом, фаервол обрезает соединения с левых адресов, а второе вытекает из первого, или я что-то не так понимаю?
Коротко говоря, если режете доступ фаерволлом, АЦЛ сервиса смысла не имеют. Больше настроек - больше шанс ошибиться.
ВС
ок, вопросов нет.
AK
1. Безопасность. В различных сервисах регулярно находят различные зиродэй уязвимости. Делеко ходить не нужно - уязвимость винбокса в микротике. Фаерволл в этом плане надежнее.
2. Нагрузка на ресурс. Все соединения приходящие на ACL целевого сервиса, будут проходить через нетфильтр, контрак и уже потом обрабатываться сервисом. Т.е. каждое новое соединение будет грузить всю цепочку. Поэтому при мало-мальской атаке на сервис роутеру будет туго.
2. Нагрузка на ресурс. Все соединения приходящие на ACL целевого сервиса, будут проходить через нетфильтр, контрак и уже потом обрабатываться сервисом. Т.е. каждое новое соединение будет грузить всю цепочку. Поэтому при мало-мальской атаке на сервис роутеру будет туго.
я кстати сделал немножко не так
так как интернет приходит в микротовский свитч, на свитче закрыть попробовал винбокс
/interface ethernet switch rule add dst-address=mtk-ip dst-port=8291 ports=ether1,sfp-sfpplus4 protocol=tcp src-address=valid-ip switch=switch1
/interface ethernet switch rule add dst-address=mtk-ip dst-port=8291 new-dst-ports="" ports=ether1,sfp-sfpplus4 protocol=tcp switch=switch1
так как интернет приходит в микротовский свитч, на свитче закрыть попробовал винбокс
/interface ethernet switch rule add dst-address=mtk-ip dst-port=8291 ports=ether1,sfp-sfpplus4 protocol=tcp src-address=valid-ip switch=switch1
/interface ethernet switch rule add dst-address=mtk-ip dst-port=8291 new-dst-ports="" ports=ether1,sfp-sfpplus4 protocol=tcp switch=switch1
KM
@Falciloid i need to setup gre over ipsec
KM
between a mikrotik and huawei ar1200
LT
between a mikrotik and huawei ar1200
So why you can't do this?
KM
the gre tunnel cannot ping
KM
shall i show you the settings?
LT
the gre tunnel cannot ping
Ping independent from tunnels. Describe your task and issues with you stuck more fully
KM
I get the tunnel established in mikrotik
KM
but current bytes counter for installed SA
KM
only increases for one SA