Re: Comcast XB6 Blocking TFTP

[Blake Hudson]

You may already be aware, but TFTP - like FTP - is not a NAT friendly 
protocol and requires a helper or ALG to inspect the control channel in 
order to open up and translate the connections used by the data channel 
(which use unrelated high numbered UDP ports). If TFTP is not working 
when NAT is enabled, it sounds like that modem does not have a TFTP ALG 
included or enabled. I have no experience with that model personally, 
but it's not a unique problem. Workarounds are to not use NAT, purchase 
a better NAT router, define a DMZ host, or use a NAT friendly protocol 
like SCP.


Sorry about SIP. That's also not a NAT friendly protocol, and while some 
of the same workarounds still apply there are generally not numerous or 
better alternatives like there are for file transfer protocols that 
replace FTP/TFTP.


--Blake

Mike Hammett wrote on 3/25/2019 12:18 PM:
Have any of you seen the Comcast XB6 modem blocking TFTP and some SIP 
requests?


We put the modem into bridge mode and TFTP requests are successful. 
Reset it, set security to the lowest setting, disable the firewall... 
 no TFTP requests pass.


Modem\Router - cable - laptop.

Of course we can't call into support because the customer is out of 
town and thus we're unable to authenticate ourselves to support (not 
that we tried).




-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

Re: FW: softlayer.com

[John Alcock]

Well,

It has been a challenge.  I am not sure who helped or fixed the problem,
but now anything hosted on softlayer.com is responding.

I am not sure if there was anyone lurking on the list that helped out, but
if you are, Thank You.

I have a batch of new stuff not working, but they may be one off's.  I am
trying to find a pattern.

John

On Fri, Mar 22, 2019 at 2:32 PM Travis Garrison 
wrote:

> Traceroute from here if it helps
>
>
>
> Tracing route to 138-43-128-1.reserved.highland.net [138.43.128.1]
>
> over a maximum of 30 hops:
>
>
>
>   1<1 ms<1 ms<1 ms  [REDACTED]
>
>   2<1 ms<1 ms<1 ms  [REDACTED]
>
>   3 1 ms 1 ms<1 ms  [REDACTED]
>
>   4 1 ms<1 ms<1 ms  [REDACTED]
>
>   5 6 ms 6 ms 6 ms  v313.core1.mci3.he.net [216.218.213.141]
>
>   616 ms16 ms16 ms  100ge10-2.core1.dal1.he.net
> [184.105.81.206]
>
>   726 ms26 ms26 ms
> xo-as15-as2828.10gigabitethernet6-7.core1.dal1.he.net [184.105.255.78]
>
>   840 ms39 ms40 ms  207.88.14.198.ptr.us.xo.net
> [207.88.14.198]
>
>   940 ms39 ms40 ms  207.88.12.178.ptr.us.xo.net
> [207.88.12.178]
>
> 1039 ms39 ms39 ms  216.156.16.239.ptr.us.xo.net
> [216.156.16.239]
>
> 1148 ms48 ms48 ms
> ip65-46-198-198.z198-46-65.customer.algx.net [65.46.198.198]
>
> 1241 ms41 ms41 ms
> occm-6.dhcp.grp1-rng1.tncsvl.blomand.net.57.131.192.in-addr.arpa
> [192.131.57.6]
>
> 13 *** Request timed out.
>
>
>
> Thanks
>
> Travis
>
>
>
> *From:* NANOG  *On Behalf Of *Siyuan Miao
> *Sent:* Friday, March 22, 2019 9:22 AM
> *To:* Nikolas Geyer 
> *Cc:* nanog@nanog.org
> *Subject:* Re: softlayer.com
>
>
>
> Perhaps it won't work because their customer support will ask you for
> bi-directional traceroute and refused to forward to backbone team.
>
>
>
> Then they'll say it's not their fault and you can see the packet is
> dropped outside our network.
>
>
>
> Here's a sample traceroute from SoftLayer Washington, San Jose and Seattle
> in case someone needs it:
>
>
>
> aveline@iad02-sl01:~$ mtr 138.43.128.1 --report-wide
>
> Start: Fri Mar 22 17:20:42 2019
>
> HOST: iad02-sl01Loss%   Snt   Last   Avg
> Best  Wrst StDev
>
>   1.|-- [REDACTED] 0.0%101.4
>  1.5   0.8   3.7   1.0
>
>   2.|-- ae13.dar02.wdc01.networklayer.com  0.0%100.5
>  3.3   0.4  28.6   8.8
>
>   3.|-- ae9.bbr01.eq01.wdc02.networklayer.com  0.0%100.8
>  0.8   0.7   1.0   0.0
>
>   4.|-- eqix-dc5.intellifiber.com  0.0%100.8
>  1.2   0.8   2.2   0.3
>
>   5.|-- ae13-0.cr02.asbn01-va.us.windstream.net0.0%100.9
>  0.9   0.9   1.0   0.0
>
>   6.|-- ae11-0.cr01.atln02-ga.us.windstream.net0.0%10   15.6
> 16.1  15.6  17.4   0.5
>
>   7.|-- ae0-0.pe06.atln02-ga.us.windstream.net 0.0%10   17.4
> 16.1  15.9  17.4   0.3
>
>   8.|-- h43.88.198.64.static.ip.windstream.net 0.0%10   24.7
> 24.8  24.6  24.9   0.0
>
>   9.|-- east.tndodge-21.static.tncsvl.blomand.net  0.0%10   22.6
> 22.8  22.5  23.8   0.0
>
>  10.|-- ???   100.0100.0
>  0.0   0.0   0.0   0.0
>
>
>
> aveline@sjc03-sl01:~$ mtr 138.43.128.1 --report-wide
>
> Start: Fri Mar 22 16:21:04 2019
>
> HOST: sjc03-sl01Loss%   Snt   Last   Avg
> Best  Wrst StDev
>
>   1.|-- [REDACTED] 0.0%102.4
>  2.0   0.3  14.3   4.3
>
>   2.|-- ae0.dar02.sjc01.networklayer.com   0.0%101.0
>  0.5   0.3   1.3   0.0
>
>   3.|-- ae9.bbr01.eq01.sjc02.networklayer.com  0.0%100.8
>  0.8   0.7   0.9   0.0
>
>   4.|-- eqix-sv1.windstream.com0.0%100.9
>  0.9   0.8   1.1   0.0
>
>   5.|-- ae6-0.cr02.lsaj01-ca.us.windstream.net 0.0%10   11.6
> 11.5  11.5  11.6   0.0
>
>   6.|-- ae-11-0.cr01.dlls01-tx.us.windstream.net   0.0%10   42.6
> 42.7  42.5  43.4   0.0
>
>   7.|-- ae7-0.cr02.atln02-ga.us.windstream.net 0.0%10   64.0
> 65.6  63.9  74.2   3.4
>
>   8.|-- ae1-0.pe06.atln02-ga.us.windstream.net 0.0%10   62.3
> 62.7  62.2  66.9   1.5
>
>   9.|-- h43.88.198.64.static.ip.windstream.net 0.0%10   71.9
> 72.0  71.9  72.2   0.0
>
>  10.|-- east.tndodge-21.static.tncsvl.blomand.net  0.0%10   69.9
> 68.8  68.6  69.9   0.3
>
>  11.|-- ???   100.0100.0
>  0.0   0.0   0.0   0.0
>
>
>
> aveline@sea04-sl01:~$ mtr 138.43.128.1 --report-wide
>
> Start: Fri Mar 22 08:19:09 2019
>
> HOST: sea04-sl01Loss%   Snt   Last   Avg
> Best  Wrst StDev
>
>   1.|-- [REDACTED] 0.0%100.7
>  1.2   0.7   1.8   0.0
>
>   2.|-- ae12.dar02.sr01.sea01.networklayer.com 0.0%100.6
>  0.7   0.5   1.3   0.0
>
>   3.|-- ae9.bbr01.wb01.sea02.networklayer.com  0.0%101.2
>  1.0   0.7   

Bay Area: Help test Earthquake Early Warning System

[Sean Donelan]

This is being covered on local San Francisco Bay Area media, but if 
network engineers aren't paying attention to the local news.  Here is an 
opportunity for tech folks in the Oakland area to participate in the 
Earthquake Early Warning Test.


TEST INFORMATION
Date: Wednesday, March 27th, 2019
Time: 11:00AM
Message: “TEST of the CA Earthquake Warning System. No action required. 
THIS IS A TEST.”
Location: Downtown Oakland (Lakeside commercial neighborhood) with 
bleedover into adjacent areas depending on cell tower RF propagation.



Part of this year's test is measuring how quickly earthquake warning 
alerts are propagated through different emergency alert channels. The 
future goal is transmitting earthquake alerts in less than 3 seconds. 
That is unlikely with current systems. Instead the test will help measure 
current alert system propagation delays.


If you have access to accurate clocks, and a cell phone, and are in the 
Oakland area on Wednesday.


https://www.caloes.ca.gov/cal-oes-divisions/earthquake-tsunami-volcano-programs/california-earthquake-early-warning-program


Please participate in a citizen science test to see how fast these alerts 
can be transmitted to cell phones. For this test to be effective, you need 
to take the following steps:


1) Before the test starts, using either your cell phone or your desktop 
computer go to www.time.is.


2) Starting a few minutes in advance of the scheduled alert time (11:00AM 
Pacific), keep a close watch on your cell phone and www.time.is note the 
exact time--to the nearest second, if you can--at which the alert first 
arrives on your phone. This alert will have the heading "Emergency Alert", 
and this message: “TEST of the CA Earthquake Warning System. No action 
required. THIS IS A TEST.”


3) Please take this survey, armed with the time (to the second) you 
received the alert. https://www.surveymonkey.com/r/WEATESTSHAKEALERT



Yeah, I know. Some folks on this list likely have nano-second 
synchronized clocks and will debate whether the propagation delay is 
taking into account the correct einstein relativity offset of the earth's 
surface in the oakland bay area (I just made that techno-babble up).


Just do the reasonable thing, and help out the scientists :-)

Comcast XB6 Blocking TFTP

[Mike Hammett]

Have any of you seen the Comcast XB6 modem blocking TFTP and some SIP requests? 

We put the modem into bridge mode and TFTP requests are successful. Reset it, 
set security to the lowest setting, disable the firewall... no TFTP requests 
pass. 

Modem\Router - cable - laptop. 


Of course we can't call into support because the customer is out of town and 
thus we're unable to authenticate ourselves to support (not that we tried). 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

Re: Incoming SSDP UDP 1900 filtering

[Tom Beecher]

"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  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
>

Re: Incoming SSDP UDP 1900 filtering

[Saku Ytti]

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

Re: Incoming SSDP UDP 1900 filtering

[Sean Donelan]

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.

Re: Incoming SSDP UDP 1900 filtering

[Bryan Holloway]

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 > 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

Re: Incoming SSDP UDP 1900 filtering

[Tom Beecher]

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  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
>

Re: Incoming SSDP UDP 1900 filtering

[Sean Donelan]

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/

Re: webauthn

[Tom Beecher]

I will personally always prefer hardware based methods where the private
key data is never exposed over pure software based methods.

On Mon, Mar 25, 2019 at 9:32 AM Mauricio Rodriguez 
wrote:

> My understanding is that 2-factor is one of the primary drivers for
> webauthn.  I feel that hardware dongles are the thing of the past, with
> software now being available that runs on your smartphone and serves the
> same function.  Example - Google Authenticator.
>
> __
> Regards,
> Mauricio Rodriguez
> Founder / Owner
> Fletnet Network Engineering (www.fletnet.com)
> 1951 NW 7th Ave #600, Miami, FL 33136
>
> mauricio.rodrig...@fletnet.com
> Office: +1-786-309-5493
> Mobile: +1-305-978-6884
>
> Schedule a Meeting with me
> 
>
>
>
>
>
> On Fri, Mar 22, 2019 at 8:52 PM Michael Thomas  wrote:
>
>> I know it's a little tangential, but it's a huge operational issue for
>> network operations too. Have any NANOG folks been paying attention to
>> webauthn? i didn't know about until yesterday, though i wrote a proof of
>> concept of something that looks a lot like webauthn in 2012. The thing that
>> is kind of concerning to me is that there seems to be some amount of
>> misconception (I hope!) that you need hardware or biometric or some
>> non-password based authentication on the user device in the many write ups
>> i've been reading. i sure hope that misconception doesn't take hold because
>> there is nothing wrong with *local* password based authentication to unlock
>> your credentials. i fear that if the misconception takes hold, it will
>> cause the entire effort to tank. the issue with passwords is transmitting
>> them over the wire, first and foremost. strong *local* passwords that
>> unlock functionality is still perfectly fine for many many applications,
>> IMO.
>>
>> Which isn't to say that hardware/biometric is bad, it's just to say that
>> they are separable problems with their own set of tradeoffs. NANOG folks
>> sound like prime examples of who should be using 2 factor, etc. But we
>> don't want to discourage, oh say, Epicurious to implement webauthn to get
>> to my super-secret recipe box because they don't think people will buy id
>> dongles.
>>
>> Mike
>>
>
> *This message (and any associated files) may contain confidential and/or
> privileged information. If you are not the intended recipient or authorized
> to receive this for the intended recipient, you must not use, copy,
> disclose or take any action based on this message or any information
> herein. If you have received this message in error, please advise the
> sender immediately by sending a reply e-mail and delete this message. Thank
> you for your cooperation.*

Re: webauthn

[Mauricio Rodriguez]

My understanding is that 2-factor is one of the primary drivers for
webauthn.  I feel that hardware dongles are the thing of the past, with
software now being available that runs on your smartphone and serves the
same function.  Example - Google Authenticator.

__
Regards,
Mauricio Rodriguez
Founder / Owner
Fletnet Network Engineering (www.fletnet.com)
1951 NW 7th Ave #600, Miami, FL 33136

mauricio.rodrig...@fletnet.com
Office: +1-786-309-5493
Mobile: +1-305-978-6884

Schedule a Meeting with me






On Fri, Mar 22, 2019 at 8:52 PM Michael Thomas  wrote:

> I know it's a little tangential, but it's a huge operational issue for
> network operations too. Have any NANOG folks been paying attention to
> webauthn? i didn't know about until yesterday, though i wrote a proof of
> concept of something that looks a lot like webauthn in 2012. The thing that
> is kind of concerning to me is that there seems to be some amount of
> misconception (I hope!) that you need hardware or biometric or some
> non-password based authentication on the user device in the many write ups
> i've been reading. i sure hope that misconception doesn't take hold because
> there is nothing wrong with *local* password based authentication to unlock
> your credentials. i fear that if the misconception takes hold, it will
> cause the entire effort to tank. the issue with passwords is transmitting
> them over the wire, first and foremost. strong *local* passwords that
> unlock functionality is still perfectly fine for many many applications,
> IMO.
>
> Which isn't to say that hardware/biometric is bad, it's just to say that
> they are separable problems with their own set of tradeoffs. NANOG folks
> sound like prime examples of who should be using 2 factor, etc. But we
> don't want to discourage, oh say, Epicurious to implement webauthn to get
> to my super-secret recipe box because they don't think people will buy id
> dongles.
>
> Mike
>

-- 
This message (and any associated files) may contain confidential and/or 
privileged information. If you are not the intended recipient or authorized 
to receive this for the intended recipient, you must not use, copy, 
disclose or take any action based on this message or any information 
herein. If you have received this message in error, please advise the 
sender immediately by sending a reply e-mail and delete this message. Thank 
you for your cooperation.

Re: webauthn

[Roxanna Cieplinska]

Keep it short!

Roxanna I. Cieplinska
M: + 1 (415) 412-7699

Sent from my iPhone

> On Mar 22, 2019, at 5:50 PM, Michael Thomas  wrote:
> 
> I know it's a little tangential, but it's a huge operational issue for 
> network operations too. Have any NANOG folks been paying attention to 
> webauthn? i didn't know about until yesterday, though i wrote a proof of 
> concept of something that looks a lot like webauthn in 2012. The thing that 
> is kind of concerning to me is that there seems to be some amount of 
> misconception (I hope!) that you need hardware or biometric or some 
> non-password based authentication on the user device in the many write ups 
> i've been reading. i sure hope that misconception doesn't take hold because 
> there is nothing wrong with *local* password based authentication to unlock 
> your credentials. i fear that if the misconception takes hold, it will cause 
> the entire effort to tank. the issue with passwords is transmitting them over 
> the wire, first and foremost. strong *local* passwords that unlock 
> functionality is still perfectly fine for many many applications, IMO.
> 
> Which isn't to say that hardware/biometric is bad, it's just to say that they 
> are separable problems with their own set of tradeoffs. NANOG folks sound 
> like prime examples of who should be using 2 factor, etc. But we don't want 
> to discourage, oh say, Epicurious to implement webauthn to get to my 
> super-secret recipe box because they don't think people will buy id dongles.
> 
> Mike

Re: Incoming SSDP UDP 1900 filtering

[Hansen, Christoffer]

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



signature.asc
Description: OpenPGP digital signature

Re: Incoming SSDP UDP 1900 filtering

[Ca By]

On Mon, Mar 25, 2019 at 5:33 AM Jason Hellenthal 
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 but 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  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
>>
>

Re: Incoming SSDP UDP 1900 filtering

[Jason Hellenthal via NANOG]

Actually a little surprised to see port 25 blocked in both directions here 
along with 1080. It’s like saying here’s your network but 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  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 
>>  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

Re: Incoming SSDP UDP 1900 filtering

[Ca By]

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
>

Re: Incoming SSDP UDP 1900 filtering

[Tom Hill]

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

Re: Incoming SSDP UDP 1900 filtering

[Sean Donelan]

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 :-)

RE: Incoming SSDP UDP 1900 filtering

[Phil Lavin]

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

Re: Incoming SSDP UDP 1900 filtering

[Sean Donelan]

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.

Incoming SSDP UDP 1900 filtering

[marcel.duregards--- via NANOG]

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