Puncte:1

firewalld: blocarea conexiunilor de ieșire blochează și conexiunile de intrare

drapel in

log4shell ne-a determinat să îmbunătățim securitatea unor servere. Dorim acum să blocăm și traficul de ieșire (pe cât posibil). Regulile actuale pentru firewall sunt:

/> firewall-cmd --list-all
public (activ)
  target: implicit
  icmp-block-inversion: nu
  interfețe: eth0
  surse: 
  servicii: dhcpv6-client https smtp ssh
  porturi: 143/tcp 3000/tcp 4949/tcp 8080/tcp 12999/tcp 25/tcp 1194/tcp
  protocoale: 
  mascarada: nu
  porturi înainte: 
  porturi sursă: 
  icmp-blocks: 
  reguli bogate: 

Deci, de exemplu, conexiunile la server prin ssh sunt în prezent posibile (și ar trebui să fie încă posibile în viitor). Acum vrem să împiedicăm toate conexiunile de ieșire, cu excepția conexiunilor prin https (443). Pentru a face asta, am adăugat câteva reguli firewalld (vezi și https://serverfault.com/a/624474/145652):

/> firewall-cmd --permanent --direct --add-rule filtru ipv4 IEȘIRE 0 -p tcp -m tcp --dport=443 -j ACCEPT
succes
/> firewall-cmd --permanent --direct --add-rule filtru ipv4 OUTPUT 1 -j DROP
succes
/> firewall-cmd --reload

Dar după aceste comenzi, vom pierde toate conexiunile la server: fără ping, fără ssh, serverul nu acceptă nicio conexiune. Posibil ca firewall-cmd --permanent --direct --add-rule filtru ipv4 OUTPUT 1 -j DROP se blochează toate trafic de ieșire, inclusiv răspunsul serverelor la cererile de intrare (ssh-)? Lipsește o regulă care să permită trimiterea datelor de răspuns la cererile primite?

A.B avatar
drapel cl
A.B
Utilizarea regulilor directe abia se califică drept folosirea firewalld. Îl ocolește mai mult (cu valori de prioritate scăzută) decât îl folosește.
Puncte:2
drapel cn

Doar învârt o instanță pentru a testa, dar bănuiesc că este pentru că nu permiteți și regulile de ieșire conexe/stabilite, așa că nucleul vă distruge conexiunile existente.

Actualizare: sunt sigur că aceasta este problema. Tocmai l-am testat pornind Centos 7 pe o instanță EC2, instalând FirewallD și apoi inserând prima regulă fără permanent steag. Toate merg bine.

De îndată ce am lipit în CĂDERE BRUSCA regula, m-am deconectat.

În linkul pe care l-ați furnizat, prima regulă pe care o adaugă este o STABILIT, LEGAT regulă. Aceasta înseamnă că conexiunile care sunt permise sunt permise să iasă (deci firewall-ul este cu stare). Fără această regulă, nu aveți reguli de stare și conexiunea dvs. SSH nu se poate stabili.

Deci, lista dvs. reală de reguli trebuie să fie:

# firewall-cmd --permanent --direct --add-rule filtru ipv4 IEȘIRE 0 -m stare --state ESTABLISHED, RELATED -j ACCEPT
# firewall-cmd --permanent --direct --add-rule filtru ipv4 IEȘIRE 1 -p tcp -m tcp --dport 80 -j ACCEPT
# firewall-cmd --permanent --direct --add-rule filtru ipv4 IEȘIRE 1 -p tcp -m tcp --dport 443 -j ACCEPT
# firewall-cmd --permanent --direct --add-rule filtru ipv4 IEȘIRE 1 -p tcp -m tcp --dport 53 -j ACCEPT
# firewall-cmd --permanent --direct --add-rule filtru ipv4 IEȘIRE 1 -p udp --dport 53 -j ACCEPT
# firewall-cmd --permanent --direct --add-rule filtru ipv4 OUTPUT 2 -j DROP

Rețineți că am inclus și HTTP, HTTPS și DNS - altfel conexiunile nu se vor stabili la nume DNS, deoarece serverul nu le va putea rezolva...

drapel in
În linkul pe care îl pun, citisem doar răspunsul acceptat. Dar uneori este o idee bună să citiți mai mult ca doar răspunsul acceptat sau răspunsul cu cele mai multe voturi pozitive - lol. Mulțumiri!

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.