И 10 лет не прошло. NAT Pinning возвращается.
https://www.securitylab.ru/news/513749.php
Исходник с более подробным описание.
IMHO от «iptables -j CT --helper» нужно отказаться.
https://www.securitylab.ru/news/513749.php
Исходник с более подробным описание.
IMHO от «iptables -j CT --helper» нужно отказаться.
Наконец можно будет не патчить ядро и iptables для пропуска нескольких правил!
В nftables-0.97 завезли конструкции вида
table inet x {
chain y {
type filter hook input priority 0;
tcp dport 22 jump {
ip saddr { 127.0.0.0/8, 172.23.0.0/16, 192.168.13.0/24 } accept
ip6 saddr ::1/128 accept;
}
}
}
Теперь можно рассматривать nftables как конкурента iptables.
Правда не совсем понятно нужно ли для этого ядро >= 5.10-rc1
Это просто удачный экземпляр или на него мало писали?
=== START OF INFORMATION SECTION ===
Model Family: SandForce Driven SSDs
Device Model: OCZ-VERTEX3
Serial Number: OCZ-E54XIIO79BY3459C
LU WWN Device Id: 5 e83a97 e1c01a1a1
Firmware Version: 2.15
User Capacity: 120,034,123,776 bytes [120 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS, ACS-2 T13/2015-D revision 3
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Thu Oct 29 10:02:27 2020 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 094 094 050 Pre-fail Always - 0/128828398
5 Retired_Block_Count 0x0033 100 100 003 Pre-fail Always - 0
9 Power_On_Hours_and_Msec 0x0032 020 020 000 Old_age Always - 70615h+54m+56.360s
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 38
171 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0
172 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0
174 Unexpect_Power_Loss_Ct 0x0030 000 000 000 Old_age Offline - 20
177 Wear_Range_Delta 0x0000 000 000 000 Old_age Offline - 15
181 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0
182 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
194 Temperature_Celsius 0x0022 030 030 000 Old_age Always - 30 (Min/Max 30/30)
195 ECC_Uncorr_Error_Count 0x001c 120 120 000 Old_age Offline - 0/128828398
196 Reallocated_Event_Count 0x0033 100 100 003 Pre-fail Always - 0
201 Unc_Soft_Read_Err_Rate 0x001c 120 120 000 Old_age Offline - 0/128828398
204 Soft_ECC_Correct_Rate 0x001c 120 120 000 Old_age Offline - 0/128828398
230 Life_Curve_Status 0x0013 100 100 000 Pre-fail Always - 100
231 SSD_Life_Left 0x0013 100 100 010 Pre-fail Always - 0
233 SandForce_Internal 0x0000 000 000 000 Old_age Offline - 15264
234 SandForce_Internal 0x0032 000 000 000 Old_age Always - 36244
241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 36244
242 Lifetime_Reads_GiB 0x0032 000 000 000 Old_age Always - 11928
Правильно ли я понимаю, что google имеет доступ к содержимому push-уведомлений?
Хочется получить информацию за некоторое время для одного процесса какие файлы он читал/писал и сколько данных прочитано/записано для каждого файла.
Есть уточнение: процесс - php-fpm.
Теоретически strace подходит, но нужно парсить его вывод.
А есть ли что-то готовое?
Не могу найти размеры разъёма питания для RPI4
Сколько милиметров диаметры отверстия и штыря?
Питание через usb type-c не рассматривается.
Есть 2 профиля. В одном все работает, во втором безумные тормоза при наличии видео или html5/canvas(?)
Чем можно экспортировать настройки профиля в текстовый вид для последующего сравнения?
Давно я так не охреневал заглянув в комп :)
(Картинки на яндекс-диске. У кого изжога на него - проходите мимо)
Вот так вот, хрусь и пополам! Жертва - Arctic Freezer Xtreme выпуска до 2014 года.
Дело было вечером, время 21 час, т.е. в магазин бежать поздно, да и денег жалко на старенький комп.
Пришлось колхозить крепление из ляминия.
Так оно выглядит перед сборкой.
Есть работающий bigbluebutton сервер. API реализовано на tomcat7
В ходе разборок с одной проблемой выяснилось, что один запрос API дает кучу запросов к несуществующим файлам
grep ENOENT | sort | uniq -c
125 stat("/META-INF/services/javax.xml.parsers.SAXParserFactory", 0x7f55024e1000) = -1 ENOENT (No such file or directory)
8 stat("/META-INF/services/javax.xml.parsers.SAXParserFactory", 0x7f55024e1530) = -1 ENOENT (No such file or directory)
125 stat("/usr/share/bbb-web/META-INF/services/javax.xml.parsers.SAXParserFactory", 0x7f55024e1000) = -1 ENOENT (No such file or directory)
8 stat("/usr/share/bbb-web/META-INF/services/javax.xml.parsers.SAXParserFactory", 0x7f55024e1530) = -1 ENOENT (No such file or directory)
125 stat("/usr/share/bbb-web/WEB-INF/classes/META-INF/services/javax.xml.parsers.SAXParserFactory", 0x7f55024e1000) = -1 ENOENT (No such file or directory)
125 stat("/usr/share/bbb-web/WEB-INF/classes/META-INF/services/javax.xml.parsers.SAXParserFactory", 0x7f55024e1030) = -1 ENOENT (No such file or directory)
8 stat("/usr/share/bbb-web/WEB-INF/classes/META-INF/services/javax.xml.parsers.SAXParserFactory", 0x7f55024e1530) = -1 ENOENT (No such file or directory)
8 stat("/usr/share/bbb-web/WEB-INF/classes/META-INF/services/javax.xml.parsers.SAXParserFactory", 0x7f55024e1560) = -1 ENOENT (No such file or directory)
125 stat("/usr/share/bbb-web/WEB-INF/META-INF/services/javax.xml.parsers.SAXParserFactory", 0x7f55024e1000) = -1 ENOENT (No such file or directory)
8 stat("/usr/share/bbb-web/WEB-INF/META-INF/services/javax.xml.parsers.SAXParserFactory", 0x7f55024e1530) = -1 ENOENT (No such file or directory)
Можно ли это как-то исправить?
В основном проекте решили начать переформатирование кода.
merge дает коллизии по несколько сотен строк :(
При том, что «diff -ubwB» говорит о незначительных изменениях.
Может есть способы немного облегчить/автоматизировать этот процесс ?
Два вопроса:
- есть ли в ffmpeg аппаратного ускорения для перекодирования в vp9 ? (судя по всему из vp8)
- какую железку при этом нужно иметь для этого ?
Есть ли живая поделка для получения object-pinned из классического BPF для актуальных ядер ?
Ну или один работоспособный пример для «iptables -m bpf --bbject-pinned ...»
filter2xdp с github не актуален. За 3 года в ядре что-то сильно поменялось и валидатор eBPF ругается на все инструкции.
Есть работающая связка openssh + pam_oath + freeotp
А чем файл с f2a кодами редактировать кроме как текстовым редактором?
Хочется уметь добавлять/заменить/убавить коды для юзера.
А юзеру, при вводе своего пароля, показывать код и qrcode (для freeotp например).
Вход по ключам при этом тоже существует.
до запуска fuse_main() создается тесколько тредов.
В каждом треде создаётся таймер через timerfd_create(CLOCK_REALTIME, 0)
далее делаем timerfd_settime(tfd, TFD_TIMER_ABSTIME,...)
таймер через 2 секунды и интервал 2 секунды.
все работает!
как только запускается fuse_main() в виде демона, то все чтение из tfd прекращается.
Что это за @#$%^&*! ?
Есть объектный файл с отладочной информацией.
1. Хочется получить список функций имеющихся в нём.
nm или objdump решают эту задачу.
2. Для каждой функции получить список вызываемых функций.
Чем это можно сделать?
Новость не совсем свежая, но все-таки https://www.securitylab.ru/news/504821.php
Под видом обеспечения доступа к гос. ресурсам будут втюхивать корневой сертификат на все девайсы?
Есть вебморда (roundcube) и почтовик на другой машине.
На каждый клик в вебмейле оно подключается на почтовик, что IMHO не здорово.
Есть imapproxy, который умеет кешировать коннекты по логину. На тестовой системе все просто сказочно!
А в продакшене его кто-нибудь использует?
Владельцам ядер ниже 4.4 можно не читать.
Собственно есть cgroup и iptables -m cgroup. Почему бы не создать отдельный cgroup и фильтровать локальный трафик для этой группы?
1. Не забываем включить классную фичу
sysctl -w net.ipv4.ip_early_demux=1
# на ядрах 4.10+
sysctl -w net.ipv4.tcp_early_demux=1
sysctl -w net.ipv4.udp_early_demux=1
2. Создаем группу
mkdir /sys/fs/cgroup/net_cls/testgroup2
echo 1234 >/sys/fs/cgroup/net_cls/testgroup2/net_cls.classid
3. создаем тестовые правила
iptables -A INPUT -m cgroup --cgroup 1234 -p icmp
iptables -A INPUT -m cgroup --cgroup 1234 -p udp
iptables -A INPUT -m cgroup --cgroup 1234 -p tcp
iptables -A OUTPUT -m cgroup --cgroup 1234 -p icmp
iptables -A OUTPUT -m cgroup --cgroup 1234 -p udp
iptables -A OUTPUT -m cgroup --cgroup 1234 -p tcp
4. Переносим себя в эту группу
echo $$ >/sys/fs/cgroup/net_cls/testgroup2/tasks
5. Тестируем UDP
dig google.com
iptables -nvxL INPUT; iptables -nvxL OUTPUT
Chain INPUT (policy ACCEPT 2 packets, 255 bytes)
pkts bytes target prot opt in out source destination
0 0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
0 0 udp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
0 0 icmp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
Chain OUTPUT (policy ACCEPT 2 packets, 91 bytes)
pkts bytes target prot opt in out source destination
0 0 icmp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
2 91 udp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
0 0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
6. Тестируем TCP
iptables -Z
wget -4 -O /dev/zero https://google.com
iptables -nvxL INPUT; iptables -nvxL OUTPUT
Chain INPUT (policy ACCEPT 4 packets, 538 bytes)
pkts bytes target prot opt in out source destination
4 538 tcp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
0 0 udp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
0 0 icmp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
Chain OUTPUT (policy ACCEPT 6 packets, 451 bytes)
Chain OUTPUT (policy ACCEPT 6 packets, 451 bytes)
pkts bytes target prot opt in out source destination
0 0 icmp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
0 0 udp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
6 451 tcp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
7. Тестировать остальные протоколы бесполезно, т.к. они не поддерживаются в early_demux
Что имеем в результате? TCP можно контролировать для группы, а с UDP пролный 3.14ц!
Поковыряв ядро становится полностью понятно почему.
Проблема в том, что в UDP можно сделать bind() только на порт, что делает поиск сокета на которые пришли данные в два раза сложнее. __udp4_lib_demux_lookup() делает поиск только по номеру порта и адресу, игнорируя сокеты привязанные только к номеру порта.
Заменив __udp4_lib_demux_lookup() на полноценный поиск udp сокета через __udp4_lib_lookup()
для ядра 4.14.165
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 731ea78..6143ca5 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2295,8 +2295,8 @@ int udp_v4_early_demux(struct sk_buff *skb)
uh->source, iph->saddr,
dif, sdif);
} else if (skb->pkt_type == PACKET_HOST) {
- sk = __udp4_lib_demux_lookup(net, uh->dest, iph->daddr,
- uh->source, iph->saddr, dif, sdif);
+ sk = __udp4_lib_lookup(net, iph->saddr, uh->source, iph->daddr, uh->dest,
+ dif, 0, &udp_table, NULL);
}
if (!sk || !refcount_inc_not_zero(&sk->sk_refcnt))
Да, это дополнительные накладные расходы, но мы дважды это подтвердили через net.ipv4.ip_early_demux=1 и net.ipv4.udp_early_demux=1
Но теперь мы получаем в п.5
Chain INPUT (policy ACCEPT 2 packets, 255 bytes)
pkts bytes target prot opt in out source destination
0 0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
1 226 udp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
0 0 icmp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
Chain OUTPUT (policy ACCEPT 2 packets, 91 bytes)
pkts bytes target prot opt in out source destination
0 0 icmp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
2 91 udp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
0 0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 cgroup 1234
Но это патч ядра, который не все могут осилить.
Есть возможность получить аналогичный результат при помощи модуля ядра. ( https://github.com/vel21ripn/ipt_sk_helper )
Чтоб оно заработало нужно сделать sysctl -w net.ipv4.ip_early_demux=2
Работа проверялать на 4.4.209 и 4.14.165. Собирается даже на 5.4.х
Если кто может попробовать собрать его и протестировать - напишите что получилось.
PS Если починить эту фичу в официальном ядре, то станет доступной фильтраци входящего трафика по UID/GID.
| ← назад | следующие → |