On Thursday, 11 April, 2019 08:08, Patrick McEvilly
wrote:
>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
On Thu, Apr 11, 2019 at 12:52 PM Barry Raveendran Greene
wrote:
> On Apr 11, 2019, at 10:08, Patrick McEvilly
wrote:
>> 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 tc
On Thu, Apr 11, 2019 at 7:15 AM Patrick McEvilly <
patrick_mcevi...@harvard.edu> wrote:
> 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
> On Apr 11, 2019, at 10:08, Patrick McEvilly
> wrote:
> 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?
Filtering Exploitable Ports and Minimi
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 un
"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 sy
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, becau
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 mig
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
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.
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-fil
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 reaso
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 t
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
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:
>
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
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 :-)
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
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 filte
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
20 matches
Mail list logo
