Puncte:1

FreeBSD 13 PF blochează traficul din închisoare

drapel id

După ce mi-am actualizat sistemul FreeBSD de la 12.2 la 13.0-p3 PF blochează tot traficul către închisorile mele. Când dezactivați PF totul funcționează bine (cu excepția faptului că este neprotejat ;))

Am încercat să îmi dau seama ce regulă blochează acest trafic prin setarea „blochează în jurnal toate”, dar în afară de unele lucruri evidente multicast nu apare nimic care să explice de ce acest trafic este blocat.

Din nou, înainte totul a funcționat perfect sub versiunea 12.2. Am găsit câteva articole despre v13 acum filtrarea prin VLAN în loc de lo0, dar nu folosesc niciun VLAN.

În ce direcție ar trebui să caut mai departe?

Actualizare 2021-07-15:

Din motive de claritate: iată fișierul meu pf_rules:

setați returnarea politicii de bloc
setați optimizarea agresivă
setați săriți pe { lo0, lo1, lo2, lo3, lo4, lo5 }
ext_if=hn0
ext_address="{ 192.x.x.x, 2001:981:x.x::x }"
ext_services = "{ ssh, http, https, smtp, smtps }"
tcp_services = „{ ftp, ssh, domeniu, ntp, www, smtp, smtps, trimitere, http, https,nfs}”
udp_services = "{domeniu, ntp, nfs }"
icmp6_types="{ 2, 128 }" # pachet prea mare, cerere de ecou (ping6)
icmp6_types_ext_if="{ 128, 133, 134, 135, 136, 137 }"
jail_net = „192.168.1.0/24”
jail_services = "{ mysql, http, smtp, 587, 3000 }"
tabelul <sshguard> persistă
freca în toate
nu trece $ext_if de la $jail_net la orice -> $ext_address
blocați log pe $ext_if proto tcp de la <sshguard> la orice port ssh etichetă „ssh bruteforce”
blocați în log all
treceți rapid din <pf_whitelist> semnalează starea synproxy S/SA
transmiteți pe $ext_if inet6 proto icmp6 toate icmp6-tip echoreq păstrați starea
trece pe $ext_if inet proto udp la portul 33433:33626
trece pe $ext_if inet6 proto udp la portul 33433:33626
transmiteți pe $ext_if inet6 proto ipv6-icmp icmp6-type $icmp6_types păstrați starea
treceți pe $ext_if inet6 proto ipv6-icmp de la orice la { ($ext_if ), ff02::1/16 } icmp6-type $i
cmp6_types_ext_if păstrează starea
treceți pe $ext_if proto tcp de la oricare la portul $ext_address $ext_services păstrează starea
treceți pe $ext_if inet6 proto tcp de la oricare la portul $ext_address $ext_services păstrează starea
transmite $ext_if inet proto tcp la orice port $tcp_services keep state
transmite $ext_if inet6 proto tcp către orice port $tcp_services păstrează starea
transmite $ext_if inet6 proto udp către orice port $udp_services
trece proto udp la orice port $udp_services keep state
treceți în proto tcp de la oricare la portul $jail_net $jail_services păstrează starea
transmite proto tcp de la $jail_net la orice port $jail_services keep state
trece inet proto icmp de la orice la oricare

Acest lucru a funcționat de mulți ani până la FreeBSD 13

drookie avatar
drapel za
`kldload pflog && ifconfig pflog0 up && tcpdump -netti pflog0`? Și actualizați-vă întrebarea cu rezultatele.
GTeley avatar
drapel id
După cum am spus, am verificat jurnalele (cu tcpdump), dar în afară de unele lucruri UDP și multicast, nu apare nimic: 1626265392.763303 regula 1/0(potrivire): blocare pe hn0: 192.168.178.56.138 > 192.168.178.255.138: NBT UDP PACKET(138) 1626265398.905896 regula 1/0(potrivire): blocați pe hn0: fe80::98af:7b38:affd:bc9f > ff02::16: HBH ICMP6, raport de ascultare multicast v2, 4 înregistrări de grup, lungime 88
drapel br
A trebuit să elimin steagul „synproxy”.
Puncte:0
drapel id

Aparent, acest lucru nu a avut nimic de-a face cu PF, ci ceva cu procesul de actualizare de la versiunea 12.2 la 13.0. Instalarea versiunii 13 pe un server fizic și crearea unei închisori cu unele servicii au funcționat bine. Deci ar putea avea ceva de-a face cu upgrade-ul pe un server virtual, fie el Hyper-V sau altceva.Încă nu știu, deoarece totul în setări și configurație arată la fel (cea mai mare parte am copiat-o de pe serverul virtual actualizat unde nu funcționează)

Puncte:0
drapel br

Citând din Proxy TCP SYN:

| Proxy-ul SYN nu va funcționa dacă PF rulează pe un bridge(4).

Scoateți steagul synproxy

treceți rapid din <pf_whitelist> semnalează starea synproxy S/SA

Încearcă în schimb

trece rapid de la <pf_whitelist> steagurile S/SA păstrează starea

Dacă funcționează, îl puteți folosi numai pentru închisori și păstrați synproxy pentru alții, de ex.

trece rapid de la <pf_whitelist> la $jail_net flags S/SA păstrează starea
treceți rapid din <pf_whitelist> semnalează starea synproxy S/SA
GTeley avatar
drapel id
Salut Vladimir, Vă mulțumim pentru contribuție. Din păcate, nu pare să te ajute. De asemenea: presupun că este mai mult. Crearea unei noi închisori (în scopuri de testare) nu a funcționat deoarece ezjail-admin nu a reușit să creeze link-uri către /bin, /sbin etc. Așa că trebuie să mă aprofundez în acest lucru pentru a afla ce nu merge mai bine în versiunea 13. Poate ar fi trebuit să treacă peste 13 și să treacă direct la 14 ;)
GTeley avatar
drapel id
Da, cu siguranță este ceva în neregulă cu FreeBSD 13 și închisori. Nici măcar într-o închisoare (cele care au venit de la 12.2) nu mai pot accesa serviciile prin adresa „externă” pe care ascultă. Deci, dacă un serviciu HTTP local rulează pe portul 3000, pe o închisoare 12.2 îl pot accesa de ex. „curl -v 192.168.1.101:3000” Pe un sistem actualizat la v13, acest lucru nu mai funcționează. Acest lucru (parțial?) explică de ce nu există încercări de acces blocate în de pf_log.
drapel br
Imi pare rau sa aud asta. FWIW, folosesc [Rolul Ansible](https://github.com/vbotka/ansible-freebsd-jail). A trebuit să elimin semnalul „synproxy” doar când am trecut de la 12 la 13.
GTeley avatar
drapel id
Am instalat un vechi server IBM x3400 M3 cu FreeBSD 13 de la zero și am creat un test_jail, am instalat niște servicii și totul merge bine. Deci trebuie să aibă ceva de-a face cu procesul de actualizare. Deoarece tot ce pot vedea este identic în configurare și configurare (în afară de faptul că una este o mașină virtuală), este foarte dificil să spun ce a mers prost
drapel br
Văd. Doriți să închideți aceste întrebări și răspunsuri?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.