Whirlpool

Anyone know why a DG384GT might be accepting connections on TCP port 5190?

Its not being deliberately forwarded to any machine on the LAN, and doesn't appear on the firewall rules page.
The modem actually seems to be accepting the connections itself.

Anyone got any clues as to why this might be?

Port 5190 (TCP and UDP) is the default used by ICQ, the popular Instant Messenging system.

Yes, I'm aware of that.

My question is directed at the fact that I don't use AIM, and none of my PCs have this port open.
It appears that the modem is accepting these connections itself.

Also, there is no mention of this port in my firewall rules, so it should be blocked by default.

It strongly looks like a security hole in the Netgear.

wrong router

If you telnet into it, you should see that /usr/sbin/reaim is running. It is probably an ALG for AIM/ICQ. I agree it's annoying to have that port open though.

So I'll be wanting to kill off that process then.

Its not just annoying - its downright deceptive: my firewall rules are explicitly blocking everything apart from those ports I want forwarded.

And AIM/ICQ is emphatically not in that list. So my modem should be blocking that port, not accepting connections to it.

And anyway, what does this reaim process do with the connection once it has accepted it (apart from open an unwanted security hole in my modem)?

yogi writes...

And anyway, what does this reaim process do with the connection once it has accepted it (apart from open an unwanted security hole in my modem)?

ReAIM is listed on SourceForge.net as a transparently AIM proxy. Looking further into the setup page it also appears to transparently proxy MSN messenger too. According to that page you may also find some other ports open too:

iptables -A INPUT -i ppp0 -p tcp --dport 1863:1864 -j ACCEPT
iptables -A INPUT -i ppp0 -p tcp --dport 4443 -j ACCEPT
iptables -A INPUT -i ppp0 -p tcp --dport 5566 -j ACCEPT
iptables -A INPUT -i ppp0 -p tcp --dport 40000:40099 -j ACCEPT

I've taken a particular interest in this router as I'm considering buying one of the DG834 series^*. I'll be interested to know whether you can configure it to a block all by default firewall. I was pointed to a page on the DG834 that has me thinking otherwise.

I'd appreciate it if you can take the time to an iptables listing that includes interface information as the page at www.suburbia.com.au/~dan neglected to do this. You could also use netstat in the device to find out what ports are being listened on. The commands I would run if I had that router are as follows:

# netstat -lntuw
# iptables -t nat -nvL
# iptables -t mangle -nvL
# iptables -t filter -nvL

You may find it more concerning that ReAIM does not appear to be maintained and has not been updated since March 26 2003 according to the project information. This fact alone would give me motivation to gut the DG834 firewall and cripple reaim if I do buy one.

bambos writes...

You may find it more concerning that ReAIM does not appear to be maintained and has not been updated since March 26 2003 according to the project information.

I do find that concerning, especially given this quote off the homepage of the product: "Current Status The current code is alpha quality. This means that it works for me, but has many rough edges and plenty of things still to finish and properly design."

Hardly confidence inspiring, is it?

You could also use netstat in the device to find out what ports are being listened on.

netstat is not supported on the busybox implementation for this modem.

iptables -t nat -nvL

Chain PREROUTING (policy ACCEPT 4022 packets, 477K bytes)
pkts bytes target prot opt in out source destination
4189 488K REAIM_PRE all -- * * 0.0.0.0/0 0.0.0.0/0
156 10195 DNS udp -- br0 * 0.0.0.0/0 192.168.0.1 udp dpt:53
0 0 DROP all -- ppp0 * 0.0.0.0/0 !xxx.xxx.xxx.xxx
0 0 DNAT udp -- br0 * 0.0.0.0/0 192.168.0.1 udp dpt:53 to:10.112.112.112
0 0 DNAT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5190 to:1.0.0.0:5190

Chain POSTROUTING (policy ACCEPT 578 packets, 45894 bytes)
pkts bytes target prot opt in out source destination
1600 96112 MASQUERADE all -- * ppp0 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 571 packets, 45590 bytes)
pkts bytes target prot opt in out source destination

Chain DNS (1 references)
pkts bytes target prot opt in out source destination
156 10195 DNAT all -- * * 0.0.0.0/0 192.168.0.1 to:xxx.xxx.xxx.xxx

Chain REAIM_PRE (1 references)
pkts bytes target prot opt in out source destination
1 60 REDIRECT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1863 redir ports 1863
0 0 REDIRECT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5190 redir ports 5190

# iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 196K packets, 138M bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 5228 packets, 612K bytes)
pkts bytes target prot opt in out source destination

# iptables -t filter -nvL
Chain INPUT (policy DROP 1121 packets, 263K bytes)
pkts bytes target prot opt in out source destination
4 208 DROP tcp -- !ppp0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp flags:!0x16/0x02
3880 232K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2962 645K REAIM_IN all -- * * 0.0.0.0/0 0.0.0.0/0
526 234K INPUT_UDP udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0
591 28520 INPUT_TCP tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0
1834 381K ACCEPT all -- !ppp0 * 0.0.0.0/0 0.0.0.0/0 state NEW

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
\ 2805 165K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
185K 137M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 FORWARD_UDP udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0
26 1272 FORWARD_TCP tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0
3561 334K ACCEPT all -- !ppp0 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 5205 packets, 595K bytes)
pkts bytes target prot opt in out source destination
6 3456 ACCEPT icmp -- * br0 0.0.0.0/0 0.0.0.0/0
0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID

Chain ALGS (5 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD_TCP (1 references)
pkts bytes target prot opt in out source destination
0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 389,522,1503,1731
0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:6701
0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80
0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 6901,1863,6891,1503,7001
26 1272 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD_UDP (1 references)
pkts bytes target prot opt in out source destination
0 0 ALGS udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 6901,5060
0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0

Chain INPUT_TCP (1 references)
pkts bytes target prot opt in out source destination
9 432 DROP tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 multiport dports 23,80,32764
582 28088 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0

Chain INPUT_UDP (1 references)
pkts bytes target prot opt in out source destination
526 234K RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0

Chain REAIM_IN (1 references)
pkts bytes target prot opt in out source destination
1 60 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1863:1864
0 0 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5566
0 0 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5190
0 0 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4443
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:40000:40099
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1864
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5566
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5190
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4443
0 0 ACCEPT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:40000:41000

NOTE: I have filtered the details of my firewall rules. Apologies if my filtering wasn't perfect...

So if I understand correctly, I have 4 tcp ports and 1000 udp ports open against my will and in direct contradiction to my explicit firewall rules.

yogi writes...

netstat is not supported on the busybox implementation for this modem.

It's strange that they left netstat out when it's actually in the source code of the router. Of course that's not the only thing that's strange when you look at the way they configured the firewall.

Chain PREROUTING (policy ACCEPT 4022 packets, 477K bytes)
pkts bytes target prot opt in out source destination
4189 488K REAIM_PRE all -- * * 0.0.0.0/0 0.0.0.0/0
156 10195 DNS udp -- br0 * 0.0.0.0/0 192.168.0.1 udp dpt:53
0 0 DROP all -- ppp0 * 0.0.0.0/0 !xxx.xxx.xxx.xxx
0 0 DNAT udp -- br0 * 0.0.0.0/0 192.168.0.1 udp dpt:53 to:10.112.112.112
0 0 DNAT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5190 to:1.0.0.0:5190

The PREROUTING chain of the nat table generally isn't meant to be used for any filtering. Yet the output above shows that rules have been added to this chain when they should have been added to either the INPUT, FORWARD or OUTPUT chains of the filter table.

# iptables -t filter -nvL
Chain INPUT (policy DROP 1121 packets, 263K bytes)
pkts bytes target prot opt in out source destination
4 208 DROP tcp -- !ppp0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp flags:!0x16/0x02
3880 232K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2962 645K REAIM_IN all -- * * 0.0.0.0/0 0.0.0.0/0

The filter table shows that only packets dropped before it hits the REAIM_IN chain is NEW TCP packets from the internal interfaces that are not SYN packets. The following part from the REAIM_IN is accepted by the router from the external interface:

0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:40000:40099
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1864
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5566
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5190
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4443
0 0 ACCEPT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:40000:41000

In total there's 104 TCP ports and 1001 UDP ports alone that could potentially be open depending on the state of ReAIM. You were nearly spot on in terms of the number of ports that have not been blocked.

I certainly wouldn't like to have a firewall like that on my router. Although there's always the opportunity for somebody to customise the firmware as the source is available.

Okay, so presumably if I kill off the reaim process, I will be circumventing the problems (which seem to be fairly wide-reaching).

A bit of a pain to have to telnet into the modem every time I restart it just so I can switch off a security hole that shouldn't be there...

And if the firmware were modified to not have reaim activated, or at least not without being user-configured to be active, it might stand up to scrutiny.

Thanks for your assistance bambos - I know a fair amount about networks, but not much about iptables, so I was struggling a bit to make sense of it all.

yogi writes...

A bit of a pain to have to telnet into the modem every time I restart it just so I can switch off a security hole that shouldn't be there...

Try writing a firewall rule that explicitly blocks the port 5190 - works for the 834G so maybe worth a go on the GT. Note, 834G also leaves 1864, 4443, 5566, 6881 and 400xx open, but similarly all can be closed by explicit rules.

There have been many complaints on the netgear forum pages, ...

It does look like adding an explicit block for each port works. Not sure where you got port 6881 from, but you can block it if you don't like file-sharing...

I have opened a support request with netgear about this, and so far they have asked me to provide my WAN IP and modem admin password, and to enable remote access.

Yeah, right....like I'm going to do that.

I've politely suggested they try it out on their own hardware rather than opening even more security holes in my modem. Their suggestion that something on my LAN might be using uPNP on these ports rather suggests they are currently a bit clueless on this subject. If they'd properly read what I wrote to them (and understood it) they'd know that they don't need access to my modem in order to look into the problem.

I'm waiting for their response. Perhaps other people should raise technical support requests with them too. Might make them more responsive.

yogi writes...

It does look like adding an explicit block for each port works. Not sure where you got port 6881 from, but you can block it if you don't like file-sharing...

My guess is he may have meant TCP port 6891. It's the port that MSN uses for file transfers and is easy to confuse with port 6881.

Chain FORWARD_TCP (1 references)
pkts bytes target prot opt in out source destination
0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 389,522,1503,1731
0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:6701
0 0 ALGS tcp -- * * 0.0.0.0/0 0Chain FORWARD_TCP (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 389,522,1503,1720,1731
2 0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:6701
3 0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80
4 0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 6901,1863,6891,1503,7001.0.0.0/0 tcp spt:80
0 0 ALGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 6901,1863,6891,1503,7001
26 1272 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0

You can find that port listed in the FORWARD_TCP chain that is used in the inbuilt FORWARD chain. In addition to TCP port 6891 you'll notice other ports are forwarded too. It's odd that the rule that uses the FORWARD_TCP chain as a target is after the rule that accepts ESTABLISHED and RELATED forwarded traffic.

I've never needed a rule to accept NEW or INVALID traffic in my FORWARD chain for MSN file transfers to work for example. The more I look at the firewall of the DG834 series the more I dislike it. What could have been implemented in a more elegant manner just looks like an insecure mess to me.

Are there any DG834 series owners around that have considered developing an alternative firmware using the firmware source?

bambos writes...

My guess is he may have meant TCP port 6891. It's the port that MSN uses for file transfers and is easy to confuse with port 6881.

Oops - although I did mean 6881, it isn't a port that is left open by default. Instead it is a port I have explicitly opened, for Azureus. I failed to read the action column as I copied the port numbers in my original post.

So I've spoken to Netgear about this issue.

They told me that it is a requirement for customers in the USA to have these ports open, as they need to use them over there.
That's the most pathetic excuse for a security hole I've ever heard.

They accept that it is a problem in the firmware and the workaround offered is to explicitly close all the open ports using the firewall (despite the fact that you wouldn't know they are open).
Note that it is also possible to telnet into the modem and kill the reaim process, but you'd have to do it after every time the modem is rebooted.

They have escalated it as a bug requiring a fix, but told me it is unlikely to happen unless they receive enough bug reports that get escalated (you have to let them ring you up and discuss it in order to get it escalated).
They wouldn't say how many escalated bug reports would be needed in order to get it fixed, but I got the impression that 100 might be enough.
The fix suggested in the bug report is to have the option of enabling or disabling ReAIM through the web interface, so you get the choice of whether all these ports are open or not.

So if anyone would like this to be fixed, I suggest you all file bug reports.

I can telnet in, just would like to know how to kill this process thanks the re aim one

just in case anyone else wants to know how to kill re-aim

you need to use telnet or use putty.

you also need to type this in first in your browser

192.168.2.1/setup.cgi?todo=debug

if your using default then this would be 192.168.0.1/setup.cgi?todo=debug

ps -aux | grep aim

then look at start number at left hand side and then type kill + the first number you see at left

you will need to do this everytime you hard reboot router or it resyncs with dslam etc.

if you use icq though or aim or anything else that uses port 5190 then use 5191 or you could just reopen 5190 if router lets you as its more than likely just gonna tell you that port is already in use or rather already has a rule.

dontasciime writes...

then look at start number at left hand side and then type kill + the first number you see at left

The service will be restarted after a power cycle.