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
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, CO 80112 On 5/26/17, 11:39 AM, "NANOG on behalf of Graham Johnston" <nanog-bounces@nanog.org on behalf of johnstong@westmancom.com> 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.
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" <Rich.Compton@charter.com> 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, CO 80112
On 5/26/17, 11:39 AM, "NANOG on behalf of Graham Johnston" <nanog-bounces@nanog.org on behalf of johnstong@westmancom.com> 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.
-----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: <http://www.team-cymru.org/bogon-reference.html> 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-----
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 <rdobbins@arbor.net>
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: kvicknair@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.com@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 <rdobbins@arbor.net>
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
On 5/26/17 10:24, Kody Vicknair wrote: 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: kvicknair@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.com@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 <rdobbins@arbor.net>
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".
On 27 May 2017, at 0:19, Roland Dobbins wrote:
This is the correct URI for the first preso, apologies: <https://app.box.com/s/osk4po8ietn1zrjjmn8b> ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
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
participants (9)
-
Compton, Rich A -
Dave Bell -
Graham Johnston -
joel jaeggli -
Kody Vicknair -
Rabbi Rob Thomas -
Randy Bush -
Roland Dobbins -
valdis.kletnieks＠vt.edu