I'm using Debian's arno-iptables-firewall and I've configured it to only allow access on the ports I need.

But nmap shows ports 1863, 5190 open. What gives? How can I interrogate those ports further?

As I said, I'm actually using arno-iptables-firewall, but as that is difficult to 'debug' (it is very complex), I'm providing an example of the problem with a very simple demo 'firewall' (without arno), which should do the job, but apparently isn't:

$ iptables -A INPUT -p tcp --destination-port 1863 -j DROP 
$ iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       tcp  --             tcp dpt:1863 

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Then nmap example.com -p1863 (from another host) still shows

host is up (0.019s latency).
1863/tcp open  msnp

Very confused.

UPDATE: OK nmap from different hosts says different things(!). nmap from somewhere else on internet (but within the same VM hosting company's network) shows the ports closed, as they should be, and telnet from these hosts does not work. But from my office ADSL connection, the ports are open and telnet connects (then gets 'closed by foreign host' shortly after).

CONCLUSION: Having now tested from 6 places on the internet, I can only reproduce this behaviour from my office ADSL. I conclude that it is an issue with local routers or our ISP. Thank you to everybody who helped me dig deeper into this issue - I learnt a lot!

  • 2
    Fire up Wireshark and look at the actual traffic. That might help you determine if what you're seeing is a false positive. It might also be useful to use tcpdump on the host you're trying to firewall to see what is happening. Commented May 17, 2013 at 13:18
  • tcpdump, then telnet to the host on port 1863, shows "3 packets captured, 3 packets received by filter, 0 packets dropped by kernel". I can't install wireshark as the server is remote, so I'm over ssh only. Commented May 17, 2013 at 13:57

4 Answers 4


In your example it looks like you're trying to config iptables which is different than Arno IPTables. Check out this link for more info on the different types of firewalls.

To see the iptables rules you're running you can type (which you're already doing):

iptables -L

To block the ports you've listed specifically in iptables, since they're both typically TCP traffic, you can use:

-A INPUT -p tcp --dport 1863 -j REJECT
-A INPUT -p tcp --dport 5190 -j REJECT 

Warning: Make sure you're leaving your access open before running something like this, but to reject all non-allowed inbound traffic with iptables you would use:


The trick with iptables is that you'll need to actually save the ruleset since anything that you type via command line is usually flushed on restart.

Arno's IPTables Firewall

For Arno IPTables you can reference the file /etc/arno-iptables-firewall/firewall.conf for additional configuration beyond the scope of the debconf dialogs. To start/stop/restart the firewall from the shell, use the command /etc/init.d/arno-iptables-firewall [start|stop|restart]

According to the firewall.conf file:

Put in the following variables the TCP/UDP ports you want to DENY(DROP) for everyone (and logged). Also use these variables if you want to log connection attempts to these ports from everyone (also trusted/full access hosts). In principle you don't need these variables, as everything is already blocked

(denied) by default, but just exists for consistency.


If Arno IP Tables is running, in theory those ports should already be blocked. Since they appear as though they're not blocked you may only be running iptables.

You can double-check the ports with netcat or try to telnet to them to see if it's a false positive from nmap.

Netcat example:

nc -z your_server 1-6000

For telnet it if the ports are blocked, they'll say:

> telnet your_server 1863
telnet: Unable to connect to remote host

If the ports are still open, then you'll see:

Connected to your_server

This will be followed by the server response.

You should be able to see what's running by typing top.

  • Thanks, it's the double-check bit I'm not clear on: how would I identify a 'false positive'? Telnet says Trying Connected to example.com so looks like it IS open? Is there a way to check Iptables for this port? Commented May 17, 2013 at 11:19

A couple of things you can look at for this.

From the host that you're protecting try

sudo netstat -tunap

which should show all network connections. Up the top there should be a set of listening TCP ports and the corresponding process which is making use of them.

from the network try

sudo nmap -sS -sV -sC -v -n [target]

to see if nmap can figure out any more about the port.

Also in general I notice that you've got the iptables input policy set to ACCEPT. I'd recommend setting it to DROP and only allowing the ports you need. It makes securing the box much easier in the long run.

  • Thanks for taking the time to help. The only relevant info to come from that nmap command is:1863/tcp open msnp? and 5190/tcp open aol?. As in, it just added ?s to it. FYI I'm not using the iptables set-up above as my firewall, I'm using arno-iptables-firewall. The set-up in the question was temporary to demonstrate the problem clearly. Commented May 17, 2013 at 13:47
  • So that indicates that the ports are open but that nmap can't identify the service running on them. Did netstat -tunap show anything useful? Commented May 17, 2013 at 14:32
  • I didn't think so, but I'm concerned about rpc.statd which is listed as listening on TCP:59061, UDP:40594, UDP:919 as I don't know what that is (or how to kill it) Commented May 17, 2013 at 14:42
  • @artfulrobot - rpc.statd is a reboot notification service used by the NFS file locking service. By default, rpc.statd will ask portmap(8) to assign it a port number, so this will vary system to system and is recommended that you assign it a permanent port number when you're configuring a firewall. You can specify that by a call parameter -p XX (where XX is a port number). More is here.
    – TildalWave
    Commented May 17, 2013 at 16:37
  • @TildalWave Thank you. Do I need it running if I'm not being an nfs server (but I am being a client)? I do not normally use nfs, but this particular server comes with some backup space made accessible by an nfs share. Commented May 17, 2013 at 16:53

A perhaps crude but rather effective way of finding a potential offending application is to use lsof.

For example: lsof -i | grep LISTEN

Look for services matching the port numbers NMAP claims are open.

Update: Guess I should mention that the command should be run as root to ensure that all open file-handles are listed!

  • That returns nothing for these ports. Commented May 17, 2013 at 12:55
  • Well, it's difficult to make absolute statements but if there are no indications of listening services on those ports it's not entirely unlikely that NMAP is reporting false positives. (Ensure that you run the command as root) Commented May 17, 2013 at 13:16
  • But why can telnet apparently connect? Commented May 17, 2013 at 13:47

Are you trying to block 1853 and 5190 outbound? If so Nmap isn't ideally suited to determine firewall rules. To truly test a firewall rule with near 100% accuracy you need to send traffic THROUGH the firewall to a known destination on the other side, as opposed to trying to scan the firewall interface/IP itself.

From the Nmap docs:

"While Nmap attempts to produce accurate results, keep in mind that all of its insights are based on packets returned by the target machines (or firewalls in front of them). Such hosts may be untrustworthy and send responses intended to confuse or mislead Nmap." (http://nmap.org/book/man-port-scanning-techniques.html)

You need a solution like IsMyPortBlocked which sends traffic from its client through the firewall and on to the cloud-based server and then back to the client, all over the specified port(s).

  • Yeah, basically that's what was happening - my router was intercepting the traffic for some bizarre reason. Commented Aug 15, 2013 at 14:32

You must log in to answer this question.

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