firewalld cauzează nmap pentru a returna gazdă pare în jos (Administrarea sistemului, Ping, Firewalld, Nmap, Icmp)

JeremyCanfield a intrebat.

Am două mașini, server1 și server2. Pe server2, opresc firewalld.

[[email protected] ~]# systemctl stop firewalld

De pe serverul1, nmap returnează Host is up.

[[email protected] ~]$ nmap -sn server2

Starting Nmap 6.40 ( http://nmap.org ) at 2020-09-02 11:27 CDT
Nmap scan report for server2 (10.17.45.13)
Host is up (0.00045s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.01 seconds

Activez firewalld pe server2.

[[email protected] ~]# systemctl start firewalld

De pe serverul1, nmap returnează Host seems down, astfel ceva cu firewalld pe server2 face ca nmap să returneze Gazda pare că nu funcționează.

[[email protected] ~]$ nmap -sn server2

Starting Nmap 6.40 ( http://nmap.org ) at 2020-09-02 11:29 CDT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.01 seconds

De pe serverul1, ping/echo/ICMP funcționează.

[[email protected] ~]$ ping -c4 server2
PING server2 (10.17.45.13) 56(84) bytes of data.
64 bytes from server2 (10.17.45.13): icmp_seq=1 ttl=64 time=0.436 ms
64 bytes from server2 (10.17.45.13): icmp_seq=2 ttl=64 time=0.388 ms
64 bytes from server2 (10.17.45.13): icmp_seq=3 ttl=64 time=0.338 ms
64 bytes from server2 (10.17.45.13): icmp_seq=4 ttl=64 time=0.390 ms

--- server2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.338/0.388/0.436/0.034 ms

Iată setările firewalld pentru public și drop zone de pe serverul2. icmp-block este gol, ceea ce înseamnă că niciun tip de ICMP nu este blocat, iar icmp-block-inversion este setat la no pentru a permite tot traficul IMCP.

[[email protected] ~]# firewall-cmd --zone=public --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno16777984
  sources:
  services: ssh dhcpv6-client
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[[email protected] ~]# firewall-cmd --zone=drop --list-all
drop
  target: DROP
  icmp-block-inversion: no
  interfaces:
  sources:
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

/var/log/firewalld nu înregistrează nimic atunci când nmap returnează Host seems down.

Comentarii

  • Nu cunosc firewalld, dar încercați să vedeți regulile iptables reale în vigoare : iptables -L -nv. Este posibil să vedeți că există o filtrare pe INPUT care nu este înregistrată. –  > Por Dom.
  • Care este distribuția și versiunea dumneavoastră de Linux? –  > Por Michael Hampton.
  • @Dom – bine gândit, dar, din păcate, avem iptables oprit și dezactivat (systemctl stop iptables, systemctl disable iptables) pe toate serverele. –  > Por JeremyCanfield.
  • @MichaelHampton – Atât serverul1, cât și serverul2 sunt CentOS 7. Iată rezultatul uname -a -> Linux server1 3.10.0-693.11.1.el7.x86_64 #1 SMP Mon Dec 4 23:52:40 UTC 2017 x86_64 x86_64 x86_64 x86_64 GNU/Linux –  > Por JeremyCanfield.
  • Firewallcmd este un frontend pentru iptables. Deci, puteți rula întotdeauna comanda de sistem pentru a vă uita la starea kernelului. Trebuie să dezactivați vechiul iptables pentru a nu avea coliziune între ambii manageri. –  > Por Dom.
1 răspunsuri
Dom

Nu cunosc firewallcmd, dar toată filtrarea în Linux se face prin iptables. Deci, firewallcmd (ca și ufw și altele) este un front-end pentru iptables.

Poți oricând să verifici regulile active în kernel prin comanda : iptables -L -nv, chiar dacă dezactivați complet serviciul iptables (deoarece firewall-ul este gestionat de firewallcmd). Dacă nu dezactivați serviciul iptables (sau netfilter-persistent pe Debian), este posibil să aveți o coliziune între doi administratori.