As a final update to this thread, we started blocking spoofed and
invalid traffic as of early Thursday morning Nov 19th. So far, knock on
wood, no reports of issues from our customer base.
In addition, I've been able to verify with the security research team's
test tool that we are no longer
> Randy Bush
> Sent: Tuesday, October 20, 2020 6:19 AM
>
> term blocked-ports {
> from {
> protocol [ tcp udp ];
> first-fragment;
> destination-port
> [ 0 sunrpc 135 netbios-ns netbios-dgm netbios-ssn 111 445 syslog
> 11211];
> }
> then {
> sample;
Randy, thank you for the reminder to look also at what services (L4
ports) should be generally blocked.
As I was implementing a similar rule for logging purposes, I discovered
an oddity with $VENDOR_C_XR ACLs. I created the following:
object-group port TCPUDP-BLOCKED
eq 0
eq sunrpc
eq
Might filtering port 11211 like that not risk blocking random connections,
where the operating system picked that port as source, which then becomes
destination on the reply packets?
tir. 20. okt. 2020 07.19 skrev Randy Bush :
> term blocked-ports {
> from {
> protocol [ tcp udp ];
>
> On 15 Oct 2020, at 05:43, Brian Knight via NANOG wrote:
>
> I think that's good for an enterprise network, but as an SP, I'm very
> hesitant to include this. Is this included in anyone else's transit / peer /
> IX ACL?
This must not be done on peering links and on transit networks
Hi,
You are missing some IPv6 bogons prefixes. Check:
http://www.bgp4all.com.au/pfs/_media/workshops/05-bgp-bcp.pdf (page 51-53)
http://bgpfilterguide.nlnog.net/guides/bogon_prefixes/#configuration-examples-ipv6
Regards.
I took a slightly different approach for my mental exercise, expressed in
IOS pigeon:
object-group ip address AS65001
192.0.2.0 255.255.255.0
end
object-group v6-network AS65001
2001:DB8::/32
end
object-group ip address TwentyFiveGigE1/0/1
192.0.2.0 255.255.255.254
end
term blocked-ports {
from {
protocol [ tcp udp ];
first-fragment;
destination-port
[ 0 sunrpc 135 netbios-ns netbios-dgm netbios-ssn 111 445 syslog
11211];
}
then {
sample;
discard;
}
}
and i block all external
Thanks to the folks who responded to my messages on and off-list. A
couple of folks have asked me to summarize the responses that I
received.
* Static ACL is currently the best way to protect a multi-homed network.
Loose RPF may be used if bogon filtering is more important, but it does
not
> On Oct 14, 2020, at 3:34 PM, Eric Kuhnke wrote:
>
> I think he means packet captures from an example, voluntarily-tested
> recursive nameserver subject to this attack.
Thanks. We have updated all the report pages with a self-test tool specific to
the network associated with the report.
> Chris Adams
> Sent: Thursday, October 15, 2020 3:59 PM
>
> Once upon a time, adamv0...@netconsultings.com
> said:
> > Actually ideally there would be a feature/knob to automatically sync BGP
> (and static routes) with packet filters.
>
> Junos has prefix-lists that can be referenced in both
Speaking as an ISP:
Most of the ISP networks I manage are multi-homed, and I don't
think uRPF provides the knobs to ensure legitimate traffic doesn't get
dropped in some cases, so we use static ACLs at the upstream edge on
ingress (and egress). These need updated any time new IP space is
Once upon a time, adamv0...@netconsultings.com
said:
> Actually ideally there would be a feature/knob to automatically sync BGP (and
> static routes) with packet filters.
Junos has prefix-lists that can be referenced in both BGP policy and
firewall statements.
--
Chris Adams
On Thu, Oct 15, 2020 at 10:30 AM Saku Ytti wrote:
> On Thu, 15 Oct 2020 at 17:22, Tim Durack wrote:
>
>
> > We deploy urpf strict on all customer end-host and broadband circuits.
> In this scenario urpf = ingress acl I don't have to think about.
>
> But you have to think about what prefixes a
> From: Saku Ytti
> Sent: Thursday, October 15, 2020 3:30 PM
>
> On Thu, 15 Oct 2020 at 17:22, Tim Durack wrote:
>
>
> > We deploy urpf strict on all customer end-host and broadband circuits. In
> this scenario urpf = ingress acl I don't have to think about.
>
> But you have to think about
Saku Ytti wrote on 15/10/2020 15:29:
But you have to think about what prefixes a customer has. If BGP you
need to generate prefix-list, if static you need to generate a static
route. As you already have to know and manage this information, what
is the incremental cost to also emit an ACL?
the
On Thu, 15 Oct 2020 at 17:22, Tim Durack wrote:
> We deploy urpf strict on all customer end-host and broadband circuits. In
> this scenario urpf = ingress acl I don't have to think about.
But you have to think about what prefixes a customer has. If BGP you
need to generate prefix-list, if
We deploy urpf strict on all customer end-host and broadband circuits. In
this scenario urpf = ingress acl I don't have to think about.
We deploy urpf loose on all customer multihomed DIA circuits. I dont this
makes sense - ingress packet acl would be more sane.
Any flavour of urpf on upstream
On Thu, 15 Oct 2020 at 15:14, wrote:
> Yes one should absolutely do that, but...
> But considering to become a good netizen what is more work?
> a) Testing and the enabling uRPF on every customer facing box or setting up
> precise ACLs on every customer facing port, and then maintaining all
> From: Saku Ytti
> Sent: Thursday, October 15, 2020 11:12 AM
>
> Hey,
>
Hey Saku,
> > All stub autonomous systems should have a simple egress ACL allowing
> only PI of their customers and their own PAs -it’s a simple ACL at each
> AS-Exit
> points (towards transits/peers), that’s it.
> >
> >
ght want to add
all the amplification ports like 123, 161, etc
Jean
-Original Message-
From: NANOG On Behalf Of Brian
Knight via NANOG
Sent: Wednesday, October 14, 2020 6:43 PM
To: nanog
Subject: Re: Ingress filtering on transits, peers, and IX ports
So I have put together what I t
.
>
> -not sure why this isn’t the first sentence in every BCP and “security
> bulletin”…
>
>
>
>
>
> adam
>
>
>
> *From:* NANOG *On
> Behalf Of *Baldur Norddahl
> *Sent:* Thursday, October 15, 2020 8:38 AM
> *To:* nanog@nanog.org
> *Subject:* Re:
Hey,
> All stub autonomous systems should have a simple egress ACL allowing only PI
> of their customers and their own PAs -it’s a simple ACL at each AS-Exit
> points (towards transits/peers), that’s it.
>
> -not sure why this isn’t the first sentence in every BCP and “security
> bulletin”…
I
”…
adam
From: NANOG On Behalf Of
Baldur Norddahl
Sent: Thursday, October 15, 2020 8:38 AM
To: nanog@nanog.org
Subject: Re: Ingress filtering on transits, peers, and IX ports
All DNS resolvers discovered on our network belong to customers. Our own
resolvers, running unbound, were
All DNS resolvers discovered on our network belong to customers. Our own
resolvers, running unbound, were not discovered.
While filtering same AS on ingress could help those customers (but only one
was a open relay), filtering bogons is something the customer can also do.
Or the software can be
> On 15 Oct 2020, at 04:09, Casey Deccio wrote:
>
>
>> On Oct 13, 2020, at 8:49 PM, Chris Adams wrote:
>>
>> Once upon a time, Eric Kuhnke said:
>>> Considering that one can run an instance of an anycasted recursive
>>> nameserver, under heavy load for a very large number of clients, on a
So I have put together what I think is a reasonable and complete ACL.
From my time in the enterprise world, I know that a good ingress ACL
filters out traffic sourcing from:
* Bogon blocks, like 0.0.0.0/8, 127.0.0.0/8, RFC1918 space, etc
(well-documented in
I think he means packet captures from an example, voluntarily-tested
recursive nameserver subject to this attack.
On Wed, Oct 14, 2020 at 11:53 AM Casey Deccio wrote:
> Hi Bryan,
>
> > On Oct 14, 2020, at 12:43 PM, Bryan Holloway wrote:
> >
> > I too would like to know more about their
"What do you mean by "tangibles in the form of PCAPs””
I think Brian means packet captures, in PCAP format, so that we can observe
example testing via Wireshark or some other protocol analyzer.
-mel
> On Oct 14, 2020, at 11:52 AM, Casey Deccio wrote:
>
> Hi Bryan,
>
>> On Oct 14, 2020, at
Hi Bryan,
> On Oct 14, 2020, at 12:43 PM, Bryan Holloway wrote:
>
> I too would like to know more about their methodology
We've written up our methodology and results in a paper that will be available
in a few weeks. Happy to post it here if folks are interested. Obviously, no
networks are
I too would like to know more about their methodology and actual
tangibles ideally in the form of PCAPs.
On 10/14/20 4:56 PM, Brian Knight via NANOG wrote:
Hi Eric,
I shot a message over the folk who did the testing for more info about
their test. If I'm able to find anything useful in our
On Tue, Oct 13, 2020 at 05:49:42PM -0500, Brian Knight via NANOG wrote:
> Hi Mel,
>
> My understanding of uRPF is:
>
> * Strict mode will permit a packet only if there is a route for the
> source IP in the RIB, and that route points to the interface where the
> packet was received
>
> *
14, 2020 3:12:22 AM
Subject: Re: Ingress filtering on transits, peers, and IX ports
Brian Knight via NANOG wrote on 13/10/2020 23:49:
> Strict mode won't work for us, because with our multi-homed transits and
> IX peers, we will almost certainly drop a legitimate packet because the
>
> On Oct 13, 2020, at 8:49 PM, Chris Adams wrote:
>
> Once upon a time, Eric Kuhnke said:
>> Considering that one can run an instance of an anycasted recursive
>> nameserver, under heavy load for a very large number of clients, on a $600
>> 1U server these days... I wonder what exactly the
Hi Eric,
I shot a message over the folk who did the testing for more info about
their test. If I'm able to find anything useful in our logs from their
detail, I'll post it to the list.
The message referenced DNS cache poisoning and DDOS amplification, so it
seemed fairly general and more
Hi Marcos,
Thanks for your reply. But I am looking for guidance on traffic
filtering, not BGP prefix filtering.
I have looked at BCP 84, and it's a good overview of the methods
available to an ISP. My questions are more operational in nature and
are not covered by the document. Of the
On 10/13/20 9:40 PM, Nikolas Geyer wrote:
Tl;dr - definitely don’t accept your own prefix from the site it originated
from, or other sites that have internal connectivity. But also don’t assume
that an AS has a full-mesh of internal connectivity behind it and shouldn’t
accept its own prefixes
Brian Knight via NANOG wrote on 13/10/2020 23:49:
Strict mode won't work for us, because with our multi-homed transits and
IX peers, we will almost certainly drop a legitimate packet because the
best route is through another transit.
there's no "almost" about it: strict mode is unfeasible for
On 10/13/20 8:04 PM, Eric Kuhnke wrote:
If I had a dollar for every 'scary security alert' email received in a
NOC email inbox from a 'security researcher group' that is the results
of a port scan, or some small subset of trojan infected residential
endpoint computers attempting outbound
If I had a dollar for every 'scary security alert' email received in a NOC
email inbox from a 'security researcher group' that is the results of a
port scan, or some small subset of trojan infected residential endpoint
computers attempting outbound connections on ($common_service_port), or
Once upon a time, Eric Kuhnke said:
> Considering that one can run an instance of an anycasted recursive
> nameserver, under heavy load for a very large number of clients, on a $600
> 1U server these days... I wonder what exactly the threat model is.
A customer forwarded one of these notices to
Aside from the BCPs currently being discussed for ingress filtering, I
would be very interested in seeing what this traffic looked like from the
perspective of your DNS servers' logs.
I assume you're talking about customer facing recursive/caching resolvers,
and not authoritative-only
Specifically with regards to “Don’t accept your own prefix”, this poses an
interesting challenge for the original notice sent out by the security
researchers.
It is not uncommon today for various content networks (and others) to operate
multiple “island networks” with a single ASN. For
Hi, Brian
Check RFC3704/BCP84 Ingress Filtering for Multihomed Networks (Updated
by: RFC8704 Enhanced Feasible-Path uRPF).
Ingress Access Lists require typically manual maintenance, but are
the most bulletproof when done properly; typically, ingress access
lists are best fit between
Hi Mel,
My understanding of uRPF is:
* Strict mode will permit a packet only if there is a route for the
source IP in the RIB, and that route points to the interface where the
packet was received
* Loose mode will permit a packet if there is a route for the source IP
in the RIB. It does not
.
I’m curious to hear/read which uRPF would you recommend for this particular
case.
Thanks
Jean St-Laurent
From: NANOG On Behalf Of Mel Beckman
Sent: Tuesday, October 13, 2020 6:22 PM
To: Brian Knight
Cc: nanog@nanog.org
Subject: Re: Ingress filtering on transits, peers, and IX ports
Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Tue, Oct 13, 2020 at 5:22 PM Mel Beckman wrote:
> You can also use Unicast Reverse Path Forwarding. RPF is more
You can also use Unicast Reverse Path Forwarding. RPF is more efficient than
ACLs, and has the added advantage of not requiring maintenance. In a nutshell,
if your router has a route to a prefix in its local RIB, then incoming packets
from a border interface having a matching source IP will be
We recently received an email notice from a group of security
researchers who are looking at the feasibility of attacks using spoofed
traffic. Their methodology, in broad strokes, was to send traffic to
our DNS servers with a source IP that looked like it came from our
network. Their attacks
49 matches
Mail list logo
