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.