Puncte:0

UFW blochează conexiunile de ieșire existente atunci când este activat

drapel in

Am o problemă în care ufw pare să blocheze conexiunile de ieșire existente pe portul 443 când este activat. Exemplu:

24 februarie 17:53:00 server5 kernel: [18571501.131985] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=35.196.37.91 DST=1.2.3.4 LEN=40 TOS=0x00 PREC=0x60 TTL=51 ID=24902 DF PROTO=TCP SPT=443 DPT=44496 WINDOW=0 RES=0x00 RST URGP=0 
24 februarie 17:33:40 server5 kernel: [18570340.976130] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=52.10.136.43 DST=1.2.3.4 LEN=83 TOS=0x00 PREC=0x00 TTL=228 ID=23746 DF PROTO=TCP SPT=443 DPT=59404 WINDOW=118 RES=0x000 PSH 0000 PSH
27 februarie 00:47:07 server5 kernel: [18769144.299731] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=35.196.37.91 DST=1.2.3.4 LEN=1460 TOS=0x00 PREC=0x60 TTL=51 ID=60877 DF PROTO=TCP SPT=443 DPT=42030 WINDOW=229 RES=0x00ACK

De asemenea, obțin blocarea unor pachete UDP, chiar dacă am permis în mod special UDP de la 1025-65535:

24 februarie 17:52:19 server5 kernel: [18571459.414576] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=5.6.7.8 DST=1.2.3.4 LEN=69 TOS=0x00 PREC=0x00 TTL=44 ID=59557 PROTO=UDP SPT=58678 DPT=49900 LEN=49 

(Am înlocuit ip-ul serverului nostru cu 1.2.3.4). Traficul blocat sunt conexiuni curl de ieșire către Google Drive și Vimeo.

Iată cum l-am configurat:

ufw resetare
ufw implicit permite expedierea
ufw implicit deny incoming
ufw permite de la 96.54.177.7 proto tcp la orice port 22
ufw permite de la 50.70.255.166 proto tcp la orice port 22
ufw permit 443/tcp
ufw permit 80/tcp
ufw permit 25/tcp
ufw permit 587/tcp
ufw permit 1025:65535/udp

starea ufw arată:

Stare: activ
Înregistrare: activată (scăzută)
Implicit: refuza (intrat), permite (ie), dezactivat (direcționat)
Profiluri noi: săriți

La Acțiune De la
-- ------ ----
22/tcp PERMITERE ÎN 99.99.99.99               
22/tcp PERMITERE ÎN 99.99.99.99             
443/tcp PERMITERE PENTRU Oriunde                  
80/tcp PERMITERE PENTRU Oriunde                  
25/tcp PERMITERE PENTRU Oriunde                  
587/tcp PERMITERE ÎN Oriunde                  
  

În testare:

  • începerea unei încărcări noi în Vimeo după activarea ufw funcționează bine.Nimic nu pare a fi blocat.
  • activarea ufw în mijlocul unei încărcări Vimeo pare să o rupă.
  • Telnetting la portul 587 (mail) de pe server în altă parte și activarea ufw nu pare să cauzeze probleme. Conexiunea rămâne deschisă și pot scrie ajutor etc.
  • conntrack nu afișează niciodată conexiunile de ieșire, dar arată conexiunile de intrare ok.
  • când testez pe o nouă instanță de server cloud ubuntu 20.04, nu există probleme... Nu văd niciun pachet blocat pentru portul 443, iar încărcările funcționează bine. Dar pe serverul cloud de testare conntrack nu este instalat și chiar și după ce instalez conntrack și conntrackd nu văd deloc conexiuni listate în „conntrack -L”.

Deci, sunt puțin confuz cu privire la ce se întâmplă exact aici și dacă ar trebui să-mi fac griji. Nu vreau să activez ufw până când nu înțeleg pe deplin ce va face traficul meu. Cum exact ține evidența conexiunilor de ieșire dacă conntrack nu le urmărește?

Cred că se pot întâmpla câteva lucruri aici, dar aș vrea să înțeleg de ce le văd. Blocurile UDP și ACK sunt cele mai îngrijorătoare, dar par să se întâmple doar pentru o fracțiune de secundă după activarea ufw, așa că mă întreb dacă există o ușoară întârziere în timp ce ufw activează regulile. Celălalt (RST) se poate datora doar închiderii conexiunii. Blocurile ACK par să cauzeze probleme cu orice conexiuni de ieșire deschise existente care trimit în mod activ date atunci când firewall-ul este activat.

Puncte:0
drapel in

În urma investigațiilor ulterioare, s-a dovedit că pachetele blocate au avut loc doar pe o perioadă de mai puțin de 1 secundă în timp ce ufw era activat. Comanda „ufw enable” nu este nici pe departe atomică... este un script python care interacționează cu iptables. Ați putea presupune că face doar una sau două comenzi iptables, dar acest lucru este incorect. Rularea unei strace pe „ufw enable” arată că de fapt execută comanda iptables sau ip6tables de 358 de ori în cazul meu:

strace -f -tt ufw --force enable > /tmp/a 2>&1
root@testing:/home/ubuntu# grep exec /tmp/a|wc -l
358
root@testing:/home/ubuntu# grep exec /tmp/a|grep iptables|wc -l
135
root@testing:/home/ubuntu# grep exec /tmp/a|grep ip6tables|wc -l
134

Exemplu:

[pid 1959] 17:13:34.241806 execve("/usr/sbin/ip6tables", ["/usr/sbin/ip6tables", "-I", "ufw6-user-limit", "-m", "limit ", "--limit", "3/minut", "-j", "LOG", "--log-prefix", "[UFW LIMIT BLOCK] "], 0x7ffd5e6d3d10 /* 18 vars */ <nefinished . ..>

Deci, rezultatul este că activarea ufw poate distruge temporar orice conexiuni existente care transmit sau primesc date în perioada de timp necesară pentru a activa ufw, așa că aveți grijă să activați ufw pe un server live.

Puncte:0
drapel cn

Dacă te uiți cu atenție, poți vedea că traficul pierdut este trafic de intrare DST=1.2.3.4 DST înseamnă destinație și, după cum ați afirmat, 1.2.3.4 este IP-ul dvs.

Conform ieșirii de starea ufw Traficul are portul sursă 443 (SPT) nu DPT (care ar fi fost permis) și, prin urmare, este abandonat de ufw.

Bănuiesc că ați făcut o greșeală undeva (probabil legată de traducerea adresei de rețea) care are ca efect că firewall-ul nu are stare.

drapel in
Acesta este un răspuns de la serverul de la distanță (deci SRC este serverul de la distanță), dar conexiunea este cu siguranță către serverul nostru și nu este urmărită de conntrack. Mi-am editat răspunsul pentru a afișa comenzile exacte pe care le-am folosit pentru a configura ufw. Nu există comenzi care să-l facă cu stare sau nu, așa că nu văd cum este greșeala mea, dar vă rog să mă corectați dacă greșesc. Problema pare să fie conntrack care nu urmărește conexiunile de ieșire. De ce este asta?
Puncte:0
drapel gn

Pentru acesta:

24 februarie 17:53:00 server5 kernel: [18571501.131985] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=35.196.37.91 DST=1.2.3.4 LEN=40 TOS=0x00 PREC=0x60 TTL=51 ID=24902 DF PROTO=TCP SPT=443 DPT=44496 WINDOW=0 RES=0x00 RST URGP=0 

Nu este neobișnuit. Vedeți mai multe detalii într-unul dintre răspunsurile mele anterioare Aici.

Urmatorul:

24 februarie 17:33:40 server5 kernel: [18570340.976130] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=52.10.136.43 DST=1.2.3.4 LEN=83 TOS=0x00 PREC=0x00 TTL=228 ID=23746 DF PROTO=TCP SPT=443 DPT=59404 WINDOW=118 RES=0x000 PSH 0000 PSH

Nu este atât de clar, dar au existat și probleme cu întreruperea conexiunii la trecerea de la UFW dezactivat la activat în trecut. Unele metode de investigare sunt furnizate într-un alt răspuns anterior al meu Aici

Pentru acesta:

conntrack nu afișează niciodată conexiunile de ieșire, dar arată conexiunile de intrare ok.

Nu este adevarat. Iată un exemplu:

doug@s15:~$ sudo conntrack -L | grep 192.168.111.134
tcp 6 35972 STABILIT src=192.168.111.1 dst=192.168.111.134 sport=36866 dport=22 src=192.168.111.134 dst=192.168.111.134 dst=192.168.111.134 sport=36866 dport=22 src=192.168.111.134 dst=192.168.168.111.134 dst=192.168.168.111.134
conntrack v1.4.6 (conntrack-tools): au fost afișate 68 de intrări de flux.

Aceasta este o conexiune de ieșire realizată de la serverul meu principal gateway la 192.168.111.1 la un raspberry pi la 192.168.111.134.

drapel in
Pentru serverul meu, se pare că nu văd conexiuni de ieșire folosind conntrack -L. Conexiunile asociate cu 35.196.37.91 din exemplul de mai sus nu au apărut niciodată în conntrack (dar au apărut în netstat). Când ies telnet către portul 587 al serverului meu de acasă, apare în netstat, dar nu în conntrack -L. Ar putea asta să cauzeze problema? De ce serverul meu (stock ubuntu 20.04 de la OVH) nu ar afișa conexiuni de ieșire în conntrack?
drapel in
De asemenea, uitându-mă din nou la jurnalele, toate pachetele blocate par a fi RST sau ACK-uri. Bănuiesc că RST nu este o problemă, dar ACK-urile ar putea fi.
Doug Smythies avatar
drapel gn
„OVH” înseamnă că este un server găzduit? Afișarea conexiunii tale în tabelul de urmărire este destul de fundamentală, așa că nu știu de ce a ta nu o face.
drapel in
Nu, este un server dedicat cu OVH. Am încercat pe un server cloud cu OVH folosind ubuntu 20.04, iar conntrack -L nu afișează nicio intrare, inbound sau outbound. A trebuit să instalez conntrack și conntrackd. Dar chiar și fără urmărirea conexiunii, pot configura ufw. Deci, ufw are propria sa urmărire a conexiunii? Întreaga chestiune este foarte confuză și prost documentată în acest sens și mă tem să-l rulez pe serverul meu de produse până când îl înțeleg corect.
Doug Smythies avatar
drapel gn
Ei bine, nu există un tabel conntrack decât dacă iptables îl folosește. Rețineți că UFW este doar un front end pentru iptables. Modul de a înțelege aceste lucruri este să folosiți iptables pentru a analiza fluxul de pachete și contoare și altele în setul de reguli pe care îl creează UFW. Eu însumi urăsc UFW și setul complicat de reguli iptables greu de citit pe care îl creează. Serverul meu de testare nu are nicio regulă iptables setată, iar tabelul conntrack arată ca gol, chiar dacă am mai multe sesiuni SSH care rulează.
drapel in
Da, foloseam iptables brute pe centos fără probleme. ufw pare doar o modalitate mult mai rezonabilă de a gestiona un firewall decât a crea iptables manual.

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.