Am două servere dedicate: „web” (YYY.YYY.YYY.YYY) și „monitor” (XXX.XXX.XXX.XXX).
Ambele sunt în aceeași rețea a unui hoster de masă (hetzner).
Acum pe „web” am 3 puncte finale prometheus metric care rulează: docker-engine (9323) pe gazda bare metal și neo4j (2004), telegraf (9273) ca containere docker.
Ambele containere docker își mapează corect porturile de ieșire la gazdă, astfel încât următoarele apeluri executate pe „web” funcționează:
lynx http://YYY.YYY.YYY.YYY:9323/metrics => OK
lynx http://YYY.YYY.YYY.YYY:9273/metrics => OK
lynx http://YYY.YYY.YYY.YYY:2004/metrics => OK
Dar apelarea acelor puncte finale de pe serverul „monitor” funcționează numai pentru motorul docker-service bear metal (9323)
lynx http://YYY.YYY.YYY.YYY:9323/metrics => OK
lynx http://YYY.YYY.YYY.YYY:9273/metrics => timeout
lynx http://YYY.YYY.YYY.YYY:2004/metrics => timeout
UFW status verbose oferă următoarele
Stare: activ
Înregistrare: activată (scăzută)
Implicit: deny (incoming), allow (outgoing), deny (direcționat)
Profiluri noi: săriți
La Acțiune De la
-- ------ ----
[...]
9323/tcp PERMITERE ÎN XXX.XXX.XXX.XXX
9273/tcp PERMITERE ÎN XXX.XXX.XXX.XXX
2004/tcp PERMITERE ÎN XXX.XXX.XXX.XXX
[...]
Nu există alte reguli cu acele IP-uri și nici reguli generale care se aplică subrețelelor, interfețelor etc. Toate celelalte reguli sunt pentru porturi discrete, cum ar fi 22, 80, 443 etc.
Lucrul ciudat este că a funcționat cu doar câteva ore înainte. Între timp am experimentat puțin cu asta aici https://medium.com/@pitapun_44686/what-is-the-best-practice-of-docker-ufw-under-ubuntu-69e11c826b31 și a adăugat următorul bloc chiar la sfârșitul /etc/ufw/after.rules
*filtru
:ufw-user-forward - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16
-A DOCKER-USER -j ufw-user-forward
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12
-UN DOCKER-USER -j RETURN
COMMIT
Acum l-am comentat și am repornit ufw. Acele porturi 9273 și 2004 nu sunt încă accesibile, așa că nu acesta a fost motivul.
Am configurat nivelul de jurnal ufw la mare, dar nu pot vedea nicio conexiune attepmtps sau pachete abandonate de la gazda XXX.XXX.XXX.XXX.
Încercând să fac telnet în singurul port de lucru (telnet YYY.YYY.YYY.YYY 9323) pot vedea comunicarea în jurnalele ufw, dar nu pentru celelalte două porturi.
[UFW AUDIT] SRC=XXX.XXX.XXX.XXX DST=YYY.YYY.YYY.YYY DPT=9323 =>
[UFW AUDIT] SRC=YYY.YYY.YYY.YYY DST=XXX.XXX.XXX.XXX SPT=9323
Am furnizat ufw folosind modulul ansible „ufw”.
Ce alte motive ar putea fi? Ce se întâmplă? :-)
Ar putea fi că rețeaua de hosteri impune un fel de filtru între acele servere din cauza activității „suspecte” (comunicare frecventă)?
De asemenea, se întâmplă să rulez niște teste artillery.io excesive de la XXX.XXX.XXX.XXX la portul 80/443 pe YYY.YYY.YYY.YYY astăzi, dar această ipoteză nu explică de ce numai acele două porturi nu funcționează mai mult.
Și testul final, oprirea ufw pe YYY.YYY.YYY.YYY, nici nu merge. Porturile 9273 și 2004 nu sunt accesibile, 9323 este.
Aici este rezultatul de la iptables -L -v -n https://pastebin.com/HVeJGXb9
