4

I've been reading on firewalld for about the whole morning, and I came up with the following public zone:

<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <source address="167.114.37.0/24"/>
  <source address="92.222.185.0/24"/>
  <source address="92.222.184.0/24"/>
  <source address="92.222.186.0/24"/>
  <source address="149.202.34.10/32"/>
  <service name="dhcpv6-client"/>
  <service name="http"/>
  <service name="ssh"/>
  <service name="https"/>
</zone>

The best I could figure is that this zone should only allow incoming connections on those ports/services, and provide full access to those subnets. However, when I scan my server with nmap, I get boatloads of open ports (and I am most definitely not in one of the whitelisted subnets).

PORT      STATE    SERVICE
1/tcp     open     tcpmux
3/tcp     open     compressnet
4/tcp     open     unknown
6/tcp     open     unknown
7/tcp     open     echo
9/tcp     open     discard
13/tcp    open     daytime
17/tcp    open     qotd
19/tcp    open     chargen
20/tcp    open     ftp-data
21/tcp    open     ftp
22/tcp    open     ssh
23/tcp    open     telnet
24/tcp    open     priv-mail
25/tcp    filtered smtp
26/tcp    open     rsftp
30/tcp    open     unknown
32/tcp    open     unknown
33/tcp    open     dsp
37/tcp    open     time
42/tcp    open     nameserver
43/tcp    open     whois
49/tcp    open     tacacs
53/tcp    open     domain
70/tcp    open     gopher
79/tcp    open     finger
80/tcp    closed   http
81/tcp    open     hosts2-ns
82/tcp    open     xfer
83/tcp    open     mit-ml-dev
84/tcp    open     ctf
85/tcp    open     mit-ml-dev
88/tcp    open     kerberos-sec
89/tcp    open     su-mit-tg
90/tcp    open     dnsix
99/tcp    open     metagram
100/tcp   open     newacct
106/tcp   open     pop3pw
109/tcp   open     pop2
110/tcp   open     pop3
111/tcp   open     rpcbind
113/tcp   open     ident
119/tcp   open     nntp
125/tcp   open     locus-map
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn

... the list goes on, I thought I'd stop there. What am I missing here?

EDIT If I try to access one of those open or filtered ports, say with curl, I get the following

$ curl myserver.example.com:125
curl: (7) Failed to connect to myserver.example.com port 125: Operation timed out

while I correctly get connection refused when I try to access one of the closed ports.

2
  • 2
    That nmap output is plainly bogus. Try the scan again from another location which uses a different ISP. Mar 31, 2016 at 18:38
  • I get indeed differenti results. Care to elaborate?
    – Morpheu5
    Apr 1, 2016 at 5:40

1 Answer 1

0

Probably you have an intermediate router between your test computer and the server. In such a case it's the router who confuses nmap by sending fake replies, maybe as a nuance of NAT implementation. If I'm correct, you will get similar results if you scan any random IP from the computer.

1
  • Unfortunately that's not the case. I have however noticed that there is an intermediate node (in the traceroute) that pings very slowly, could that be the issue?
    – Morpheu5
    Apr 7, 2016 at 21:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .