We see more and more SSDP 'scan' in our network (coming from outside
into our AS). Of course our client have open vulnerables boxes (last one
is an enterprise class Synology with all defaults ports open:-)) which
could be used as a reflection SSDP client.
As SSDP is used with PnP for local LAN service discovery, we are
thinking of:
1) educate our client (take a lot of time)
2) filter incoming SSDP packets (UDP port 1900 at least) in our bgp border
We see option 2 as a good action to remove our autonomous systeme from
potential sources of DDOS SSDP source toward the Internet.
Of course this might (very few chance) open others problems with clients
which use this port as an obfuscation port, but anyhow it would not be a
good idea as it is a registered IANA port.
We could think of filtering also incoming port 5000 (UPnP), but it is
the default port that Synology decide to use (WHY??? so many trojan use
this) for the DSM login into the UI.
Its always a bad idea to do packet filtering at your bgp border.
All packet filtering should be done as close to the customer as possible, preferably at the customer's home/office broadband gateway router device.
I don't know why the default configuration of a broadband gateway router would allow unsolicited internet-to-lan packets. Doing the filtering on the customer's broadband gateway router, enables individual customer configuration changes, i.e. in the unlikely event they use those UDP/TCP ports for something else.
Connecting "naked" consumer or enterprise LANs, i.e., a Synology NAS or most other things, directly to the internet without a gateway device is usually a bad idea. Naked LAN connections can be Ok in some situations, with proper configuration, but not by default.
Although somewhat controversal, since 2003 I think ISPs should have some default filters at the customer-edge which can be removed at an individual customer's request.
But no default packet filters at an ISP's BGP-edge, i.e., customer or upstream/downstream ISP bgp connections. It just breaks too many things, in weird difficult to diagnose ways.
Looking back at logs for VoIP calls over the past week (we are a small B2B telco), I see a fair number of RTP streams originating from UDP port 1900 on the customer side. Such filtering at the provider edge would have caused one way audio on these calls
Blocking common abuse ports by default at the $customer CPE has it's
positive benefits. Then allowing $customer to request port blocking
removed if necessary. (Require $customer to know what they are doing
before approving unblocking port)
If your edge ingress ACLs are not 100% in sync all the time, you will inevitably have Really Weird Stuff happen that will end up taking forever to diagnose.
You will eventually end up closing off a port that something else needs to work properly, and now you have to figure out how to resolve that.
Packet filtering is more computationally taxing than just routing is. Your edge equipment is likely going to be built for maximum routing efficiency. Trying to bite off too much filtering there increases your risk of legit traffic being tossed on the floor.
If your edge ingress ACLs are not 100% in sync all the time, you will inevitably have Really Weird Stuff happen that will end up taking forever to diagnose.
You will eventually end up closing off a port that something else needs to work properly, and now you have to figure out how to resolve that.
Packet filtering is more computationally taxing than just routing is. Your edge equipment is likely going to be built for maximum routing efficiency. Trying to bite off too much filtering there increases your risk of legit traffic being tossed on the floor.
Not necessarily disagreeing with your posits here, but, empirically speaking, we've had ACLs for stuff like this for years without any incidents or consternation.
And we are careful to ensure that any updates are pushed to all edge ingresses.
BGP-edge filters don't help with customer-to-customer packets within the same ISP BGP autonomous area. So you would need CPE customer-edge filters anyway. A small ISP might be able to handle individual customer filters on their backbone routers, but that way leads to insane network engineers.
See Barry Greene's page for the list of all the pro's & con's of different alternatives. There are very few new ideas, just new people rediscovering old ideas.
If your edge ingress ACLs are not 100% in sync all the time, you will inevitably have Really Weird Stuff happen that will end up taking forever to diagnose.
You may at some cases have hard to troubleshoot issues, which is true
for everything, even when perfectly configured, because software is
not perfect. However choosing to do iACL is still something many
networks choose to do, because the upside is worth the complexity to
them.
Packet filtering is more computationally taxing than just routing is. Your edge equipment is likely going to be built for maximum routing efficiency. Trying to bite off too much filtering there increases your risk of legit traffic being tossed on the floor.
Depends on implementation, on some implementations it is zero-cost on
some it is not. On most implementations it's very cheap, particularly
compared to say uRPF. It seems your position is 'i don't know how ACL
works on my platforms and i don't trust myself to write ACL, so i
should not do them', which is perfectly valid position under those
constrains, but other networks have other constrains under which it is
no longer valid proposal to omit doing iACL.
I would encourage networks to continue deploying iACL and consider it
BCP. iACL removes attack surface and protects you from host of known
and unknown SIRT issues.
I'm working with Level3 on a similar problem. They filter both UDP and TCP port 1900 on our peer to them. This is blocking all connections that randomly use ephemeral tcp port 1900.
They are refusing to remove the tcp port 1900 filter without dispensation from the DDoS security gods. I understand blocking UDP 1900, what is the purpose of Level3 filtering tcp port 1900?
Hey Tom,
> If your edge ingress ACLs are not 100% in sync all the time, you will inevitably have Really Weird Stuff happen that will end up taking forever to diagnose.
You may at some cases have hard to troubleshoot issues, which is true
for everything, even when perfectly configured, because software is
not perfect. However choosing to do iACL is still something many
networks choose to do, because the upside is worth the complexity to
them.
> Packet filtering is more computationally taxing than just routing is. Your edge equipment is likely going to be built for maximum routing efficiency. Trying to bite off too much filtering there increases your risk of legit traffic being tossed on the floor.
Depends on implementation, on some implementations it is zero-cost on
some it is not. On most implementations it's very cheap, particularly
compared to say uRPF. It seems your position is 'i don't know how ACL
works on my platforms and i don't trust myself to write ACL, so i
should not do them', which is perfectly valid position under those
constrains, but other networks have other constrains under which it is
no longer valid proposal to omit doing iACL.
I would encourage networks to continue deploying iACL and consider it
BCP. iACL removes attack surface and protects you from host of known
and unknown SIRT issues.
They are refusing to remove the tcp port 1900 filter without dispensation from the DDoS security gods. I understand blocking UDP 1900, what is the purpose of Level3 filtering tcp port 1900?
I ran in to this years ago with the NIPR to Internet gateway at Pearl. They were filtering about 100 TCP ports in the 1024 to 5000 range because they were commonly used for malware C&C. They insisted they were only blocking destination ports… Didn’t quite get the concept that the source port on a packet traveling one way becomes the destination port on the return packet, or that 1024 to 5000 were common ephemeral source ports for both Windows and a number of firewall products. The idea of filtering only on syn-not-ack packets also failed to make contact in their craniums.
Good luck with Level3. The folks at Pearl still hadn’t figured it out years later when I changed jobs.
They are both port 1900 (that is, they have a 1900 in them -- they also probably block TCP/UDP 19000 bidirectionally as well, since that has a "1900" in it -- they likely also tried to block TCP/UDP 190000 as well, but for some reason even through that also has "1900" in it the firewall would not accept it as a 16-bit port number, so they submitted a bug report to the vendor and closed the ticket).
In short, never ascribe to malice that which can be oh so easily and correctly attributed to ignorance, stupidity (incurable ignorance) and incompetence.
Besides, the "Internet" package that you purchased did not include that channel. If you wish to receive channels 1900 and 19000 they are available as an add-on feature pack.
