Force 200, with 4.5.6 in NAT MODE.
Why I have the 5000 TCP port open on the outside world?
I know that is a UPnP port, but it should not be open on the outside world.
With the way upnp works, it is expected to have a world reachable port available. What is not expected is for you to not block upnp from leaving your network or allowing it in to your network.
Well… as you read on GRC.com , he suggests to block the incoming 1900 udp and 5000 tcp incoming… should I do it?
I already block on the whole network, the 1900/udp IN.
I am not familiar with GRC.com and their view on things so I wont make a judgment save be careful of the advise you take as if your are acting as an ISP you are bound to some net neutrality regulations that preclude any advise given by anyone on the internet.
If your not using or allowing upnp, then it should be disabled in the APs and SMs. This is a gateway protocol for home networks to allow devices and applications to puch holes in a firewall/nat system to allow access from outside the gateway. This protocol should not be running on your production network and will cause headaches with users whom are trying to host services on a NAT’d connection.
I know that upnp is, my only concern is why do we have an open port from the outside.
In the past we have some bugged impelementations of upnp that allowed external users to modify the port forwarding part.
I can, as ISP, filter incoming ports on the whole network (telling the users in the user contract of internet access).
Currently we filter the 1900 udp in with no issue, and I am wondering if the 5000 tcp open from the outside world can be a security concern.
Simply speaking any allowed inbound port is a security concern.
If you are using a good network model where you have your customer network (vlan) completely separate from your management network and you are not routing between network these networks, then it is only a concern if the unwanted port is also open on the management network. You still shouldnt be allowing customer upnp onto your network for several reasons, the best one is it bypasses your routing control ability a good second is that it exposes your network to the clients and allows malicious software to harm your network.
What it comes down to is your network policies, what you allow on your network may not be the same as anyone elses. We do not allow residential clients to host servers on their connection, this policy is due to the support problems that this caused and also prevents a worm or trojan from sending spam from our ip address range since they can not get a lot of services past the firewalls nor gateways. This doesnt affect general net use not access to third party email systems. Yes its draconian but we are very upfront about this in our contracts.
You will need to look at your network policies and make a decision, just remember that different networks (vlans) can have different policies applied.
Don’t rely on the radio’s L2 firewall either, it’s more of a L2 colander than a L2 wall… doubt the L3 is much better but haven’t messed with it.
Well it is iptables, so it is a wall but as you know if (like anything else) it is not setup properly, which the scripts may not do, then you can stop more air with a seive.
We played with the L3 firewall a bit and again its just iptables on ip addresses, so again scripting is a possibility for error.
The empm firewalls do function enough to block some common attacks but really they are by no means meant to take on a port storm attack or a ddos attack.
As it pertains to the thread: we disable upnp on all our radios and block at the tower router all protocols that are not allowed to access our network from the clients. Example: netbios and other network discovery protocols at best can only see the AP but with SM isolation enabled all traffic between SMs must hairpin at the router and this is restricted at the router. This is helpful in that our network is not scanable from the clients but also its not diagnoseable either. Techs must set their laptop to the management vlan to be able to see anything and by default we block client side management access unless the SM has no RF connection. (This is default behavior in nat and bridged modes unless you set management access to specifically only wireless).
Inbound traffic control is done at our gateways so it is much more manageable and less clumsy.