(IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
Hi, All, Recently, I happened to participate in an IPv6 deployment meeting with some large content provider, and said meeting included a discussion about how to mitigate some attacks using block-lists. These folks argued that they ban offending IPv6 addresses as /128s, following IPv4 practices. So it seemed to me that some of the implications arising from the increased IPv6 address space were non-obvious to them. -- that has been the motivation for the publication of this document. * TXT: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt * HTML: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.html Comments welcome! P.S.: The document is targeted at the IETF opsec wg (https://www.ietf.org/mailman/listinfo/opsec), but I'll be happy to discuss it on this mailing-list, off-list, or at the opsec wg mailing-list... Thanks! Regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt Date: Thu, 02 Feb 2023 19:48:40 -0800 From: internet-drafts@ietf.org To: Fernando Gont <fgont@si6networks.com>, Guillermo Gont <ggont@si6networks.com> A new version of I-D, draft-gont-opsec-ipv6-addressing-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-opsec-ipv6-addressing Revision: 00 Title: Implications of IPv6 Addressing on Security Operations Document date: 2023-02-02 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-addressing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-opsec-ipv6-addressing Abstract: The increased address availability provided by IPv6 has concrete implications on security operations. This document discusses such implications, and sheds some light on how existing security operations techniques and procedures might need to be modified accommodate the increased IPv6 address availability. The IETF Secretariat
As long as they have a reasonable expiry process, it could work. After all, they’re only collecting addresses to ban at the rate they’re actually being used to send packets. While that’s nota. Completely effective throttle, as long as your expiry process can keep up and your TTL doesn’t exceed your ring buffer size, it should be theoretically OK. Owen
On Feb 5, 2023, at 02:44, Fernando Gont <fgont@si6networks.com> wrote:
Hi, All,
Recently, I happened to participate in an IPv6 deployment meeting with some large content provider, and said meeting included a discussion about how to mitigate some attacks using block-lists. These folks argued that they ban offending IPv6 addresses as /128s, following IPv4 practices.
So it seemed to me that some of the implications arising from the increased IPv6 address space were non-obvious to them. -- that has been the motivation for the publication of this document.
* TXT: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt * HTML: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.html
Comments welcome!
P.S.: The document is targeted at the IETF opsec wg (https://www.ietf.org/mailman/listinfo/opsec), but I'll be happy to discuss it on this mailing-list, off-list, or at the opsec wg mailing-list...
Thanks!
Regards, Fernando
-------- Forwarded Message -------- Subject: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt Date: Thu, 02 Feb 2023 19:48:40 -0800 From: internet-drafts@ietf.org To: Fernando Gont <fgont@si6networks.com>, Guillermo Gont <ggont@si6networks.com>
A new version of I-D, draft-gont-opsec-ipv6-addressing-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository.
Name: draft-gont-opsec-ipv6-addressing Revision: 00 Title: Implications of IPv6 Addressing on Security Operations Document date: 2023-02-02 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-addressing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-opsec-ipv6-addressing
Abstract: The increased address availability provided by IPv6 has concrete implications on security operations. This document discusses such implications, and sheds some light on how existing security operations techniques and procedures might need to be modified accommodate the increased IPv6 address availability.
The IETF Secretariat
Hi, Owen, On 6/2/23 20:39, Owen DeLong wrote:
As long as they have a reasonable expiry process, it could work.
What, specifically? Banning /128s?
After all, they’re only collecting addresses to ban at the rate they’re actually being used to send packets.
Yeah, but the whole point of banning is that the banned address is actually used by an attacker subsequently, In other words, if: 1. The attacker employs one address for malicious purposes 2. You ban that address 3. The attacker changes the his/her address and goes back to #1 ... you´d be doing yourself a disservice by adding addresses to the ban-list. You just pay penalties for no actual gain.
While that’s nota. Completely effective throttle, as long as your expiry process can keep up and your TTL doesn’t exceed your ring buffer size, it should be theoretically OK.
Memory is a limited resource. As soon as you consistently use memory iptables-rules slot to store more and more rules/addresses youĺl get no benefit from, the attacker is winning.... Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
On Mon, Feb 6, 2023 at 6:43 PM Fernando Gont <fgont@si6networks.com> wrote:
On 6/2/23 20:39, Owen DeLong wrote:
After all, they’re only collecting addresses to ban at the rate they’re actually being used to send packets.
Yeah, but the whole point of banning is that the banned address is actually used by an attacker subsequently,
You both have valuable points here. Listen to each other. On the one hand, sophisticated attackers already scatter attacks between source addresses to evade protection software. Attackers who don't have control over their computer's IP address do not. This is not new and IPv6 does not really change that picture. On the other hand, there are so many addresses in a /64 that an attacker can literally use a fresh one for each and every probe he sends. Without a process for advancing the /128 ban to a /64 ban (and releasing it once activity stops), reactive firewalls are likely to become less and less effective. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Hi, Bill, Thanks for your feedback! In-line.... On 7/2/23 00:05, William Herrin wrote:
On Mon, Feb 6, 2023 at 6:43 PM Fernando Gont <fgont@si6networks.com> wrote:
On 6/2/23 20:39, Owen DeLong wrote:
After all, they’re only collecting addresses to ban at the rate they’re actually being used to send packets.
Yeah, but the whole point of banning is that the banned address is actually used by an attacker subsequently,
You both have valuable points here. Listen to each other.
On the one hand, sophisticated attackers already scatter attacks between source addresses to evade protection software. Attackers who don't have control over their computer's IP address do not. This is not new and IPv6 does not really change that picture.
... although the ability to change IP addresses in IPv4 is rather limited. -- e.g., if I want do do it at home, I could do a DHCP release and try to get a different lease.. but not very practical -- and certainly not possible in a e.g. cafe scenario. Whereas in the IPv6 case , you normally have at least a /64 without restriction. You might have a /56 or /48 thanks to your ISP, or simply a /48 thanks to some free tunnelbroker provider...
On the other hand, there are so many addresses in a /64 that an attacker can literally use a fresh one for each and every probe he sends. Without a process for advancing the /128 ban to a /64 ban (and releasing it once activity stops), reactive firewalls are likely to become less and less effective.
Not just /128 to /64, but also e.g. /64 to /56 or possibly /48... Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
On Mon, Feb 6, 2023 at 7:40 PM Fernando Gont <fgont@si6networks.com> wrote:
On 7/2/23 00:05, William Herrin wrote:
On the one hand, sophisticated attackers already scatter attacks between source addresses to evade protection software.
Whereas in the IPv6 case , you normally have at least a /64 without restriction. You might have a /56 or /48 thanks to your ISP, or simply a /48 thanks to some free tunnelbroker provider...
That's not what's actually happening. What's happening is a mix of your computer gets one address unless you bother to enable DHCP/PD, or your CPE gets an IPv6 block and your computer does SLAAC and/or DHCP to assign itself a single IPv6 address. A lot of the probing is coming from hijacked computers, so they have the address they have. Sophisticated attackers can do more with the address blocks they get from their own service providers. But sophisticated attackers could spin up VMs with stolen credit cards, hijack BGP and do all manner of things with IPv4 and IPv6 too.
On the other hand, there are so many addresses in a /64 that an attacker can literally use a fresh one for each and every probe he sends. Without a process for advancing the /128 ban to a /64 ban (and releasing it once activity stops), reactive firewalls are likely to become less and less effective.
Not just /128 to /64, but also e.g. /64 to /56 or possibly /48...
Maybe. But I suggest that in the absence of data about how such attacks will evolve, it might be best to start with a version of a defense that's easy to conceptualize and implement. Risk is vulnerability times threat. You already understand the vulnerability. Before expending much in the way of resources, you also have to understand the threat. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
Hi, Bill, On 7/2/23 01:26, William Herrin wrote:
On Mon, Feb 6, 2023 at 7:40 PM Fernando Gont <fgont@si6networks.com> wrote:
On 7/2/23 00:05, William Herrin wrote:
On the one hand, sophisticated attackers already scatter attacks between source addresses to evade protection software.
Whereas in the IPv6 case , you normally have at least a /64 without restriction. You might have a /56 or /48 thanks to your ISP, or simply a /48 thanks to some free tunnelbroker provider...
That's not what's actually happening.
Well, this *is* happening. -- trust me :-)
What's happening is a mix of your computer gets one address unless you bother to enable DHCP/PD, or your CPE gets an IPv6 block and your computer does SLAAC and/or DHCP to assign itself a single IPv6 address. A lot of the probing is coming from hijacked computers, so they have the address they have.
Sophisticated attackers can do more with the address blocks they get from their own service providers. But sophisticated attackers could spin up VMs with stolen credit cards, hijack BGP and do all manner of things with IPv4 and IPv6 too.
You can use a /48 pretty legitimately without stealing any credit cards or spinning extra VMs... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Anecdotal but I've seen hacked AWS accounts with Cloudformation scripts to create and destroy lots of tiny instances to rotate through IPv4 addresses. Being able to rotate through IP addresses is not a new thing, I'm sure we all have networks in mind when we think of garbage/malicious traffic just over IPv4 alone. Internally at my company (corp network that went all in on IPv6), we have a script that looks through logs and will ban an entire /64 for a period of time if it has more than a few banned IP addresses in the same subnet (I think ~10 /128s is a 30 minute ban, but we're still tuning it). There are some strange implementations of IPv6 that end up having a lot of dissociated users grouped together in a /64 (i.e. Linode, AT&T Wireless, etc) which makes me hesitant to implement automatic /64 bans for 1 or 2 spammy IP addresses. At one point we accidentally banned a large portion of US users on AT&T when we banned 2600:387:f:10::/64 On 2/6/2023 10:05 PM, William Herrin wrote:
On Mon, Feb 6, 2023 at 6:43 PM Fernando Gont <fgont@si6networks.com> wrote:
On 6/2/23 20:39, Owen DeLong wrote:
After all, they’re only collecting addresses to ban at the rate they’re actually being used to send packets. Yeah, but the whole point of banning is that the banned address is actually used by an attacker subsequently, You both have valuable points here. Listen to each other.
On the one hand, sophisticated attackers already scatter attacks between source addresses to evade protection software. Attackers who don't have control over their computer's IP address do not. This is not new and IPv6 does not really change that picture.
On the other hand, there are so many addresses in a /64 that an attacker can literally use a fresh one for each and every probe he sends. Without a process for advancing the /128 ban to a /64 ban (and releasing it once activity stops), reactive firewalls are likely to become less and less effective.
Regards, Bill Herrin
----- On Feb 7, 2023, at 4:20 PM, nanog nanog@nanog.org wrote: Hi,
Anecdotal but I've seen hacked AWS accounts with Cloudformation scripts to create and destroy lots of tiny instances to rotate through IPv4 addresses.
If only AWS would care about hacked AWS accounts. Thanks, Sabri
On 7/2/23 21:43, Sabri Berisha wrote:
----- On Feb 7, 2023, at 4:20 PM, nanog nanog@nanog.org wrote:
Hi,
Anecdotal but I've seen hacked AWS accounts with Cloudformation scripts to create and destroy lots of tiny instances to rotate through IPv4 addresses.
If only AWS would care about hacked AWS accounts.
Do they lose or earn money when accounts are hacked? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
----- On Feb 7, 2023, at 5:04 PM, Fernando Gont fgont@si6networks.com wrote:
On 7/2/23 21:43, Sabri Berisha wrote:
----- On Feb 7, 2023, at 4:20 PM, nanog nanog@nanog.org wrote:
Hi,
Anecdotal but I've seen hacked AWS accounts with Cloudformation scripts to create and destroy lots of tiny instances to rotate through IPv4 addresses.
If only AWS would care about hacked AWS accounts.
Do they lose or earn money when accounts are hacked?
I guess that depends if the credit card on file is expired... Thanks, Sabri
Hi, Daniel, On 7/2/23 21:20, Daniel Marks via NANOG wrote:
Anecdotal but I've seen hacked AWS accounts with Cloudformation scripts to create and destroy lots of tiny instances to rotate through IPv4 addresses.
As with everything, the question is always "what's the level of effort that is required". If an attacker is given the option to: 1) Hack an AWS account, and then script the creation of through-away VMs just to be able to change the IP address each time, or, 2) Stay on the same machine, and be able to (even legitimately) use 2**64 addresses without even the need to hack any terraform scripts They will probably go for #2. And aside of their choices, #1 requires more skills than #2.
Being able to rotate through IP addresses is not a new thing, I'm sure we all have networks in mind when we think of garbage/malicious traffic just over IPv4 alone.
The difference is in the scale at which this is possible with IPv6, and how high (or low) the bar is to do it.
There are some strange implementations of IPv6 that end up having a lot of dissociated users grouped together in a /64 (i.e. Linode, AT&T Wireless, etc)
Therein probably lies some good advice .. i.e., that to the extent that is possible, folks refrain from sharing the same /64 across unrelated/disassociated users. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
On Feb 6, 2023, at 18:43, Fernando Gont <fgont@si6networks.com> wrote:
Hi, Owen,
On 6/2/23 20:39, Owen DeLong wrote:
As long as they have a reasonable expiry process, it could work.
What, specifically? Banning /128s?
Yes.
After all, they’re only collecting addresses to ban at the rate they’re actually being used to send packets.
Yeah, but the whole point of banning is that the banned address is actually used by an attacker subsequently,
In other words, if:
1. The attacker employs one address for malicious purposes 2. You ban that address 3. The attacker changes the his/her address and goes back to #1
... you´d be doing yourself a disservice by adding addresses to the ban-list. You just pay penalties for no actual gain.
Sure, but there are lots of human endeavors where this is par for the course… Consider voting for legislators in the US, for example. No matter what we do, this is always going to boil down to a contest of intellect between the attackers and the targets. There’s a limit to the extent to which we can effectively solve stupid on the side of the targets.
While that’s nota. Completely effective throttle, as long as your expiry process can keep up and your TTL doesn’t exceed your ring buffer size, it should be theoretically OK.
Memory is a limited resource. As soon as you consistently use memory iptables-rules slot to store more and more rules/addresses youĺl get no benefit from, the attacker is winning....
No argument here… See above. I wasn’t advocating the mechanism, just kind of making fun of the theory behind it. Sorry if the sarcasm wasn’t clear. Owen
participants (5)
-
Daniel Marks -
Fernando Gont -
Owen DeLong -
Sabri Berisha -
William Herrin