DD-WRT uPNP listening on external interface TCP port 5431?

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware
Goto page 1, 2  Next
Author Message
alyandon
DD-WRT Novice


Joined: 27 Aug 2006
Posts: 10

PostPosted: Sun Aug 27, 2006 20:34    Post subject: DD-WRT uPNP listening on external interface TCP port 5431? Reply with quote
Firmware: DD-WRT v23 SP1 Final (05/16/06) std on WRT-54G v2

A friend of mine was running a nmap sweep against my network and came up with an external accessible service I couldn't identify. When he connected and sent an HTTP request (GET / HTTP/1.0) the service responded with:

Code:

HTTP/1.1 404 Not Found
DATE: Sun, 27 Aug 2006 15:31:12 GMT
Connection: Keep-Alive
Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0
Content-Length: 0
Content-Type: text/xml; charset="utf-8"
EXT:


Noticing the UPNP and BRCM400 I immediately suspected the UPNP service on the router was listening on the external interface. When I connect to the same port via the router's internal ip address and send the same request I get the exact same response. When the UPNP service is disabled there is no response.

What is going on here? How do I disable this from listening on the WAN interface?


Last edited by alyandon on Mon Aug 28, 2006 23:33; edited 2 times in total
Sponsor
colindean
DD-WRT User


Joined: 08 Jun 2006
Posts: 58
Location: Pittsburgh, PA

PostPosted: Mon Aug 28, 2006 2:30    Post subject: Reply with quote
Confirmed, port 5431 is accessible internally and externally on mine, too.

It's the port used for Universal Plug and Play. However, it seems odd that this service is listening on the WAN IP in addition to the LAN/WLAN.

Working as in intended or bug?

_________________
Tank(WRT54G) Foney(WRT54GS) Susie (WL-500W)
Mi parolas Esperanton.
alyandon
DD-WRT Novice


Joined: 27 Aug 2006
Posts: 10

PostPosted: Mon Aug 28, 2006 2:54    Post subject: Reply with quote
I can't think of a single reason why the UPnp service would need to listen on the WAN side of the router.

I used the following iptables command to block it for the time being:

iptables -A INPUT -i vlan1 -p tcp --dport 5431 -j DROP

Note that "vlan1" is the alias of my WAN interface. Yours may be different.
cyberde
DD-WRT Guru


Joined: 07 Jun 2006
Posts: 1488
Location: the Netherlands

PostPosted: Mon Aug 28, 2006 17:01    Post subject: Reply with quote
I'm using 08/28/06 v24 build and ran a ShieldsUp! test, result attached.


stealth.PNG
 Description:
 Filesize:  9.44 KB
 Viewed:  14465 Time(s)

stealth.PNG



_________________
Firmware: DD-WRT v24-sp2 (latest available) mega
WRT320N

Donater
rkloost
DD-WRT Guru


Joined: 11 Jul 2006
Posts: 1247
Location: Nijmegen, The Netherlands

PostPosted: Mon Aug 28, 2006 21:01    Post subject: Re: DD-WRT uPNP listening on external interface TCP port 543 Reply with quote
alyandon wrote:
Firmware: DD-WRT v23 SP1 Final (05/16/06) std on WRT-54G v2

A friend of mine was running a nmap sweep against my network and came up with an external accessible service I couldn't identify. When he connected and sent an HTTP request (GET / HTTP/1.0) the service responded with:

Code:

HTTP/1.1 404 Not Found
DATE: Sun, 27 Aug 2006 15:31:12 GMT
Connection: Keep-Alive
Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0
Content-Length: 0
Content-Type: text/xml; charset="utf-8"
EXT:


Noticing the UPNP and BRCM400 I immediately suspected some service on the router was listening on the external interface. When I connect to the same port via the router's internal ip address and send the same request I get the exact same response.

What is going on here? How do I disable this from listening on the WAN interface?


It seems like an ordinary http-server answer.

Do you have remote administration configured?
If yes, logical you see something like this.

Do this from the inside and check the headers...
Disable upnp, and try again...

Regards,
Ruud

_________________
Firmware: DD-WRT v24 SP1 std
1xWRT150Nv1.1
2xWRT54GLv1.1
2xWRT54GSv1.0
1xWRT54Gv2

In need of WRT54GS <= v3 EU/UK for firmware-debugging purposes. Buffalo's are welcome too! PM me if you have a spare one.
alyandon
DD-WRT Novice


Joined: 27 Aug 2006
Posts: 10

PostPosted: Mon Aug 28, 2006 23:04    Post subject: Re: DD-WRT uPNP listening on external interface TCP port 543 Reply with quote
rkloost wrote:

It seems like an ordinary http-server answer.

Do you have remote administration configured?
If yes, logical you see something like this.

Do this from the inside and check the headers...
Disable upnp, and try again...


With UPNP service activated:

Code:

~ # netstat -lt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address      Foreign Address     State
tcp        0      0 *:www                   *:*            LISTEN
tcp        0      0 *:domain                *:*            LISTEN
tcp        0      0 *:ssh                   *:*            LISTEN
tcp        0      0 *:5431                  *:*            LISTEN
tcp        0      0 *:telnet                *:*            LISTEN


UPNP Deactivated:

Code:

~ # netstat -lt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address      Foreign Address     State
tcp        0      0 *:www                   *:*            LISTEN
tcp        0      0 *:domain                *:*            LISTEN
tcp        0      0 *:ssh                   *:*            LISTEN
tcp        0      0 *:telnet                *:*            LISTEN


Dump of iptables before I explicitly block 5431 on the WAN interface.

Code:

~ # iptables --list --numeric | head
Chain INPUT (policy ACCEPT)
target     prot opt source          destination
DROP       tcp  --  0.0.0.0/0       0.0.0.0/0           tcp dpt:8080
DROP       tcp  --  0.0.0.0/0       0.0.0.0/0           tcp dpt:80
DROP       tcp  --  0.0.0.0/0       0.0.0.0/0           tcp dpt:443
DROP       tcp  --  0.0.0.0/0       0.0.0.0/0           tcp dpt:23
DROP       tcp  --  0.0.0.0/0       0.0.0.0/0           tcp dpt:69
DROP       tcp  --  0.0.0.0/0       0.0.0.0/0           tcp dpt:22


Notice that internal services are blocked via firewall (instead of simply listening on the LAN/WLAN interface only). Following that logic, it seems to me that DD-WRT should probably be inserting a rule to block tcp 5431 for me when UPNP is enabled but isn't.
rkloost
DD-WRT Guru


Joined: 11 Jul 2006
Posts: 1247
Location: Nijmegen, The Netherlands

PostPosted: Mon Aug 28, 2006 23:20    Post subject: Reply with quote
you're maybe right... but did'nt give an answer to my question...

Default policy in DD-WRT is drop connections...

What you're seeing are the listening ports...

But if the ipfilter is configured to drop inbound traffic (default stance...)

It shows only that the upnp is listening.... not that the connections or the traffic reach
your upnp daemon...

iptables is a lowlevel filter that "comes" before the actual listening port...

Please do a manual get-request on the inside...
before and after disabling upnp...

Most important to me:
You did'nt answer:
Quote:
Do you have remote administration configured?

Regards,
Ruud

_________________
Firmware: DD-WRT v24 SP1 std
1xWRT150Nv1.1
2xWRT54GLv1.1
2xWRT54GSv1.0
1xWRT54Gv2

In need of WRT54GS <= v3 EU/UK for firmware-debugging purposes. Buffalo's are welcome too! PM me if you have a spare one.
alyandon
DD-WRT Novice


Joined: 27 Aug 2006
Posts: 10

PostPosted: Mon Aug 28, 2006 23:31    Post subject: Reply with quote
Any connection attempt to port 5431 is going to fail when nothing is listening (the case when upnp service is disabled as shown by netstat -lt). I had already established that the upnp service was the culprit (listening on port 5431 when enabled) and was accepting connections on both internal and external interfaces.

Sorry if I didn't make that clear in my original post. I'll try and clarify it. And no, I do not have any of the remote admin features enabled.
rkloost
DD-WRT Guru


Joined: 11 Jul 2006
Posts: 1247
Location: Nijmegen, The Netherlands

PostPosted: Mon Aug 28, 2006 23:47    Post subject: Reply with quote
Did the probe with nmap show a listening port 5431 give an answer?

You're assumption that if the ports is listening it willl answer is wrong!

iptables does something like this:

listening port
|
iptables
|
incoming request

iptables sits in between...

So if there is no explicit allow... the traffic will not reach the port.

Did you check your data with log enebled, loglevel high, all on?
With logging redirected to a syslogd? kiwisyslog on a loghost will do...

Regards,
Ruud

_________________
Firmware: DD-WRT v24 SP1 std
1xWRT150Nv1.1
2xWRT54GLv1.1
2xWRT54GSv1.0
1xWRT54Gv2

In need of WRT54GS <= v3 EU/UK for firmware-debugging purposes. Buffalo's are welcome too! PM me if you have a spare one.
alyandon
DD-WRT Novice


Joined: 27 Aug 2006
Posts: 10

PostPosted: Tue Aug 29, 2006 0:15    Post subject: Reply with quote
We seem to be talking past each other so I'll attempt to be as clear as possible. My apologies if my responses come off as snarky.

rkloost wrote:
Did the probe with nmap show a listening port 5431 give an answer?


Yes. As I said in my original post, it was responding to external connection requests and responding exactly the same as if the connection had come from the internal interface.

Quote:

You're assumption that if the ports is listening it willl answer is wrong!


I am not making any assumptions. I have established the uPnP service (or a service associated with it since netstat -p won't work) is listening on port 5431 on the external interface (via netstat -lt). There is no corresponding entry in firewall to block an incoming request on the external interface (via iptables --list --numeric and examining the INPUT chain) to that service.

Quote:

So if there is no explicit allow... the traffic will not reach the port.


I think this is the root cause of our misunderstanding. If you look at the output from iptables above the first line has "Chain INPUT (policy ACCEPT)". That means the default policy is to accept packets, not reject. Since the firewall isn't rejecting anything, connection attempts sail right on through to the service unless it is blocked by an explicit rule. The same default policy is applied to the FORWARD and OUTPUT chains as well.

Considering that the firewall is configured to accept packets on the INPUT chain and there are rules explicitly present in the INPUT chain to block access to internal services (ie: httpd, ssh, etc) from the internet, it looks very much to me that the default policy choice is intentional and the only bug here is an oversight to insert a rule to block port 5431 when uPnP is enabled. This is, of course, speculation on my part but I don't see a more reasonable interpretation at the moment.
rkloost
DD-WRT Guru


Joined: 11 Jul 2006
Posts: 1247
Location: Nijmegen, The Netherlands

PostPosted: Tue Aug 29, 2006 7:23    Post subject: Reply with quote
LS,

I had to implement a special configuration on my router to allow answers to
interim dhcp-renews

Quote:
~ # iptables -v -L INPUT --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 230 76261 ACCEPT udp -- vlan1 any anywhere anywhere udp spt:bootps dpt:bootpc
2 16782 2219K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
3 0 0 DROP udp -- vlan1 any anywhere anywhere udp dpt:route
4 0 0 DROP udp -- br0 any anywhere anywhere udp dpt:route
5 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:route
6 15 876 logdrop icmp -- vlan1 any anywhere anywhere
7 0 0 logdrop igmp -- any any anywhere anywhere
8 0 0 ACCEPT all -- lo any anywhere anywhere state NEW
9 761 84530 logaccept all -- br0 any anywhere anywhere state NEW
10 434 65868 logdrop all -- any any anywhere anywhere
~ #


The first line is result of:
Quote:
iptables -I INPUT -p UDP -i vlan1 --dport 68 --sport 67 -j ACCEPT


So I don't see in the default an accept rule for port 5431

Regards,
Ruud

_________________
Firmware: DD-WRT v24 SP1 std
1xWRT150Nv1.1
2xWRT54GLv1.1
2xWRT54GSv1.0
1xWRT54Gv2

In need of WRT54GS <= v3 EU/UK for firmware-debugging purposes. Buffalo's are welcome too! PM me if you have a spare one.
cyberde
DD-WRT Guru


Joined: 07 Jun 2006
Posts: 1488
Location: the Netherlands

PostPosted: Tue Aug 29, 2006 17:36    Post subject: Reply with quote
How did you test your external port?

It's normal that you can connect to that specific port if you tested it from inside your LAN. Even when you try to connect to your external ip from inside your LAN.

Try something like [url=https://www.grc.com/x/ne.dll?bh0bkyd2]ShieldsUp[url] like I did, and choose for a specific port range.

I also agree with rkloost (not just because he's also dutch Wink), there's just no way the port is forwarded without there being an IPTables rule for it.

_________________
Firmware: DD-WRT v24-sp2 (latest available) mega
WRT320N

Donater
alyandon
DD-WRT Novice


Joined: 27 Aug 2006
Posts: 10

PostPosted: Wed Aug 30, 2006 0:04    Post subject: Reply with quote
cyberde wrote:
How did you test your external port?


Please read (or re-read) my original post for the relevant information.

Quote:

It's normal that you can connect to that specific port if you tested it from inside your LAN. Even when you try to connect to your external ip from inside your LAN.


I'm well aware of how the router will loopback connection requests destined for the external ip that come from the internal network.

Quote:

Try something like [url=https://www.grc.com/x/ne.dll?bh0bkyd2]ShieldsUp[url] like I did, and choose for a specific port range.


I've already demonstrated
1) the service listens on the external interface (netstat -lt)
2) the service isn't blocked by iptables due to a combination a default accept policy on the INPUT chain + no explicit rule blocking incoming requests (iptables --list --numeric)
3) the service responds to external connection requests (the response posted in my original post).

However, here you go:



Open means the Shields Up! site was able to establish a tcp connection to that port on my router.

Quote:

I also agree with rkloost (not just because he's also dutch Wink), there's just no way the port is forwarded without there being an IPTables rule for it.


You said "port is forwarded". This has nothing to do with port forwarding which is covered by the FORWARD chain. The uPnP service is a service that runs on the router and as such is covered by the INPUT chain. Besides guys - the first response in this thread was someone confirming exactly what I said was happening.

I realize you both are trying to help and I appreciate it but I don't understand where you've come up with this notion that the INPUT chain operating on a default accept policy will block unsolicited traffic without a rule explicitly defined to block said traffic. Please refer to the documentation at http://www.netfilter.org/ to educate yourself on default policies and especially what a default policy of accept on the INPUT chain implies.

To further prove my point that I'm not imagining things, here is a Shields Up probe of a random port on the router:



Notice that the state is "closed" and not "stealth". That is because the router actively rejected the connection request (no service running on the router on port 2222) instead of silently dropping the connection request packet. The response is entirely consistent with the input chain operating on a default accept policy.

Not unsurprisingly, if I run
Code:

iptables -A INPUT -i vlan1 -p all -j DROP

my router more or less becomes invisible to the internet at large except for port forwards defined in the FORWARD chain.

Back to the problem, the uPnP service is exposed to the internet at large in this particular firmware and I need to know how to address this permanently. Manually adding (and re-adding as the router erases and reloads the rules on virtually any configuration change) an iptables rule to block the uPnP service is a hideous work-around at best. Identifying why it isn't blocked from the internet like all the other internal router daemons (which are blocked by explicit rules) would be nice.
OPaul
DD-WRT User


Joined: 07 Jun 2006
Posts: 92
Location: North Carolina, USA

PostPosted: Wed Aug 30, 2006 0:13    Post subject: Reply with quote
I enabled UPNP on my WRT54Gv2.0 had ran ShieldsUp on port 5431, and it comes up stealthed. Firmware in signature.

--EDIT --
Oh, well once I disable the SPI firewall then the port shows up as Open. Like you said, any other port comes up Closed. Once UPNP is disabled, the port comes up closed.

I see no reason why this port should be listening on WAN port.

_________________
WRT54G v2.0 (DD-WRT v24-12548 std-nokaid_nohotspot_nostor)
alyandon
DD-WRT Novice


Joined: 27 Aug 2006
Posts: 10

PostPosted: Wed Aug 30, 2006 1:10    Post subject: Reply with quote
Thanks!! You win the prize. I guess the SPI firewall option is disabled by default in this build. When enabled, the iptables output for the INPUT chain is:

Code:

Chain INPUT (policy ACCEPT)
target     prot opt source            destination
ACCEPT     all  --  anywhere          anywhere            state RELATED,ESTABLISHED
DROP       udp  --  anywhere          anywhere            udp dpt:route
DROP       udp  --  anywhere          anywhere            udp dpt:route
ACCEPT     udp  --  anywhere          anywhere            udp dpt:route
ACCEPT     icmp --  anywhere          anywhere
ACCEPT     igmp --  anywhere          anywhere
ACCEPT     tcp  --  anywhere          anywhere            tcp dpt:auth
ACCEPT     all  --  anywhere          anywhere            state NEW
logaccept  all  --  anywhere          anywhere            state NEW
DROP       all  --  anywhere          anywhere


Note the explicit rules blocking traffic not associated with an existing connection.

Where did you acquire SP2? Is it an official build? I only see v23 SP1 on the download site.
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum