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. – Christoffer May 17 '13 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. – artfulrobot May 17 '13 at 13:57

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.

| improve this answer | |
  • 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? – artfulrobot May 17 '13 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.

| improve this answer | |
  • 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. – artfulrobot May 17 '13 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? – Rory McCune May 17 '13 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) – artfulrobot May 17 '13 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 May 17 '13 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. – artfulrobot May 17 '13 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!

| improve this answer | |
  • That returns nothing for these ports. – artfulrobot May 17 '13 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) – Christoffer May 17 '13 at 13:16
  • But why can telnet apparently connect? – artfulrobot May 17 '13 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).

| improve this answer | |
  • Yeah, basically that's what was happening - my router was intercepting the traffic for some bizarre reason. – artfulrobot Aug 15 '13 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.