Довольно типичная для айтишников (как людей, в целом не обладающих развитым гуманитарным знанием) и неверная точка зрения.
В чём именно она неверная? Есть определённая должность в компании - ведущий разработчик aka senior. У него определённые обязанности, и передача опыта через говорение слов ртом в них не входит. Есть задача. Делаем её, документируем в базе знаний, чтобы всем было понятно. При этом пишем поддерживаемый и понятный код. Если кому-то что-то непонятно, то они задают вопросы в комментариях к документации, и там же получают ответы. Имхо, этого вполне хватает для качественной передачи знаний внутри компании.
Что значит "не делится знаниями"? Если процессы документирования налажены, то это не проблема. А каждому разжёвывать на синках, почему сделано так и иначе, и объяснять азы - ну за это надо отдельно доплачивать и это сугубо добровольно должно быть, потому что тут у нас не семинары для обмена опытом и не школа.
Для защиты от кражи сокетов необходимо настраивать серверные приложения в стандартный режим монопольного использования сетевых портов. На использование опций SO_REUSEPORT или SO_REUSEADDR для серверных сокетов следует наложить табу.
Многопоточные/многопроцессные приложения, которым это необходимо, при этом как себя поведут? Так же предлагаю вам дополнить статью конкретным примером, как это можно сделать :)
жёстко зашиты в коде (внутри функций / методов) / hardcoded
вынесены в константы модулей
константы намного лучше, чем «магическеские числа» и «магические строки» непосредственно в коде
полезно если константы меняются крайне редко, но всё же могут меняться
вынесены в отдельные конфиг‑файлы (файлы, используемые для хранения параметров и настроек приложений).
Я бы добавил ещё два метода конфигурирования - через переменные окружения и через аргументы командной строки. Ну и никто не запрещает использовать сразу несколько методов конфигурирования, которые "наслаиваются" друг на друга.
А вот зря не считаете это страшным. Это очень сильно фрустрирует - внедрение какой-то хурмы ради отсутствия застоя. Это время и усилия можно потратить с большей пользой.
Но раз мы уменьшили себя, то значит уменьшились и наши рецепторы и теперь мы не можем видеть волны, которые значительно больше нас самих. То есть мы перестанем видеть в обычном видимом свете, как видит человек стандартных размеров. Мы перестанем видеть большинство цветов, зато будем видеть рентгеновское излучение.
Мне такое рассуждение кажется немного сомнительным.
В командах есть добавление фильтра с действием зеркалирования трафика, но не учтено, что команды создания ingress очереди нет, а без неё и фильтр не будет создан.
UPD: ни через tc, ни через netdev / ingress хук невозможно заблокировать получение датаграм на сокеты af_packet / pf_packet, т.к. клонирование происходит вот здесь (при условии, что у нас в системе есть фильтры, которые отбирают данные датаграммы; если таких фильтров нет, то и клонирования не происходит - т.н. ленивое поведение), а обработка tc qdisc ingress происходит чуть дальше по коду, и только после происходит обработка через netdev / ingress хук. Так что, похоже, XDP является одним из немногих оставшихся вариантов дропнуть подобный трафик, т.к. выполнение XDP программы происходит чуть раньше, чем происходит клонирование датаграммы.
Пунтим вопрос обратно на мозг: как так iptables пакет считает в статистику, но не может дропнуть? Или может?
На стековерфлоу есть ответ на вопрос, почему счётчики правил для отбрасывания пакетов инкрементируются (и эти пакеты на самом деле дропаются), а dhcp клиент продолжает работать без проблем.
Да, причём именно в egress направлении замечательно фильтруется. Вешаем любую classfull дисциплину и навешиваем несложный фильтр. Например:
~/# tc q add dev <iface> root handle 1: prio
~/# tc f add dev <iface> parent 1: protocol ip prio 1 flower ip_src 0.0.0.0/32 ip_dst 255.255.255.255 ip_protocol udp src_port 68 dst_port 67 action drop
Но нужно дополнительно исследовать поведение, когда на сокете выставлена опция PACKET_QDISC_BYPASS. Тут я навскидку не скажу - надо читать код ядра.
Для ядер, начиная с 5.16 доступен дополнительный способ вместо tc - там добавлен хук netdev/egress, который можно использовать из nftables.
~/# nft -i
nft> flush ruleset
nft> add table netdev t
nft> add chain netdev t egress_chain { type filter hook egress device <iface> priority 0; }
nft> add rule netdev t egress_chain ip saddr 0.0.0.0/32 ip daddr 255.255.255.255/32 meta l4proto udp udp sport 68 udp dport 67 counter drop
А вот в направлении ingress фильтрация через tc / nftables обламывается, потому что клонирование пакета происходит раньше, чем эти инструменты вступают в работу. Это можно увидеть на прекрасной диаграмме из вики (на ней есть неточности, так что не верьте всему и перепроверяйте всегда).
Ошибка при выборе инструмента.
Skill issues.
Вполне себе заменяет.
В чём именно она неверная? Есть определённая должность в компании - ведущий разработчик aka senior. У него определённые обязанности, и передача опыта через говорение слов ртом в них не входит. Есть задача. Делаем её, документируем в базе знаний, чтобы всем было понятно. При этом пишем поддерживаемый и понятный код. Если кому-то что-то непонятно, то они задают вопросы в комментариях к документации, и там же получают ответы. Имхо, этого вполне хватает для качественной передачи знаний внутри компании.
Тут уже другая проблема - человек пишет неподдерживаемый код (магия без комментариев и документации).
Что значит "не делится знаниями"? Если процессы документирования налажены, то это не проблема. А каждому разжёвывать на синках, почему сделано так и иначе, и объяснять азы - ну за это надо отдельно доплачивать и это сугубо добровольно должно быть, потому что тут у нас не семинары для обмена опытом и не школа.
Ну и всё-таки
GRE over IPSEC, а не наоборот.Многопоточные/многопроцессные приложения, которым это необходимо, при этом как себя поведут? Так же предлагаю вам дополнить статью конкретным примером, как это можно сделать :)
Я бы добавил ещё два метода конфигурирования - через переменные окружения и через аргументы командной строки. Ну и никто не запрещает использовать сразу несколько методов конфигурирования, которые "наслаиваются" друг на друга.
А вот зря не считаете это страшным. Это очень сильно фрустрирует - внедрение какой-то хурмы ради отсутствия застоя. Это время и усилия можно потратить с большей пользой.
О, ещё один SHITOps!
Но раз мы уменьшили себя, то значит уменьшились и наши рецепторы и теперь мы не можем видеть волны, которые значительно больше нас самих. То есть мы перестанем видеть в обычном видимом свете, как видит человек стандартных размеров. Мы перестанем видеть большинство цветов, зато будем видеть рентгеновское излучение.Мне такое рассуждение кажется немного сомнительным.
В командах есть добавление фильтра с действием зеркалирования трафика, но не учтено, что команды создания ingress очереди нет, а без неё и фильтр не будет создан.
А как вам такое мировоззрение - https://ru.wikipedia.org/wiki/Философский_пессимизм
А будет в обозримом будущем что-нибудь из свежей литературы по Rust? Например, второе издание The rust programming language.
Это разные программы. "Соло на клавиатуре" и сейчас живёт и здравствует. Переехало в вэб.
В openwrt используется своя система инициализации и управления сервисами - procd
UPD: ни через tc, ни через netdev / ingress хук невозможно заблокировать получение датаграм на сокеты af_packet / pf_packet, т.к. клонирование происходит вот здесь (при условии, что у нас в системе есть фильтры, которые отбирают данные датаграммы; если таких фильтров нет, то и клонирования не происходит - т.н. ленивое поведение), а обработка tc qdisc ingress происходит чуть дальше по коду, и только после происходит обработка через netdev / ingress хук. Так что, похоже, XDP является одним из немногих оставшихся вариантов дропнуть подобный трафик, т.к. выполнение XDP программы происходит чуть раньше, чем происходит клонирование датаграммы.
На стековерфлоу есть ответ на вопрос, почему счётчики правил для отбрасывания пакетов инкрементируются (и эти пакеты на самом деле дропаются), а dhcp клиент продолжает работать без проблем.
Да, причём именно в egress направлении замечательно фильтруется. Вешаем любую classfull дисциплину и навешиваем несложный фильтр. Например:
Но нужно дополнительно исследовать поведение, когда на сокете выставлена опция
PACKET_QDISC_BYPASS. Тут я навскидку не скажу - надо читать код ядра.Для ядер, начиная с 5.16 доступен дополнительный способ вместо tc - там добавлен хук netdev/egress, который можно использовать из nftables.
А вот в направлении ingress фильтрация через tc / nftables обламывается, потому что клонирование пакета происходит раньше, чем эти инструменты вступают в работу. Это можно увидеть на прекрасной диаграмме из вики (на ней есть неточности, так что не верьте всему и перепроверяйте всегда).
В том переводе есть фатальный недостаток. И не хватает частей.