[boco]

24 минуты назад, ixi сказал:

А там tcp-reset или drop?

 

Коннтрак в этом конфиге и не нужен, достаточно изменить порядок правил

 

Ни в чём, конечно же. Можно спокойно жить и с открытым ssh и всё будет нормально. Но висящее на стене ружьё обязательно выстрелит.

 

я хз как тут цитировать нормально, после какого-то обновления форума перестала вообще работать тема nag classic. поетому отвечу без цитат.

 

1. без понятия, надо в исходники конкретного рекурсера смотреть. это важно?

 

2. как изменить? я вот вижу что в предложенном конфиге без коннтрака рекурсер не получит ответов на свои запросы.

 

3. в чем принципиальная разница закрыть ssh фаерволом или tcp wrappers? я не понимаю, поясните.

[The Ripper]

Цитата

3. в чем принципиальная разница закрыть ssh фаерволом или tcp wrappers? я не понимаю, поясните.

kernel или userspace ?

cloudflare, вон, вообще еще "до" фильтрует - https://blog.cloudflare.com/l4drop-xdp-ebpf-based-ddos-mitigations

Изменено 29 декабря, 2023 пользователем The Ripper

[boco]

52 минуты назад, The Ripper сказал:

kernel или userspace ?

cloudflare, вон, вообще еще "до" фильтрует - https://blog.cloudflare.com/l4drop-xdp-ebpf-based-ddos-mitigations

ну вы клаудфлэр-то с обычными гражданами не сравнивайте 😃

 

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

[The Ripper]

Будто 1Mpps и более что-то из карьера с белазами :)

Я и на своей мелкой сети такое видел.

 

Ну ладно, я спорить не буду. Оно мне надо ? ;)

[boco]

12 минут назад, The Ripper сказал:

Будто 1Mpps и более что-то из карьера с белазами 🙂

Я и на своей мелкой сети такое видел.

1 mpps к рекурсеру?! если это не шутка, поделитесь как и чем вы это перевариваете? а то у меня есть твердая уверенность, что скалировать dnsdist до 1 mpps не получится

[The Ripper]

Ну да. В жизни всегда все так, как ожидается.

Все идет по плану. Исключительно всегда. ;)

 

Речь, конечно, шла не о dns. А вообще, чуть больше 1mpps спокойно переварили четырехядерные sandybdirge супермикры (nftables с flowtables).

Интересно, что об этом подумал бы tcpwrappers ? :)

Изменено 29 декабря, 2023 пользователем The Ripper

[boco]

39 минут назад, The Ripper сказал:

Речь, конечно, шла не о dns. А вообще, чуть больше 1mpps спокойно переварили четырехядерные sandybdirge супермикры (nftables с flowtables).

Интересно, что об этом подумал бы tcpwrappers ? 🙂

я думаю эти mpps'ы у вас софтроутер гоняет слева направо. tcp wrappers тут ортогонально. более того, именно в таких софтроутерах с целью минимизации числа правил фаервола (для ускорения пересылки пакетов слева направо) рекомендуется прикрывать tcp wrappers'ами и собственными acl слушающие сеть сервисы.

[The Ripper]

Да чего спорим-то ?

Речь о kernel/userspace идет, не более.

Про conntrack мимо - его можно и не использовать.

И ядром фильтровать ненужное разумнее, нежели передавать это в юзерспейс и т.д.

 

Понятно что tcpwrappers и forwarding это про красное и круглое.

 

На пальцах - скорее всего, конфеты едите без фантиков ? То есть у вас есть спец инструмент для очистки конфеты (руки), инструмент для оценки конфеты (глаза, обоняние), и только потом вы принимаете решение пустить конфету по пищеварительному тракту.

 

Пихать все в юзерспейс - это, кмк, жрать конфеты не снимая фантики. В теории некоторые виды обертки могут быть переварены, конечно. Но зачем ? :)

[The Ripper]

...рекомендуется прикрывать tcp wrappers'ами и собственными acl слушающие сеть сервисы

то есть если у меня даже охулиард правил в input у меня тормозит forward, чтоли ? :)

 

"Собственный acl сервиса" должен быть конечно. Но тут уже больше для приличия.

Пусть, например, рекурсор тратит вычислительную мощность для, непосредственно, работы, а не решает кому зя, а кому низя.

Изменено 29 декабря, 2023 пользователем The Ripper

[boco]

55 минут назад, The Ripper сказал:

...рекомендуется прикрывать tcp wrappers'ами и собственными acl слушающие сеть сервисы

то есть если у меня даже охулиард правил в input у меня тормозит forward, чтоли ? :)

да, здесь вы правы. в линухе не тормозит.

 

1 час назад, The Ripper сказал:

Про conntrack мимо - его можно и не использовать.

можете показать, как должны выглядеть правила в этом случае?

[The Ripper]

как должны выглядеть правила в этом случае?

nf_conntrack можно и не загружать, если нет правил его использующих (--state и проч.) и/или nat

[boco]

3 минуты назад, The Ripper сказал:

как должны выглядеть правила в этом случае?

nf_conntrack можно и не загружать, если нет правил его использующих (--state и проч.) и/или nat

ну то есть политику дроп на инпут убрать и файнтюнить правила? уже не так лаконично получается. в принципе, рабочее решение, если сеть ничто больше не слушает и не будет слушать.

[The Ripper]

chain policy к conntrack не имеет отношения

 

вы же когда даете/не даете доступ в acl самого userspace приложения, там же нет никакого conntrack и отслеживания состояний

 

уберите nf_conntrack и то же самое будет уже происходить в ядре и более эффективно

 

если нужно что-то дропать еще более эффективно - ссылку на cloudflare выше дал :)

[boco]

3 минуты назад, The Ripper сказал:

chain policy к conntrack не имеет отношения

если не убрать политику дроп на инпут, рекурсер без коннтрака не получит ответ от авторитетного сервера

[The Ripper]

еще раз - chain policy тут ни при чем

policy - предписание, что делать с пакетом не подошедшим ни под одно правило в цепочке

 

речь о established и related состояниях (ответах, то есть) при отсутствии разрешающих правил ?

 

для unbound - outgoing-port-permit: тут-диапазон

и безусловно делать accept в этот диапазон на входе

 

пока нет запроса, нет открытого порта

[boco]

10 минут назад, The Ripper сказал:

речь о established и related состояниях (ответах, то есть) при отсутствии разрешающих правил ?

 

для unbound - outgoing-port-permit: тут-диапазон и безусловно делать accept в этот диапазон на входе

да, речь именно про это.

про диапазон портов - зачем же себя ограничивать? так можно и не вписаться. и главное - все это извращение весь этот файнтюнинг только чтобы недайбох не сделать болт в юзерспейсе, это же пипец как накладно. =)

вощем мне тоже надоело. =) я предложил простое, эффективное и главное проверенное практикой решение. настаивать не буду. мир дружба жевачка.

[Ivan_83]

On 12/28/2023 at 6:54 PM, boco said:

за счет чего? и насколько затратнее?

Потому что длинна пайпа обработки очень сильно различается.

 

В случае фаера это: разобрать IP, провалится в фаер, разобрать UDP, отматчить правила, дропнуть пакет.

 

В случае ACL в приложении:разобрать IP, провалится в фаер, разобрать UDP, отматчить правила, постоять в очереди обработки пакетов, свалится в обработчик UDP, разобрать заголовок UDP, найти соответствующий сокет, закинуть в очередь обработки сокета, разбудить приложение/послать эвент на чтение, переключить контекст, вычитать данные из сокета, сматчить ACL.

 

Уловили разницу в длине?

Даже если выкинуть фаер, операция переключения контекста считается весьма затратной и её стараются избегать, так же вычитывание из сокета это копирование памяти (почти всегда).

 

 

13 hours ago, ixi said:

Можно спокойно жить и с открытым ssh и всё будет нормально. Но висящее на стене ружьё обязательно выстрелит.

Ружья боятся - огнестрел не хранить :)

У меня за 15 лет с ssh была только один раз одна проблема - когда во фре нашли что оказывается можно хитро мимо пароля входить, из за какой то там ошибки.

А проблема в том, что пришлось обновлять пока другие не зашли :)

[boco]

4 часа назад, Ivan_83 сказал:

Даже если выкинуть фаер, операция переключения контекста считается весьма затратной и её стараются избегать, так же вычитывание из сокета это копирование памяти (почти всегда).

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

 

лучше предложите топикстартеру правила без коннтрака, все полезнее чем стращать переключениями контекста для исчезающе малой доли невалидных пакетиков =)

 

ps. для прикола посчитал, сколько раз отработал tcp wrappers для ssh за вчера на одном из наших рекурсеров - получилось 1 раз в 10 минут. и вот ради этого включать фаервол? [:facepalm:]

[Ivan_83]

On 12/30/2023 at 12:31 AM, boco said:

что затраты на переключение контекста даже несколько раз в секунду

Почему вы решили что будет именно такой низкий рейт?

 

On 12/30/2023 at 12:31 AM, boco said:

ps. для прикола посчитал, сколько раз отработал tcp wrappers для ssh за вчера на одном из наших рекурсеров - получилось 1 раз в 10 минут. и вот ради этого включать фаервол? [:facepalm:]

Так это забивание гвоздей микроскопом, эффективность стремещаяся к нулю.

 

On 12/30/2023 at 12:31 AM, boco said:

ничто по сравнению с пробеганием каждого пакета по коннтраку.

А зачем для DNS контрак?

 

On 12/30/2023 at 12:31 AM, boco said:

лучше предложите топикстартеру правила без коннтрака, все полезнее чем стращать переключениями контекста для исчезающе малой доли невалидных пакетиков =)

Я не шарю в этих ваших линуксах :)

[boco]

41 минуту назад, Ivan_83 сказал:

Почему вы решили что будет именно такой низкий рейт?

по опыту =)

 

41 минуту назад, Ivan_83 сказал:

А зачем для DNS контрак?

ну потому что либо коннтрак, либо ограничить рекурсер каким-то диапазоном исходящих портов. выше же обсудили... попахивает, не к ночи будь помянут, протоколом ftp =)

[Ivan_83]

20 hours ago, boco said:

ну потому что либо коннтрак, либо ограничить рекурсер каким-то диапазоном исходящих портов.

Я не понимаю зачем контрак для DNS, ICMP и некоторых других протоколов.

[sdy_moscow]

А может кто знает, сходу, как используя не "прибитый" к порту UDP сокет заставить отправлять пакеты kernel_sendmsg(...) с определенного номера порта, а не с того "в какой палец" попадет :-). А то, что-то спринт пробежка по манам не помогла, прибивать "сокет" тоже не особо хочется - входящий трафик не предполагается....

[Ivan_83]

12 hours ago, sdy_moscow said:

А может кто знает, сходу, как используя не "прибитый" к порту UDP сокет заставить отправлять пакеты kernel_sendmsg(...) с определенного номера порта, а не с того "в какой палец" попадет :-).

Никак.

socket API под это не рассчитан.

Если хотите только слать то вам в RAW, там divert, bpf и прочее где заголовки самому собирать. Рабочий пример под вашу ОС можно посмотреть в DHCP клиенте.

[sirmax]

В 30.12.2023 в 02:31, boco сказал:

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

 

лучше предложите топикстартеру правила без коннтрака, все полезнее чем стращать переключениями контекста для исчезающе малой доли невалидных пакетиков 😃

 

ps. для прикола посчитал, сколько раз отработал tcp wrappers для ssh за вчера на одном из наших рекурсеров - получилось 1 раз в 10 минут. и вот ради этого включать фаервол? [:facepalm:]

А вы не думали, что acl у условного днс, не такая уж железобетонная защита? На 53 порт вам могут затупить что угодно, не только корректный пакет. А вы уверены что специально сформированный некорректный с точки зрения днс запрос не вызовет у вас например отказ в обслуживании и крах демона? 

 

шанс словить баг в файрволле ( ядре) который пропустит пакет имхо на порядок ниже чем в прикладном софте. 
 

а еще лучше фильтровать не на сервере а на отдельной железке, хоть софтверной хоть аппаратной хоть средствами клауда и не трахать му-му

[ixi]

В 29.12.2023 в 11:10, boco сказал:

1. без понятия, надо в исходники конкретного рекурсера смотреть. это важно?

Я использую для разных случаев оба варианта. Использовать случайный для всех -- можно, конечно, но..

 

В 29.12.2023 в 11:10, boco сказал:

2. как изменить? я вот вижу что в предложенном конфиге без коннтрака рекурсер не получит ответов на свои запросы.

В unbound есть опция вроде outgoing-port-range, разрешаете их и всё. Два правила на 99.9% трафика

 

В 29.12.2023 в 11:10, boco сказал:

3. в чем принципиальная разница закрыть ssh фаерволом или tcp wrappers? я не понимаю, поясните.

tcp wrappres -- это userspace, менее безопасно по умолчанию. Не говоря о скорости..

 

В 30.12.2023 в 00:29, Ivan_83 сказал:

У меня за 15 лет с ssh была только один раз одна проблема - когда во фре нашли что оказывается можно хитро мимо пароля входить, из за какой то там ошибки.

Багами не зацепило, но один случай всё же был, юзеру надоело копировать пароль от бастиона и он сменил его себе на словарный. Так что с файрволом всё же безопаснее.