В
Кто-нибудь пробовать запускать RouterOS в bhyve гипервизоре? У меня не заводится, пробовал и x86 и CHR
Size: a a a
2020 March 22
VK
ссылки выше
И кстати rfc3871 "
Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited."
Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited."
I
И кстати rfc3871 "
Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited."
Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited."
да, и именно поэтому практика отсутствия проверки встречается
Л
2.5.6 вроде только про это, и там даже написано, что применять это нужно не всегда. Или чот я просмотрел?
В 2.5.5 ещё об этом, но там тоже:
This requirement only holds for single-homed networks. Note that
a simple forwarding table check is not sufficient in the more
complex scenarios of multi-homed or multi-attached networks, i.e.,
where the traffic may be asymmetric. In these cases, a more
extensive check such as Feasible Path RPF could be very useful.
This requirement only holds for single-homed networks. Note that
a simple forwarding table check is not sufficient in the more
complex scenarios of multi-homed or multi-attached networks, i.e.,
where the traffic may be asymmetric. In these cases, a more
extensive check such as Feasible Path RPF could be very useful.
Л
да, и именно поэтому практика отсутствия проверки встречается
Видимо всё таки встречается (раз уж столько людей здесь за неё топят), но в чём профит для провайдера от такой проверки так никто и не ответил.
VK
да, и именно поэтому практика отсутствия проверки встречается
Не очень понятно, зачем проверять. Ну погнал клиент трафик с срц другого провайдера, где опасность?
I
Не очень понятно, зачем проверять. Ну погнал клиент трафик с срц другого провайдера, где опасность?
подумайте на шаг вперед
Л
Не очень понятно, зачем проверять. Ну погнал клиент трафик с срц другого провайдера, где опасность?
На самом деле опасность, конечно, есть. Но в контексте провайдера эта опасность притянута за уши. Опасность, вероятно, в том, что злоумышленник может представлятся адресом жертвы, и таким образом совершать атаку.
I
чаще всего это не из-за мультихоминга происходит
VK
подумайте на шаг вперед
Ну подумал, не вижу опасности. Если вы видите - скажите, в чем она
I
вон, чак написал выше
Л
Но подчеркну - в контексте провайдера - это сова с глобусом внутри.
I
есть куча протоколов, которые отвечают большим куском данных в ответ на маленький пакет-запрос
I
рефлекшн-ддос замутить при отсутствии проверки на сорс - как два пальца
Л
есть куча протоколов, которые отвечают большим куском данных в ответ на маленький пакет-запрос
Это проблема провайдера? Или это проблема конечного пользователя/владельца сервиса?
VK
вон, чак написал выше
Это за уши притянуто. Распространенные атаки посредством dns и так работают, потому что там в запросе l7 ещё срц есть, и вот его-то и подменяют, хоть зафильтуйся.
I
Это за уши притянуто. Распространенные атаки посредством dns и так работают, потому что там в запросе l7 ещё срц есть, и вот его-то и подменяют, хоть зафильтуйся.
это проблема одного протокола
VK
И у ntp то же самое
I
Это проблема провайдера? Или это проблема конечного пользователя/владельца сервиса?
это проблема Интернета
I
и ISOC предписывает решать эту проблему провайдерам