Dear Community, 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. What do you think ? Thank, best regards, -- Marcel
On Mon, 25 Mar 2019, marcel.duregards--- via NANOG wrote:
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
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.
Barry Greene has already written up a great overview, and provides links to best practices on ISP port filtering, pro & con. http://www.senki.org/exploitable-port-filtering/ My advice is consistent with Barry's, but I should I done my web research first :-)
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. On Mon, Mar 25, 2019 at 6:41 AM Tom Hill <tom@ninjabadger.net> wrote:
On 25/03/2019 09:17, Sean Donelan wrote:
Its always a bad idea to do packet filtering at your bgp border.
Wild assertion. Why?
DoS mitigation, iACLs, BGP security... I can think of lots of very sensible reasons.
-- Tom
On 3/25/19 9:08 AM, Tom Beecher wrote:
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.
On Mon, Mar 25, 2019 at 6:41 AM Tom Hill <tom@ninjabadger.net <mailto:tom@ninjabadger.net>> wrote:
On 25/03/2019 09:17, Sean Donelan wrote: > Its always a bad idea to do packet filtering at your bgp border.
Wild assertion. Why?
DoS mitigation, iACLs, BGP security... I can think of lots of very sensible reasons.
-- Tom
On Mon, 25 Mar 2019, Bryan Holloway wrote:
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.
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. -- ++ytti
"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'," That is not my position at all, but thanks. On Mon, Mar 25, 2019 at 12:43 PM Saku Ytti <saku@ytti.fi> wrote:
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.
-- ++ytti
On Mon, 25 Mar 2019, Tom Hill wrote:
On 25/03/2019 09:17, Sean Donelan wrote:
Its always a bad idea to do packet filtering at your bgp border.
Wild assertion. Why?
My mistake trying to keep it simple. I should have just posted Barry Greene's link. http://www.senki.org/exploitable-port-filtering/
On Mon, 25 Mar 2019, marcel.duregards--- via NANOG wrote:
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
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
Blocked ssdp and move on Ssdp is a horrible ddos vector Comcast and many others already block it, because is the smart and best thing to do https://www.xfinity.com/support/articles/list-of-blocked-ports On Mon, Mar 25, 2019 at 1:30 AM marcel.duregards--- via NANOG < nanog@nanog.org> wrote:
Dear Community,
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.
What do you think ?
Thank, best regards,
-- Marcel
Actually a little surprised to see port 25 blocked in both directions here along with 1080. It’s like saying here’s your network buuuuut it’s limited. Though I wouldn’t recommend spawning up 25 it’s still a legitimately used port today as alike with 1080. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
On Mar 25, 2019, at 07:13, Ca By <cb.list6@gmail.com> wrote:
Blocked ssdp and move on
Ssdp is a horrible ddos vector
Comcast and many others already block it, because is the smart and best thing to do
https://www.xfinity.com/support/articles/list-of-blocked-ports
On Mon, Mar 25, 2019 at 1:30 AM marcel.duregards--- via NANOG <nanog@nanog.org> wrote: Dear Community,
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.
What do you think ?
Thank, best regards,
-- Marcel
On Mon, Mar 25, 2019 at 5:33 AM Jason Hellenthal <jhellenthal@dataix.net> wrote:
Actually a little surprised to see port 25 blocked in both directions here along with 1080. It’s like saying here’s your network buuuuut it’s limited.
Though I wouldn’t recommend spawning up 25 it’s still a legitimately used port today as alike with 1080.
Different topic. But most broadband providers have a similar list and it nearly always has port 25 blocked and you know why
-- J. Hellenthal
The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
On Mar 25, 2019, at 07:13, Ca By <cb.list6@gmail.com> wrote:
Blocked ssdp and move on
Ssdp is a horrible ddos vector
Comcast and many others already block it, because is the smart and best thing to do
https://www.xfinity.com/support/articles/list-of-blocked-ports
On Mon, Mar 25, 2019 at 1:30 AM marcel.duregards--- via NANOG < nanog@nanog.org> wrote:
Dear Community,
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.
What do you think ?
Thank, best regards,
-- Marcel
On 25/03/2019 13:44, Ca By wrote:
Different topic. But most broadband providers have a similar list and it nearly always has port 25 blocked and you know why
https://ipv6.he.net/certification/faq.php HE blocks IRC 6667 and SMTP 25 ports on https://tunnelbroker.net/ tunnels for the same reasons. 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) -- Christoffer
participants (10)
-
Bryan Holloway -
Ca By -
Hansen, Christoffer -
Jason Hellenthal -
marcel.duregards＠yahoo.fr -
Phil Lavin -
Saku Ytti -
Sean Donelan -
Tom Beecher -
Tom Hill