Re: BCP38/84 and DDoS ACLs

2017-06-01 Thread Matthew Luckie 
> This doesn't seem quite like it is BCP38 and more like this is
> BCP84, but it only talks about use of ACLs in section 2.1 without
> providing any examples. Given that it is also 13 years old I thought
> there might be fresher information out there.

section 2.1 is about permitting packets from specific address ranges.
If you want to assess the dynamism or size of ACL required for a given
AS, place the AS into this URL:

https://spoofer.caida.org/prefixes.php?asn=1909

Matthew

signature.asc
Description: PGP signature

Re: BCP38/84 and DDoS ACLs

2017-05-29 Thread Rabbi Rob Thomas 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear team,

> Your bogon list has a few non-bogons, and is missing a few current
> bogon.
> 
> Team Cymru keep a good resource for this: http://www.team-cymru. 
> org/bogon-dotted-decimal.html

Thank you, Dave!

The full list of formats and styles can be found here:

   

Be well,
Rob.
- -- 
Rabbi Rob Thomas   Team Cymru
   "It is easy to believe in freedom of speech for those with whom we
agree." - Leo McKern

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZLFmkAAoJEEPoYWL6hfKNJTUP/2KWdB1nwUx/R6tReKNkKkSx
L71nOaLMy/MIxOgw1OgI2xMPPpJtsGhTje37gpc8jV0jrx7P7VJ1/omp4gS8MFfd
ij2XSgSmix8neTYoqpfpj15Ra+1fTxcqxO68mza5IG5zYDR7Z96/jOzHoGe1NgJk
pPpS1cNv55ToeCG6ETcJ6k1LFC4uzNDdu5bVbLJMqeTbnHu0GCV/hx5xIHpWHOSM
dODifv8fadqjJNx548smGim2aFApFv1ALHNrxLm8jWokNLhDSEJBQl9pnnByifrs
huiRcCRVCzgJXCaig6ykS7RHtqCnMnIEllMqeJqCVzA2+l/FS7NFJmnXttXT5SyK
HoL+pbQ7PeUO5CgMheBfSkguECIjRJb3L/mnMCGKuueBoYikH2u7WFUowBEYlezH
I/BmooPVoKKrdSX9Y/UU8Pt/mW06M5rVo/hs2mB2uZ44SDqu9IZGcef+9Qb1Jq25
IxUHlRVXg5aC8k0VOQm0JCMD2JGeRO5OSnu/pnsuaywrK6wEvns/mgFaPTNOsTR1
AbUvrBl+MJ3sFbxJUDioIojXPn9H+LdC4x79+NpdVu9vY8EZ9aCY8YWJLd56hjIH
HfA7Y+M5JGVfdXBp6iJftR6U1cBumWasQ5Evz48VCnzEt75qXitHijjdmvfeyRuV
unmPsF25BuVfX3DAYYPu
=57M1
-END PGP SIGNATURE-

Re: BCP38/84 and DDoS ACLs

2017-05-27 Thread Dave Bell 
Your bogon list has a few non-bogons, and is missing a few current bogon.

Team Cymru keep a good resource for this: http://www.team-cymru.
org/bogon-dotted-decimal.html

Regards,
Dave

On 26 May 2017 5:01 pm, "Compton, Rich A"  wrote:

> To block UDP port 19 you can add something like:
> deny udp any eq 19 any
> deny udp any any eq 19
>
> This will prevent the DDoS attack traffic entering your network (source
> port 19) as well as the hosts scanning around looking for hosts on your
> network that can be used in amplification attacks (destination port 19).
> Please note that this will not block the UDP fragments that come with
> these attacks which have no L4 port to block.  You can possibly do
> policing on UDP fragments to address this.
>
> I¹d also suggest adding:
> deny udp any eq 17 any
> deny udp any any eq 17
>
> deny udp any eq 123 any packet-length eq 468
>
> deny udp any eq 520 any
> deny udp any any eq 520
>
> deny udp any eq 1900 any
> deny udp any any eq 1900
>
> Some people will complain that you shouldn¹t block UDP port 1900 because
> it¹s above 1023 but believe me it¹s worth it.
>
>
>
> also to block invalid source IPs to prevent some spoofed traffic from
> coming into your network:
>
> deny ipv4 0.0.0.0 0.255.255.255 any
> deny ipv4 10.0.0.0 0.255.255.255 any
> deny ipv4 11.0.0.0 0.255.255.255 any
> deny ipv4 22.0.0.0 0.255.255.255 any
> deny ipv4 30.0.0.0 0.255.255.255 any
> deny ipv4 100.64.0.0 0.63.255.255 any
> deny ipv4 127.0.0.0 0.255.255.255 any
> deny ipv4 169.254.0.0 0.0.255.255 any
> deny ipv4 172.16.0.0 0.15.255.255 any
> deny ipv4 192.0.0.0 0.0.0.255 any
> deny ipv4 192.0.2.0 0.0.0.255 any
> deny ipv4 192.168.0.0 0.0.255.255 any
> deny ipv4 198.18.0.0 0.1.255.255 any
> deny ipv4 198.51.0.0 0.0.0.255 any
> deny ipv4 203.0.113.0 0.0.0.255 any
> deny ipv4 224.0.0.0 31.255.255.255 any
>
>
> For BCP38 and 84 you would want to enable uRPF
> https://en.wikipedia.org/wiki/Reverse_path_forwarding
> https://tools.ietf.org/html/rfc3704
>
>
>
> Rich Compton   | Principal Eng |   314.596.2828
> 14810 Grasslands  Dr,Englewood,  CO80112
>
>
>
>
>
>
> On 5/26/17, 11:39 AM, "NANOG on behalf of Graham Johnston"
>  wrote:
>
> >I really did try looking before I sent the email but couldn't quickly
> >find what I was looking for.
> >
> >I am looking for information regarding standard ACLs that operators may
> >be using at the internet edge of their network, on peering and transit
> >connections, wherein you are filtering ingress packets such as those
> >sourced from UDP port 19 for instance. I've found incomplete conceptual
> >discussions about it nothing that seemed concrete or complete.
> >
> >This doesn't seem quite like it is BCP38 and more like this is BCP84, but
> >it only talks about use of ACLs in section 2.1 without providing any
> >examples. Given that it is also 13 years old I thought there might be
> >fresher information out there.
> >
> >Thanks,
> >graham
>
> E-MAIL CONFIDENTIALITY NOTICE:
> The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) and may contain confidential and/or legally
> privileged information. If you are not the intended recipient of this
> message or if this message has been addressed to you in error, please
> immediately alert the sender by reply e-mail and then delete this message
> and any attachments. If you are not the intended recipient, you are
> notified that any use, dissemination, distribution, copying, or storage of
> this message or any attachment is strictly prohibited.
>
>

Re: BCP38/84 and DDoS ACLs

2017-05-26 Thread joel jaeggli 
On 5/26/17 10:24, Kody Vicknair wrote:
> When I was doing some research in regards to the same subject I ran across 
> this doc. I've found it to be very helpful.
>
> http://nabcop.org/index.php/DDoS-DoS-attack-BCOP
Causally applied RPF checks applied to transit and peer interfaces
especially exchange fabrics have a very high-liklihood of blackholing
traffic you wanted particularly during maintenance if not casually
implemented. A very careful read rfc3704/bcp 84 is a necessary part of
implementing bcp 38 filters.

>
>
> Kody Vicknair
> Network Engineer
>
> Tel:985.536.1214
> Fax:985.536.0300
> Email:  kvickn...@reservetele.com
>
> Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
>
> _
>
> Disclaimer:
> The information transmitted, including attachments, is intended only for the 
> person(s) or entity to which it is addressed and may contain confidential 
> and/or privileged material which should not disseminate, distribute or be 
> copied. Please notify Kody Vicknair immediately by e-mail if you have 
> received this e-mail by mistake and delete this e-mail from your system. 
> E-mail transmission cannot be guaranteed to be secure or error-free as 
> information could be intercepted, corrupted, lost, destroyed, arrive late or 
> incomplete, or contain viruses. Kody Vicknair therefore does not accept 
> liability for any errors or omissions in the contents of this message, which 
> arise as a result of e-mail transmission. .
>
> -Original Message-
> From: NANOG [mailto:nanog-bounces+kvicknair=reservetele@nanog.org] On 
> Behalf Of Roland Dobbins
> Sent: Friday, May 26, 2017 12:20 PM
> To: nanog@nanog.org
> Subject: Re: BCP38/84 and DDoS ACLs
>
>
> On 26 May 2017, at 22:39, Graham Johnston wrote:
>
>> I am looking for information regarding standard ACLs that operators
>> may be using at the internet edge of their network, on peering and
>> transit connections,
> These .pdf presos may be of interest:
>
> <https://app.box.com/s/ko8lk4vlh1835p36na3u>
>
> <https://app.box.com/s/xznjloitly2apixr5xge>
>
> They talk about iACL and tACL design philosophy.
>
> What traffic you should permit/deny on your network is, of course, 
> situationally-specific.  Depends on what kind of network it is, what 
> servers/services/applications/users you have, et. al.  You may need one set 
> of ACLs at the peering/transit edge, and other, more specific ACLs, at the 
> IDC distribution gateway, customer aggregation gateway, et. al.
>
> ---
> Roland Dobbins 
>




signature.asc
Description: OpenPGP digital signature

Re: BCP38/84 and DDoS ACLs

2017-05-26 Thread Randy Bush 
to be honest, i do not block chargen etc at my borders; i scan hosts
and turn off silly services on the hosts.  but i do not have myriads of
hosts in a soft gooey inside.

what i block at my borders are 135-139, 161 (except for holes for
measurement stations), 445, 514, stuff such as that.

ykmv

randy

Re: BCP38/84 and DDoS ACLs

2017-05-26 Thread Roland Dobbins 
On 27 May 2017, at 0:19, Roland Dobbins wrote:

> 

This is the correct URI for the first preso, apologies:



---
Roland Dobbins

Re: BCP38/84 and DDoS ACLs

2017-05-26 Thread Roland Dobbins 

On 27 May 2017, at 0:54, valdis.kletni...@vt.edu wrote:

> I'll go out on a limb and suggest that except for a very basic home/SOHO
> network, "You may need" should be "You will probably need".

Concur, heh.

---
Roland Dobbins

Re: BCP38/84 and DDoS ACLs

2017-05-26 Thread valdis . kletnieks 
On Sat, 27 May 2017 00:19:34 +0700, Roland Dobbins said:

> servers/services/applications/users you have, et. al.  You may need one
> set of ACLs at the peering/transit edge, and other, more specific ACLs,
> at the IDC distribution gateway, customer aggregation gateway, et. al.

I'll go out on a limb and suggest that except for a very basic home/SOHO
network, "You may need" should be "You will probably need".


pgpXVRTvTB0c_.pgp
Description: PGP signature

RE: BCP38/84 and DDoS ACLs

2017-05-26 Thread Kody Vicknair 
When I was doing some research in regards to the same subject I ran across this 
doc. I've found it to be very helpful.

http://nabcop.org/index.php/DDoS-DoS-attack-BCOP




Kody Vicknair
Network Engineer

Tel:985.536.1214
Fax:985.536.0300
Email:  kvickn...@reservetele.com

Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084

_

Disclaimer:
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Kody Vicknair immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Kody Vicknair therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission. .

-Original Message-
From: NANOG [mailto:nanog-bounces+kvicknair=reservetele@nanog.org] On 
Behalf Of Roland Dobbins
Sent: Friday, May 26, 2017 12:20 PM
To: nanog@nanog.org
Subject: Re: BCP38/84 and DDoS ACLs


On 26 May 2017, at 22:39, Graham Johnston wrote:

> I am looking for information regarding standard ACLs that operators
> may be using at the internet edge of their network, on peering and
> transit connections,

These .pdf presos may be of interest:

<https://app.box.com/s/ko8lk4vlh1835p36na3u>

<https://app.box.com/s/xznjloitly2apixr5xge>

They talk about iACL and tACL design philosophy.

What traffic you should permit/deny on your network is, of course, 
situationally-specific.  Depends on what kind of network it is, what 
servers/services/applications/users you have, et. al.  You may need one set of 
ACLs at the peering/transit edge, and other, more specific ACLs, at the IDC 
distribution gateway, customer aggregation gateway, et. al.

---
Roland Dobbins

Re: BCP38/84 and DDoS ACLs

2017-05-26 Thread Roland Dobbins 


On 26 May 2017, at 22:39, Graham Johnston wrote:

I am looking for information regarding standard ACLs that operators 
may be using at the internet edge of their network, on peering and 
transit connections,


These .pdf presos may be of interest:





They talk about iACL and tACL design philosophy.

What traffic you should permit/deny on your network is, of course, 
situationally-specific.  Depends on what kind of network it is, what 
servers/services/applications/users you have, et. al.  You may need one 
set of ACLs at the peering/transit edge, and other, more specific ACLs, 
at the IDC distribution gateway, customer aggregation gateway, et. al.


---
Roland Dobbins

Re: BCP38/84 and DDoS ACLs

2017-05-26 Thread Compton, Rich A 
To block UDP port 19 you can add something like:
deny udp any eq 19 any
deny udp any any eq 19

This will prevent the DDoS attack traffic entering your network (source
port 19) as well as the hosts scanning around looking for hosts on your
network that can be used in amplification attacks (destination port 19).
Please note that this will not block the UDP fragments that come with
these attacks which have no L4 port to block.  You can possibly do
policing on UDP fragments to address this.

I¹d also suggest adding:
deny udp any eq 17 any
deny udp any any eq 17

deny udp any eq 123 any packet-length eq 468

deny udp any eq 520 any
deny udp any any eq 520

deny udp any eq 1900 any
deny udp any any eq 1900

Some people will complain that you shouldn¹t block UDP port 1900 because
it¹s above 1023 but believe me it¹s worth it.



also to block invalid source IPs to prevent some spoofed traffic from
coming into your network:

deny ipv4 0.0.0.0 0.255.255.255 any
deny ipv4 10.0.0.0 0.255.255.255 any
deny ipv4 11.0.0.0 0.255.255.255 any
deny ipv4 22.0.0.0 0.255.255.255 any
deny ipv4 30.0.0.0 0.255.255.255 any
deny ipv4 100.64.0.0 0.63.255.255 any
deny ipv4 127.0.0.0 0.255.255.255 any
deny ipv4 169.254.0.0 0.0.255.255 any
deny ipv4 172.16.0.0 0.15.255.255 any
deny ipv4 192.0.0.0 0.0.0.255 any
deny ipv4 192.0.2.0 0.0.0.255 any
deny ipv4 192.168.0.0 0.0.255.255 any
deny ipv4 198.18.0.0 0.1.255.255 any
deny ipv4 198.51.0.0 0.0.0.255 any
deny ipv4 203.0.113.0 0.0.0.255 any
deny ipv4 224.0.0.0 31.255.255.255 any


For BCP38 and 84 you would want to enable uRPF
https://en.wikipedia.org/wiki/Reverse_path_forwarding
https://tools.ietf.org/html/rfc3704



Rich Compton   | Principal Eng |   314.596.2828
14810 Grasslands  Dr,Englewood,  CO80112






On 5/26/17, 11:39 AM, "NANOG on behalf of Graham Johnston"
 wrote:

>I really did try looking before I sent the email but couldn't quickly
>find what I was looking for.
>
>I am looking for information regarding standard ACLs that operators may
>be using at the internet edge of their network, on peering and transit
>connections, wherein you are filtering ingress packets such as those
>sourced from UDP port 19 for instance. I've found incomplete conceptual
>discussions about it nothing that seemed concrete or complete.
>
>This doesn't seem quite like it is BCP38 and more like this is BCP84, but
>it only talks about use of ACLs in section 2.1 without providing any
>examples. Given that it is also 13 years old I thought there might be
>fresher information out there.
>
>Thanks,
>graham 

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

BCP38/84 and DDoS ACLs

2017-05-26 Thread Graham Johnston 
I really did try looking before I sent the email but couldn't quickly find what 
I was looking for.

I am looking for information regarding standard ACLs that operators may be 
using at the internet edge of their network, on peering and transit 
connections, wherein you are filtering ingress packets such as those sourced 
from UDP port 19 for instance. I've found incomplete conceptual discussions 
about it nothing that seemed concrete or complete.

This doesn't seem quite like it is BCP38 and more like this is BCP84, but it 
only talks about use of ACLs in section 2.1 without providing any examples. 
Given that it is also 13 years old I thought there might be fresher information 
out there.

Thanks,
graham