How discoverable are IPv6 addresses and AAAA names by potential attackers? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) Come Celebrate our 10 Year Anniversary!IPv6 replacement for scanning IP rangeDNS, subdomain, and IPv6 — possible to add subdomain.example.com NS record to an IPv6 host?Issues resolving local domain name with Windows 7Does Windows try to look for IPv6 AAAA records even when it does not have a routable IPv6 address?Win2k8R2 Obtaining DHCPv6 address, but has static configurationWindows 7 laptop with two active network connections will not perform DNS AAAA lookup under certain conditionsGetting DNS replies for non-existing hostnames (DNSMasq)Some workstations/servers on the domain respond with IPv6 instead of IPv4 addresses, even though IPv6 is disabled across the boardUnable to ping computers via DNS domain nameHow to disable AAAA lookups?How can I identify a rogue IPv6 DHCP server on my LAN?
Trademark violation for app?
How do I find out the mythology and history of my Fortress?
Is it common practice to audition new musicians 1-2-1 before rehearsing with the entire band?
What is the longest distance a player character can jump in one leap?
Generate an RGB colour grid
For a new assistant professor in CS, how to build/manage a publication pipeline
Delete nth line from bottom
Fundamental Solution of the Pell Equation
An adverb for when you're not exaggerating
Why are there no cargo aircraft with "flying wing" design?
Is there a kind of relay only consumes power when switching?
Is there any way for the UK Prime Minister to make a motion directly dependent on Government confidence?
Significance of Cersei's obsession with elephants?
Is safe to use va_start macro with this as parameter?
Crossing US/Canada Border for less than 24 hours
Compare a given version number in the form major.minor.build.patch and see if one is less than the other
Using et al. for a last / senior author rather than for a first author
Why are both D and D# fitting into my E minor key?
How to tell that you are a giant?
Do I really need to have a message in a novel to appeal to readers?
Integration Help
Where are Serre’s lectures at Collège de France to be found?
Is it a good idea to use CNN to classify 1D signal?
Is the Standard Deduction better than Itemized when both are the same amount?
How discoverable are IPv6 addresses and AAAA names by potential attackers?
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
Come Celebrate our 10 Year Anniversary!IPv6 replacement for scanning IP rangeDNS, subdomain, and IPv6 — possible to add subdomain.example.com NS record to an IPv6 host?Issues resolving local domain name with Windows 7Does Windows try to look for IPv6 AAAA records even when it does not have a routable IPv6 address?Win2k8R2 Obtaining DHCPv6 address, but has static configurationWindows 7 laptop with two active network connections will not perform DNS AAAA lookup under certain conditionsGetting DNS replies for non-existing hostnames (DNSMasq)Some workstations/servers on the domain respond with IPv6 instead of IPv4 addresses, even though IPv6 is disabled across the boardUnable to ping computers via DNS domain nameHow to disable AAAA lookups?How can I identify a rogue IPv6 DHCP server on my LAN?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
It is fairly standard to receive a significant number of minor hacking attempts each day trying common username / passwords for services like SSH and SMTP. I've always assumed these attempts are using the "small" address space of IPv4 to guess IP addresses. I notice that I get zero hacking attempts on IPv6 despite my domain having AAAA Name records mirroring every A Name record and all IPv4 services are also open to IPv6.
Assuming a public DNS (AWS route 53) with an obscure subdomain pointing to a reasonably randomised /64 suffix; Are IPv6 addresses and / subdomains remotely discoverable without trying every address in a /64 bit prefix or every subdomain in a very long list of common names?
I am of course aware that crawling the web looking for listed (sub)domain names is simple enough. I'm also aware that machines on the same subnet can use NDP. I'm more interested in whether DNS or the underlying protocols of IPv6 allow discovery / listing unknown domains and addresses by remote.
domain-name-system ipv6 autodiscovery discovery
add a comment |
It is fairly standard to receive a significant number of minor hacking attempts each day trying common username / passwords for services like SSH and SMTP. I've always assumed these attempts are using the "small" address space of IPv4 to guess IP addresses. I notice that I get zero hacking attempts on IPv6 despite my domain having AAAA Name records mirroring every A Name record and all IPv4 services are also open to IPv6.
Assuming a public DNS (AWS route 53) with an obscure subdomain pointing to a reasonably randomised /64 suffix; Are IPv6 addresses and / subdomains remotely discoverable without trying every address in a /64 bit prefix or every subdomain in a very long list of common names?
I am of course aware that crawling the web looking for listed (sub)domain names is simple enough. I'm also aware that machines on the same subnet can use NDP. I'm more interested in whether DNS or the underlying protocols of IPv6 allow discovery / listing unknown domains and addresses by remote.
domain-name-system ipv6 autodiscovery discovery
Related: IPv6 replacement for scanning IP range
– Michael Hampton♦
2 days ago
This looks like security by obscurity... If your only line of defense is using (supposedly) hard to discover identifiers (either names or IP addresses) then you can expect to be breached at some point. You may be relatively safe against generic exploits/random pokes, but if you have to defend against active attacks on you then that line of defence breaks. There is a ton of possible ways to discover "obscure" names, look at geekflare.com/find-subdomains for a start
– Patrick Mevzek
yesterday
2
@patrick If you have only a single line of defense you are getting breached period. I still don't want my locked doors advertised to the whole world
– Philip Couling
yesterday
So by your own conclusion you are breached and you should setup your systems and their security differently.
– Patrick Mevzek
yesterday
1
No. By my own conclusion this is not my only line of security. I never suggested otherwise.
– Philip Couling
yesterday
add a comment |
It is fairly standard to receive a significant number of minor hacking attempts each day trying common username / passwords for services like SSH and SMTP. I've always assumed these attempts are using the "small" address space of IPv4 to guess IP addresses. I notice that I get zero hacking attempts on IPv6 despite my domain having AAAA Name records mirroring every A Name record and all IPv4 services are also open to IPv6.
Assuming a public DNS (AWS route 53) with an obscure subdomain pointing to a reasonably randomised /64 suffix; Are IPv6 addresses and / subdomains remotely discoverable without trying every address in a /64 bit prefix or every subdomain in a very long list of common names?
I am of course aware that crawling the web looking for listed (sub)domain names is simple enough. I'm also aware that machines on the same subnet can use NDP. I'm more interested in whether DNS or the underlying protocols of IPv6 allow discovery / listing unknown domains and addresses by remote.
domain-name-system ipv6 autodiscovery discovery
It is fairly standard to receive a significant number of minor hacking attempts each day trying common username / passwords for services like SSH and SMTP. I've always assumed these attempts are using the "small" address space of IPv4 to guess IP addresses. I notice that I get zero hacking attempts on IPv6 despite my domain having AAAA Name records mirroring every A Name record and all IPv4 services are also open to IPv6.
Assuming a public DNS (AWS route 53) with an obscure subdomain pointing to a reasonably randomised /64 suffix; Are IPv6 addresses and / subdomains remotely discoverable without trying every address in a /64 bit prefix or every subdomain in a very long list of common names?
I am of course aware that crawling the web looking for listed (sub)domain names is simple enough. I'm also aware that machines on the same subnet can use NDP. I'm more interested in whether DNS or the underlying protocols of IPv6 allow discovery / listing unknown domains and addresses by remote.
domain-name-system ipv6 autodiscovery discovery
domain-name-system ipv6 autodiscovery discovery
edited yesterday
Philip Couling
asked 2 days ago
Philip CoulingPhilip Couling
1,0191023
1,0191023
Related: IPv6 replacement for scanning IP range
– Michael Hampton♦
2 days ago
This looks like security by obscurity... If your only line of defense is using (supposedly) hard to discover identifiers (either names or IP addresses) then you can expect to be breached at some point. You may be relatively safe against generic exploits/random pokes, but if you have to defend against active attacks on you then that line of defence breaks. There is a ton of possible ways to discover "obscure" names, look at geekflare.com/find-subdomains for a start
– Patrick Mevzek
yesterday
2
@patrick If you have only a single line of defense you are getting breached period. I still don't want my locked doors advertised to the whole world
– Philip Couling
yesterday
So by your own conclusion you are breached and you should setup your systems and their security differently.
– Patrick Mevzek
yesterday
1
No. By my own conclusion this is not my only line of security. I never suggested otherwise.
– Philip Couling
yesterday
add a comment |
Related: IPv6 replacement for scanning IP range
– Michael Hampton♦
2 days ago
This looks like security by obscurity... If your only line of defense is using (supposedly) hard to discover identifiers (either names or IP addresses) then you can expect to be breached at some point. You may be relatively safe against generic exploits/random pokes, but if you have to defend against active attacks on you then that line of defence breaks. There is a ton of possible ways to discover "obscure" names, look at geekflare.com/find-subdomains for a start
– Patrick Mevzek
yesterday
2
@patrick If you have only a single line of defense you are getting breached period. I still don't want my locked doors advertised to the whole world
– Philip Couling
yesterday
So by your own conclusion you are breached and you should setup your systems and their security differently.
– Patrick Mevzek
yesterday
1
No. By my own conclusion this is not my only line of security. I never suggested otherwise.
– Philip Couling
yesterday
Related: IPv6 replacement for scanning IP range
– Michael Hampton♦
2 days ago
Related: IPv6 replacement for scanning IP range
– Michael Hampton♦
2 days ago
This looks like security by obscurity... If your only line of defense is using (supposedly) hard to discover identifiers (either names or IP addresses) then you can expect to be breached at some point. You may be relatively safe against generic exploits/random pokes, but if you have to defend against active attacks on you then that line of defence breaks. There is a ton of possible ways to discover "obscure" names, look at geekflare.com/find-subdomains for a start
– Patrick Mevzek
yesterday
This looks like security by obscurity... If your only line of defense is using (supposedly) hard to discover identifiers (either names or IP addresses) then you can expect to be breached at some point. You may be relatively safe against generic exploits/random pokes, but if you have to defend against active attacks on you then that line of defence breaks. There is a ton of possible ways to discover "obscure" names, look at geekflare.com/find-subdomains for a start
– Patrick Mevzek
yesterday
2
2
@patrick If you have only a single line of defense you are getting breached period. I still don't want my locked doors advertised to the whole world
– Philip Couling
yesterday
@patrick If you have only a single line of defense you are getting breached period. I still don't want my locked doors advertised to the whole world
– Philip Couling
yesterday
So by your own conclusion you are breached and you should setup your systems and their security differently.
– Patrick Mevzek
yesterday
So by your own conclusion you are breached and you should setup your systems and their security differently.
– Patrick Mevzek
yesterday
1
1
No. By my own conclusion this is not my only line of security. I never suggested otherwise.
– Philip Couling
yesterday
No. By my own conclusion this is not my only line of security. I never suggested otherwise.
– Philip Couling
yesterday
add a comment |
3 Answers
3
active
oldest
votes
Malicious bots don't guess IPv4 addresses anymore. They simply try them all. On modern systems this can take as little as a few hours.
With IPv6, this is not really possible any longer, as you've surmised. The address space is so much larger that it's not even possible to brute-force scan a single /64 subnet within a human lifetime.
Bots will have to get more creative if they are to continue blind scanning on IPv6 as on IPv4, and malicious bot operators will have to get accustomed to waiting far longer between finding any machines, let alone vulnerable ones.
Fortunately for the bad guys and unfortunately for everyone else, IPv6 adoption has gone much more slowly than it really should have. IPv6 is 23 years old but has only seen significant adoption in the last five years or so. But everyone is keeping their IPv4 networks active, and extremely few hosts are IPv6-only, so malicious bot operators have had little incentive to make the switch. They probably won't do until there is a significant abandonment of IPv4, which probably won't happen in the next five years.
I expect that blind guessing probably won't be productive for malicious bots, when they finally do move to IPv6, so they'll have to move to other means, like brute-forcing DNS names, or targeted brute-forcing of small subsets of each subnet.
For instance, a common DHCPv6 server configuration gives out addresses in ::100
through ::1ff
by default. That's just 256 addresses to try, out of a whole /64. Reconfiguring the DHCPv6 server to pick addresses from a much larger range mitigates this problem.
And using modified EUI-64 addresses for SLAAC reduces the search space to 224 multiplied by the number of assigned OUIs. While this is over 100 billion addresses, it's far less than 264. Random bots won't bother to search this space, but state-level malicious actors will, for targeted attacks, especially if they can make educated guesses as to which NICs might be in use, to reduce the search space further. Using RFC 7217 stable privacy addresses for SLAAC is easy (at least on modern operating systems that support it) and mitigates this risk.
RFC 7707 describes several other ways in which reconnaissance might be performed in IPv6 networks to locate IPv6 addresses, and how to mitigate against those threats.
Many bots are VERY creative already, and there is likely a huge black market for the better bots, probably with bundled access to their bot net while they're at it. The bots that are not creative should be easily blocked by whatever method you block the creative ones with.
– BeowulfNode42
yesterday
1
Most of what I see is the non-creative variety of bot. Though it's the creative variety that keeps me up at night. Fortunately I have a client who pays me to lose sleep over them. That said, I'm yet to see any significant bot traffic on IPv6, creative or not.
– Michael Hampton♦
yesterday
Yes I have more recently noticed the bruit force attempts are spread across months (a username or password per day) suggesting each single username or password is tried against every public facing SSH server on the (IPv4) Internet before moving onto the next username or password.
– Philip Couling
yesterday
add a comment |
Regarding AAAA records:
DNS is traditionally unencrypted. While there is a family of standards (DNSSEC) for signing DNS, the encryption of DNS records has had a far more haphazard deployment process, and so it is generally safest to assume that any MitM can read all of your DNS queries unless you have gone out of your way to configure encrypted DNS explicitly on the client side. You would know if you had done so because it's quite an ordeal.
(Also, your web browser is probably sending unencrypted SNI in the TLS handshake, after it has resolved the domain. It is not obvious how you would go about plugging this hole, since a VPN or Tor can still be MitM'd between the exit node or VPN termination point and the remote server. The good folks at Cloudflare are working on fixing this problem for good, but ESNI will also depend on client implementation, particularly for Chrome, if it's going to really get off the ground.)
However, MitM attacks may or may not be a problem, depending on your threat model. More important is the simple fact that DNS names are intended to be public information. Lots of people (search engines, DNS registrars, etc.) collect and publicize DNS names for entirely benign reasons. DNS resolvers typically apply rate limits, but these limits are usually quite generous, because they're meant to stop DoS attacks, not subdomain enumeration. Creating an HTTPS certificate often involves publishing the domain name for all to see, depending on the CA (Let's Encrypt does it, and so do many others). In practice, it is quite impossible to keep a domain or subdomain a secret, because just about everyone assumes they are public and makes no effort to hide them.
So, to answer this question:
I'm more interested in whether DNS or the underlying protocols of IPv6 allow discovery / listing unknown domains and addresses by remote.
Technically, no, it doesn't. But that does not matter because an enormous amount of higher-layer technology just assumes your DNS records are public, so public they will inevitably be.
1
Encrypted SNI is under development. Give it a year or two.
– Michael Hampton♦
yesterday
1
@MichaelHampton: I believe that ESNI will happen. But given the industry's track record (DNSSEC, IPv6, DANE, ...) I'm a bit skeptical that "a year or two" will truly be sufficient. Regardless, we shall see soon enough.
– Kevin
yesterday
1
CloudFlare is pushing it so I'll bet on sooner rather than later :)
– Michael Hampton♦
yesterday
I find myself wanting to say "yes but..." to each of your specific examples however it is a very good point that DNS names are generally assumed to be public information. +1
– Philip Couling
yesterday
add a comment |
I've found that MANY bots these days are not guessing, with IPv4 or IPv6. Security through obscurity is not security at all. Obscurity simply delays / reduces the number of attacks for a while, and then it is irrelevant.
Hackers know your company's domain name from your website or email address, what public server IPs you publish for things like email, SPF, web servers, etc. Though it may take them a bit longer to learn a random server name, but they will guess the common names, like www, mail, smtp, imap, pop, pop3, ns1, etc, and then scrape your website for any additional data they can find. They will retrieve from their store of previous scans your DNS names, IPs and what ports to focus on. They will also retrieve a list of email address / password pairs from any data breaches they can find and try all of those logins plus some extra ones with whatever systems they think you are running on your ports. They even go to the extent of learning the names and job roles of your staff to try and execute a social engineered attack. Our spam filter is continuously bombarded with attempts by scammers claiming to be someone from management needing an urgent wire transfer of funds. Oh they also learn who your business partners are and claim to be them, and letting you know their bank details have changed. Sometimes they even know what cloud platforms your business partners are using for their invoicing.
Criminals have access to big data tools just the same as everyone else, and they have amassed a surprisingly huge amount of data. See this testimony by some IT professionals to US congress https://www.troyhunt.com/heres-what-im-telling-us-congress-about-data-breaches/
Talking about data breaches, if a company looses something even as seemingly useless as a web server log, this will contain IP addresses v4 or v6 of everyone who used that server at that time, and what pages they accessed.
In conclusion, none of those methods require an attacker to guess what IP you are using, they already know.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f963115%2fhow-discoverable-are-ipv6-addresses-and-aaaa-names-by-potential-attackers%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Malicious bots don't guess IPv4 addresses anymore. They simply try them all. On modern systems this can take as little as a few hours.
With IPv6, this is not really possible any longer, as you've surmised. The address space is so much larger that it's not even possible to brute-force scan a single /64 subnet within a human lifetime.
Bots will have to get more creative if they are to continue blind scanning on IPv6 as on IPv4, and malicious bot operators will have to get accustomed to waiting far longer between finding any machines, let alone vulnerable ones.
Fortunately for the bad guys and unfortunately for everyone else, IPv6 adoption has gone much more slowly than it really should have. IPv6 is 23 years old but has only seen significant adoption in the last five years or so. But everyone is keeping their IPv4 networks active, and extremely few hosts are IPv6-only, so malicious bot operators have had little incentive to make the switch. They probably won't do until there is a significant abandonment of IPv4, which probably won't happen in the next five years.
I expect that blind guessing probably won't be productive for malicious bots, when they finally do move to IPv6, so they'll have to move to other means, like brute-forcing DNS names, or targeted brute-forcing of small subsets of each subnet.
For instance, a common DHCPv6 server configuration gives out addresses in ::100
through ::1ff
by default. That's just 256 addresses to try, out of a whole /64. Reconfiguring the DHCPv6 server to pick addresses from a much larger range mitigates this problem.
And using modified EUI-64 addresses for SLAAC reduces the search space to 224 multiplied by the number of assigned OUIs. While this is over 100 billion addresses, it's far less than 264. Random bots won't bother to search this space, but state-level malicious actors will, for targeted attacks, especially if they can make educated guesses as to which NICs might be in use, to reduce the search space further. Using RFC 7217 stable privacy addresses for SLAAC is easy (at least on modern operating systems that support it) and mitigates this risk.
RFC 7707 describes several other ways in which reconnaissance might be performed in IPv6 networks to locate IPv6 addresses, and how to mitigate against those threats.
Many bots are VERY creative already, and there is likely a huge black market for the better bots, probably with bundled access to their bot net while they're at it. The bots that are not creative should be easily blocked by whatever method you block the creative ones with.
– BeowulfNode42
yesterday
1
Most of what I see is the non-creative variety of bot. Though it's the creative variety that keeps me up at night. Fortunately I have a client who pays me to lose sleep over them. That said, I'm yet to see any significant bot traffic on IPv6, creative or not.
– Michael Hampton♦
yesterday
Yes I have more recently noticed the bruit force attempts are spread across months (a username or password per day) suggesting each single username or password is tried against every public facing SSH server on the (IPv4) Internet before moving onto the next username or password.
– Philip Couling
yesterday
add a comment |
Malicious bots don't guess IPv4 addresses anymore. They simply try them all. On modern systems this can take as little as a few hours.
With IPv6, this is not really possible any longer, as you've surmised. The address space is so much larger that it's not even possible to brute-force scan a single /64 subnet within a human lifetime.
Bots will have to get more creative if they are to continue blind scanning on IPv6 as on IPv4, and malicious bot operators will have to get accustomed to waiting far longer between finding any machines, let alone vulnerable ones.
Fortunately for the bad guys and unfortunately for everyone else, IPv6 adoption has gone much more slowly than it really should have. IPv6 is 23 years old but has only seen significant adoption in the last five years or so. But everyone is keeping their IPv4 networks active, and extremely few hosts are IPv6-only, so malicious bot operators have had little incentive to make the switch. They probably won't do until there is a significant abandonment of IPv4, which probably won't happen in the next five years.
I expect that blind guessing probably won't be productive for malicious bots, when they finally do move to IPv6, so they'll have to move to other means, like brute-forcing DNS names, or targeted brute-forcing of small subsets of each subnet.
For instance, a common DHCPv6 server configuration gives out addresses in ::100
through ::1ff
by default. That's just 256 addresses to try, out of a whole /64. Reconfiguring the DHCPv6 server to pick addresses from a much larger range mitigates this problem.
And using modified EUI-64 addresses for SLAAC reduces the search space to 224 multiplied by the number of assigned OUIs. While this is over 100 billion addresses, it's far less than 264. Random bots won't bother to search this space, but state-level malicious actors will, for targeted attacks, especially if they can make educated guesses as to which NICs might be in use, to reduce the search space further. Using RFC 7217 stable privacy addresses for SLAAC is easy (at least on modern operating systems that support it) and mitigates this risk.
RFC 7707 describes several other ways in which reconnaissance might be performed in IPv6 networks to locate IPv6 addresses, and how to mitigate against those threats.
Many bots are VERY creative already, and there is likely a huge black market for the better bots, probably with bundled access to their bot net while they're at it. The bots that are not creative should be easily blocked by whatever method you block the creative ones with.
– BeowulfNode42
yesterday
1
Most of what I see is the non-creative variety of bot. Though it's the creative variety that keeps me up at night. Fortunately I have a client who pays me to lose sleep over them. That said, I'm yet to see any significant bot traffic on IPv6, creative or not.
– Michael Hampton♦
yesterday
Yes I have more recently noticed the bruit force attempts are spread across months (a username or password per day) suggesting each single username or password is tried against every public facing SSH server on the (IPv4) Internet before moving onto the next username or password.
– Philip Couling
yesterday
add a comment |
Malicious bots don't guess IPv4 addresses anymore. They simply try them all. On modern systems this can take as little as a few hours.
With IPv6, this is not really possible any longer, as you've surmised. The address space is so much larger that it's not even possible to brute-force scan a single /64 subnet within a human lifetime.
Bots will have to get more creative if they are to continue blind scanning on IPv6 as on IPv4, and malicious bot operators will have to get accustomed to waiting far longer between finding any machines, let alone vulnerable ones.
Fortunately for the bad guys and unfortunately for everyone else, IPv6 adoption has gone much more slowly than it really should have. IPv6 is 23 years old but has only seen significant adoption in the last five years or so. But everyone is keeping their IPv4 networks active, and extremely few hosts are IPv6-only, so malicious bot operators have had little incentive to make the switch. They probably won't do until there is a significant abandonment of IPv4, which probably won't happen in the next five years.
I expect that blind guessing probably won't be productive for malicious bots, when they finally do move to IPv6, so they'll have to move to other means, like brute-forcing DNS names, or targeted brute-forcing of small subsets of each subnet.
For instance, a common DHCPv6 server configuration gives out addresses in ::100
through ::1ff
by default. That's just 256 addresses to try, out of a whole /64. Reconfiguring the DHCPv6 server to pick addresses from a much larger range mitigates this problem.
And using modified EUI-64 addresses for SLAAC reduces the search space to 224 multiplied by the number of assigned OUIs. While this is over 100 billion addresses, it's far less than 264. Random bots won't bother to search this space, but state-level malicious actors will, for targeted attacks, especially if they can make educated guesses as to which NICs might be in use, to reduce the search space further. Using RFC 7217 stable privacy addresses for SLAAC is easy (at least on modern operating systems that support it) and mitigates this risk.
RFC 7707 describes several other ways in which reconnaissance might be performed in IPv6 networks to locate IPv6 addresses, and how to mitigate against those threats.
Malicious bots don't guess IPv4 addresses anymore. They simply try them all. On modern systems this can take as little as a few hours.
With IPv6, this is not really possible any longer, as you've surmised. The address space is so much larger that it's not even possible to brute-force scan a single /64 subnet within a human lifetime.
Bots will have to get more creative if they are to continue blind scanning on IPv6 as on IPv4, and malicious bot operators will have to get accustomed to waiting far longer between finding any machines, let alone vulnerable ones.
Fortunately for the bad guys and unfortunately for everyone else, IPv6 adoption has gone much more slowly than it really should have. IPv6 is 23 years old but has only seen significant adoption in the last five years or so. But everyone is keeping their IPv4 networks active, and extremely few hosts are IPv6-only, so malicious bot operators have had little incentive to make the switch. They probably won't do until there is a significant abandonment of IPv4, which probably won't happen in the next five years.
I expect that blind guessing probably won't be productive for malicious bots, when they finally do move to IPv6, so they'll have to move to other means, like brute-forcing DNS names, or targeted brute-forcing of small subsets of each subnet.
For instance, a common DHCPv6 server configuration gives out addresses in ::100
through ::1ff
by default. That's just 256 addresses to try, out of a whole /64. Reconfiguring the DHCPv6 server to pick addresses from a much larger range mitigates this problem.
And using modified EUI-64 addresses for SLAAC reduces the search space to 224 multiplied by the number of assigned OUIs. While this is over 100 billion addresses, it's far less than 264. Random bots won't bother to search this space, but state-level malicious actors will, for targeted attacks, especially if they can make educated guesses as to which NICs might be in use, to reduce the search space further. Using RFC 7217 stable privacy addresses for SLAAC is easy (at least on modern operating systems that support it) and mitigates this risk.
RFC 7707 describes several other ways in which reconnaissance might be performed in IPv6 networks to locate IPv6 addresses, and how to mitigate against those threats.
edited yesterday
Patrick Mevzek
2,97231225
2,97231225
answered 2 days ago
Michael Hampton♦Michael Hampton
175k27321651
175k27321651
Many bots are VERY creative already, and there is likely a huge black market for the better bots, probably with bundled access to their bot net while they're at it. The bots that are not creative should be easily blocked by whatever method you block the creative ones with.
– BeowulfNode42
yesterday
1
Most of what I see is the non-creative variety of bot. Though it's the creative variety that keeps me up at night. Fortunately I have a client who pays me to lose sleep over them. That said, I'm yet to see any significant bot traffic on IPv6, creative or not.
– Michael Hampton♦
yesterday
Yes I have more recently noticed the bruit force attempts are spread across months (a username or password per day) suggesting each single username or password is tried against every public facing SSH server on the (IPv4) Internet before moving onto the next username or password.
– Philip Couling
yesterday
add a comment |
Many bots are VERY creative already, and there is likely a huge black market for the better bots, probably with bundled access to their bot net while they're at it. The bots that are not creative should be easily blocked by whatever method you block the creative ones with.
– BeowulfNode42
yesterday
1
Most of what I see is the non-creative variety of bot. Though it's the creative variety that keeps me up at night. Fortunately I have a client who pays me to lose sleep over them. That said, I'm yet to see any significant bot traffic on IPv6, creative or not.
– Michael Hampton♦
yesterday
Yes I have more recently noticed the bruit force attempts are spread across months (a username or password per day) suggesting each single username or password is tried against every public facing SSH server on the (IPv4) Internet before moving onto the next username or password.
– Philip Couling
yesterday
Many bots are VERY creative already, and there is likely a huge black market for the better bots, probably with bundled access to their bot net while they're at it. The bots that are not creative should be easily blocked by whatever method you block the creative ones with.
– BeowulfNode42
yesterday
Many bots are VERY creative already, and there is likely a huge black market for the better bots, probably with bundled access to their bot net while they're at it. The bots that are not creative should be easily blocked by whatever method you block the creative ones with.
– BeowulfNode42
yesterday
1
1
Most of what I see is the non-creative variety of bot. Though it's the creative variety that keeps me up at night. Fortunately I have a client who pays me to lose sleep over them. That said, I'm yet to see any significant bot traffic on IPv6, creative or not.
– Michael Hampton♦
yesterday
Most of what I see is the non-creative variety of bot. Though it's the creative variety that keeps me up at night. Fortunately I have a client who pays me to lose sleep over them. That said, I'm yet to see any significant bot traffic on IPv6, creative or not.
– Michael Hampton♦
yesterday
Yes I have more recently noticed the bruit force attempts are spread across months (a username or password per day) suggesting each single username or password is tried against every public facing SSH server on the (IPv4) Internet before moving onto the next username or password.
– Philip Couling
yesterday
Yes I have more recently noticed the bruit force attempts are spread across months (a username or password per day) suggesting each single username or password is tried against every public facing SSH server on the (IPv4) Internet before moving onto the next username or password.
– Philip Couling
yesterday
add a comment |
Regarding AAAA records:
DNS is traditionally unencrypted. While there is a family of standards (DNSSEC) for signing DNS, the encryption of DNS records has had a far more haphazard deployment process, and so it is generally safest to assume that any MitM can read all of your DNS queries unless you have gone out of your way to configure encrypted DNS explicitly on the client side. You would know if you had done so because it's quite an ordeal.
(Also, your web browser is probably sending unencrypted SNI in the TLS handshake, after it has resolved the domain. It is not obvious how you would go about plugging this hole, since a VPN or Tor can still be MitM'd between the exit node or VPN termination point and the remote server. The good folks at Cloudflare are working on fixing this problem for good, but ESNI will also depend on client implementation, particularly for Chrome, if it's going to really get off the ground.)
However, MitM attacks may or may not be a problem, depending on your threat model. More important is the simple fact that DNS names are intended to be public information. Lots of people (search engines, DNS registrars, etc.) collect and publicize DNS names for entirely benign reasons. DNS resolvers typically apply rate limits, but these limits are usually quite generous, because they're meant to stop DoS attacks, not subdomain enumeration. Creating an HTTPS certificate often involves publishing the domain name for all to see, depending on the CA (Let's Encrypt does it, and so do many others). In practice, it is quite impossible to keep a domain or subdomain a secret, because just about everyone assumes they are public and makes no effort to hide them.
So, to answer this question:
I'm more interested in whether DNS or the underlying protocols of IPv6 allow discovery / listing unknown domains and addresses by remote.
Technically, no, it doesn't. But that does not matter because an enormous amount of higher-layer technology just assumes your DNS records are public, so public they will inevitably be.
1
Encrypted SNI is under development. Give it a year or two.
– Michael Hampton♦
yesterday
1
@MichaelHampton: I believe that ESNI will happen. But given the industry's track record (DNSSEC, IPv6, DANE, ...) I'm a bit skeptical that "a year or two" will truly be sufficient. Regardless, we shall see soon enough.
– Kevin
yesterday
1
CloudFlare is pushing it so I'll bet on sooner rather than later :)
– Michael Hampton♦
yesterday
I find myself wanting to say "yes but..." to each of your specific examples however it is a very good point that DNS names are generally assumed to be public information. +1
– Philip Couling
yesterday
add a comment |
Regarding AAAA records:
DNS is traditionally unencrypted. While there is a family of standards (DNSSEC) for signing DNS, the encryption of DNS records has had a far more haphazard deployment process, and so it is generally safest to assume that any MitM can read all of your DNS queries unless you have gone out of your way to configure encrypted DNS explicitly on the client side. You would know if you had done so because it's quite an ordeal.
(Also, your web browser is probably sending unencrypted SNI in the TLS handshake, after it has resolved the domain. It is not obvious how you would go about plugging this hole, since a VPN or Tor can still be MitM'd between the exit node or VPN termination point and the remote server. The good folks at Cloudflare are working on fixing this problem for good, but ESNI will also depend on client implementation, particularly for Chrome, if it's going to really get off the ground.)
However, MitM attacks may or may not be a problem, depending on your threat model. More important is the simple fact that DNS names are intended to be public information. Lots of people (search engines, DNS registrars, etc.) collect and publicize DNS names for entirely benign reasons. DNS resolvers typically apply rate limits, but these limits are usually quite generous, because they're meant to stop DoS attacks, not subdomain enumeration. Creating an HTTPS certificate often involves publishing the domain name for all to see, depending on the CA (Let's Encrypt does it, and so do many others). In practice, it is quite impossible to keep a domain or subdomain a secret, because just about everyone assumes they are public and makes no effort to hide them.
So, to answer this question:
I'm more interested in whether DNS or the underlying protocols of IPv6 allow discovery / listing unknown domains and addresses by remote.
Technically, no, it doesn't. But that does not matter because an enormous amount of higher-layer technology just assumes your DNS records are public, so public they will inevitably be.
1
Encrypted SNI is under development. Give it a year or two.
– Michael Hampton♦
yesterday
1
@MichaelHampton: I believe that ESNI will happen. But given the industry's track record (DNSSEC, IPv6, DANE, ...) I'm a bit skeptical that "a year or two" will truly be sufficient. Regardless, we shall see soon enough.
– Kevin
yesterday
1
CloudFlare is pushing it so I'll bet on sooner rather than later :)
– Michael Hampton♦
yesterday
I find myself wanting to say "yes but..." to each of your specific examples however it is a very good point that DNS names are generally assumed to be public information. +1
– Philip Couling
yesterday
add a comment |
Regarding AAAA records:
DNS is traditionally unencrypted. While there is a family of standards (DNSSEC) for signing DNS, the encryption of DNS records has had a far more haphazard deployment process, and so it is generally safest to assume that any MitM can read all of your DNS queries unless you have gone out of your way to configure encrypted DNS explicitly on the client side. You would know if you had done so because it's quite an ordeal.
(Also, your web browser is probably sending unencrypted SNI in the TLS handshake, after it has resolved the domain. It is not obvious how you would go about plugging this hole, since a VPN or Tor can still be MitM'd between the exit node or VPN termination point and the remote server. The good folks at Cloudflare are working on fixing this problem for good, but ESNI will also depend on client implementation, particularly for Chrome, if it's going to really get off the ground.)
However, MitM attacks may or may not be a problem, depending on your threat model. More important is the simple fact that DNS names are intended to be public information. Lots of people (search engines, DNS registrars, etc.) collect and publicize DNS names for entirely benign reasons. DNS resolvers typically apply rate limits, but these limits are usually quite generous, because they're meant to stop DoS attacks, not subdomain enumeration. Creating an HTTPS certificate often involves publishing the domain name for all to see, depending on the CA (Let's Encrypt does it, and so do many others). In practice, it is quite impossible to keep a domain or subdomain a secret, because just about everyone assumes they are public and makes no effort to hide them.
So, to answer this question:
I'm more interested in whether DNS or the underlying protocols of IPv6 allow discovery / listing unknown domains and addresses by remote.
Technically, no, it doesn't. But that does not matter because an enormous amount of higher-layer technology just assumes your DNS records are public, so public they will inevitably be.
Regarding AAAA records:
DNS is traditionally unencrypted. While there is a family of standards (DNSSEC) for signing DNS, the encryption of DNS records has had a far more haphazard deployment process, and so it is generally safest to assume that any MitM can read all of your DNS queries unless you have gone out of your way to configure encrypted DNS explicitly on the client side. You would know if you had done so because it's quite an ordeal.
(Also, your web browser is probably sending unencrypted SNI in the TLS handshake, after it has resolved the domain. It is not obvious how you would go about plugging this hole, since a VPN or Tor can still be MitM'd between the exit node or VPN termination point and the remote server. The good folks at Cloudflare are working on fixing this problem for good, but ESNI will also depend on client implementation, particularly for Chrome, if it's going to really get off the ground.)
However, MitM attacks may or may not be a problem, depending on your threat model. More important is the simple fact that DNS names are intended to be public information. Lots of people (search engines, DNS registrars, etc.) collect and publicize DNS names for entirely benign reasons. DNS resolvers typically apply rate limits, but these limits are usually quite generous, because they're meant to stop DoS attacks, not subdomain enumeration. Creating an HTTPS certificate often involves publishing the domain name for all to see, depending on the CA (Let's Encrypt does it, and so do many others). In practice, it is quite impossible to keep a domain or subdomain a secret, because just about everyone assumes they are public and makes no effort to hide them.
So, to answer this question:
I'm more interested in whether DNS or the underlying protocols of IPv6 allow discovery / listing unknown domains and addresses by remote.
Technically, no, it doesn't. But that does not matter because an enormous amount of higher-layer technology just assumes your DNS records are public, so public they will inevitably be.
edited yesterday
answered 2 days ago
KevinKevin
1619
1619
1
Encrypted SNI is under development. Give it a year or two.
– Michael Hampton♦
yesterday
1
@MichaelHampton: I believe that ESNI will happen. But given the industry's track record (DNSSEC, IPv6, DANE, ...) I'm a bit skeptical that "a year or two" will truly be sufficient. Regardless, we shall see soon enough.
– Kevin
yesterday
1
CloudFlare is pushing it so I'll bet on sooner rather than later :)
– Michael Hampton♦
yesterday
I find myself wanting to say "yes but..." to each of your specific examples however it is a very good point that DNS names are generally assumed to be public information. +1
– Philip Couling
yesterday
add a comment |
1
Encrypted SNI is under development. Give it a year or two.
– Michael Hampton♦
yesterday
1
@MichaelHampton: I believe that ESNI will happen. But given the industry's track record (DNSSEC, IPv6, DANE, ...) I'm a bit skeptical that "a year or two" will truly be sufficient. Regardless, we shall see soon enough.
– Kevin
yesterday
1
CloudFlare is pushing it so I'll bet on sooner rather than later :)
– Michael Hampton♦
yesterday
I find myself wanting to say "yes but..." to each of your specific examples however it is a very good point that DNS names are generally assumed to be public information. +1
– Philip Couling
yesterday
1
1
Encrypted SNI is under development. Give it a year or two.
– Michael Hampton♦
yesterday
Encrypted SNI is under development. Give it a year or two.
– Michael Hampton♦
yesterday
1
1
@MichaelHampton: I believe that ESNI will happen. But given the industry's track record (DNSSEC, IPv6, DANE, ...) I'm a bit skeptical that "a year or two" will truly be sufficient. Regardless, we shall see soon enough.
– Kevin
yesterday
@MichaelHampton: I believe that ESNI will happen. But given the industry's track record (DNSSEC, IPv6, DANE, ...) I'm a bit skeptical that "a year or two" will truly be sufficient. Regardless, we shall see soon enough.
– Kevin
yesterday
1
1
CloudFlare is pushing it so I'll bet on sooner rather than later :)
– Michael Hampton♦
yesterday
CloudFlare is pushing it so I'll bet on sooner rather than later :)
– Michael Hampton♦
yesterday
I find myself wanting to say "yes but..." to each of your specific examples however it is a very good point that DNS names are generally assumed to be public information. +1
– Philip Couling
yesterday
I find myself wanting to say "yes but..." to each of your specific examples however it is a very good point that DNS names are generally assumed to be public information. +1
– Philip Couling
yesterday
add a comment |
I've found that MANY bots these days are not guessing, with IPv4 or IPv6. Security through obscurity is not security at all. Obscurity simply delays / reduces the number of attacks for a while, and then it is irrelevant.
Hackers know your company's domain name from your website or email address, what public server IPs you publish for things like email, SPF, web servers, etc. Though it may take them a bit longer to learn a random server name, but they will guess the common names, like www, mail, smtp, imap, pop, pop3, ns1, etc, and then scrape your website for any additional data they can find. They will retrieve from their store of previous scans your DNS names, IPs and what ports to focus on. They will also retrieve a list of email address / password pairs from any data breaches they can find and try all of those logins plus some extra ones with whatever systems they think you are running on your ports. They even go to the extent of learning the names and job roles of your staff to try and execute a social engineered attack. Our spam filter is continuously bombarded with attempts by scammers claiming to be someone from management needing an urgent wire transfer of funds. Oh they also learn who your business partners are and claim to be them, and letting you know their bank details have changed. Sometimes they even know what cloud platforms your business partners are using for their invoicing.
Criminals have access to big data tools just the same as everyone else, and they have amassed a surprisingly huge amount of data. See this testimony by some IT professionals to US congress https://www.troyhunt.com/heres-what-im-telling-us-congress-about-data-breaches/
Talking about data breaches, if a company looses something even as seemingly useless as a web server log, this will contain IP addresses v4 or v6 of everyone who used that server at that time, and what pages they accessed.
In conclusion, none of those methods require an attacker to guess what IP you are using, they already know.
add a comment |
I've found that MANY bots these days are not guessing, with IPv4 or IPv6. Security through obscurity is not security at all. Obscurity simply delays / reduces the number of attacks for a while, and then it is irrelevant.
Hackers know your company's domain name from your website or email address, what public server IPs you publish for things like email, SPF, web servers, etc. Though it may take them a bit longer to learn a random server name, but they will guess the common names, like www, mail, smtp, imap, pop, pop3, ns1, etc, and then scrape your website for any additional data they can find. They will retrieve from their store of previous scans your DNS names, IPs and what ports to focus on. They will also retrieve a list of email address / password pairs from any data breaches they can find and try all of those logins plus some extra ones with whatever systems they think you are running on your ports. They even go to the extent of learning the names and job roles of your staff to try and execute a social engineered attack. Our spam filter is continuously bombarded with attempts by scammers claiming to be someone from management needing an urgent wire transfer of funds. Oh they also learn who your business partners are and claim to be them, and letting you know their bank details have changed. Sometimes they even know what cloud platforms your business partners are using for their invoicing.
Criminals have access to big data tools just the same as everyone else, and they have amassed a surprisingly huge amount of data. See this testimony by some IT professionals to US congress https://www.troyhunt.com/heres-what-im-telling-us-congress-about-data-breaches/
Talking about data breaches, if a company looses something even as seemingly useless as a web server log, this will contain IP addresses v4 or v6 of everyone who used that server at that time, and what pages they accessed.
In conclusion, none of those methods require an attacker to guess what IP you are using, they already know.
add a comment |
I've found that MANY bots these days are not guessing, with IPv4 or IPv6. Security through obscurity is not security at all. Obscurity simply delays / reduces the number of attacks for a while, and then it is irrelevant.
Hackers know your company's domain name from your website or email address, what public server IPs you publish for things like email, SPF, web servers, etc. Though it may take them a bit longer to learn a random server name, but they will guess the common names, like www, mail, smtp, imap, pop, pop3, ns1, etc, and then scrape your website for any additional data they can find. They will retrieve from their store of previous scans your DNS names, IPs and what ports to focus on. They will also retrieve a list of email address / password pairs from any data breaches they can find and try all of those logins plus some extra ones with whatever systems they think you are running on your ports. They even go to the extent of learning the names and job roles of your staff to try and execute a social engineered attack. Our spam filter is continuously bombarded with attempts by scammers claiming to be someone from management needing an urgent wire transfer of funds. Oh they also learn who your business partners are and claim to be them, and letting you know their bank details have changed. Sometimes they even know what cloud platforms your business partners are using for their invoicing.
Criminals have access to big data tools just the same as everyone else, and they have amassed a surprisingly huge amount of data. See this testimony by some IT professionals to US congress https://www.troyhunt.com/heres-what-im-telling-us-congress-about-data-breaches/
Talking about data breaches, if a company looses something even as seemingly useless as a web server log, this will contain IP addresses v4 or v6 of everyone who used that server at that time, and what pages they accessed.
In conclusion, none of those methods require an attacker to guess what IP you are using, they already know.
I've found that MANY bots these days are not guessing, with IPv4 or IPv6. Security through obscurity is not security at all. Obscurity simply delays / reduces the number of attacks for a while, and then it is irrelevant.
Hackers know your company's domain name from your website or email address, what public server IPs you publish for things like email, SPF, web servers, etc. Though it may take them a bit longer to learn a random server name, but they will guess the common names, like www, mail, smtp, imap, pop, pop3, ns1, etc, and then scrape your website for any additional data they can find. They will retrieve from their store of previous scans your DNS names, IPs and what ports to focus on. They will also retrieve a list of email address / password pairs from any data breaches they can find and try all of those logins plus some extra ones with whatever systems they think you are running on your ports. They even go to the extent of learning the names and job roles of your staff to try and execute a social engineered attack. Our spam filter is continuously bombarded with attempts by scammers claiming to be someone from management needing an urgent wire transfer of funds. Oh they also learn who your business partners are and claim to be them, and letting you know their bank details have changed. Sometimes they even know what cloud platforms your business partners are using for their invoicing.
Criminals have access to big data tools just the same as everyone else, and they have amassed a surprisingly huge amount of data. See this testimony by some IT professionals to US congress https://www.troyhunt.com/heres-what-im-telling-us-congress-about-data-breaches/
Talking about data breaches, if a company looses something even as seemingly useless as a web server log, this will contain IP addresses v4 or v6 of everyone who used that server at that time, and what pages they accessed.
In conclusion, none of those methods require an attacker to guess what IP you are using, they already know.
edited yesterday
answered yesterday
BeowulfNode42BeowulfNode42
2,33811329
2,33811329
add a comment |
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f963115%2fhow-discoverable-are-ipv6-addresses-and-aaaa-names-by-potential-attackers%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Related: IPv6 replacement for scanning IP range
– Michael Hampton♦
2 days ago
This looks like security by obscurity... If your only line of defense is using (supposedly) hard to discover identifiers (either names or IP addresses) then you can expect to be breached at some point. You may be relatively safe against generic exploits/random pokes, but if you have to defend against active attacks on you then that line of defence breaks. There is a ton of possible ways to discover "obscure" names, look at geekflare.com/find-subdomains for a start
– Patrick Mevzek
yesterday
2
@patrick If you have only a single line of defense you are getting breached period. I still don't want my locked doors advertised to the whole world
– Philip Couling
yesterday
So by your own conclusion you are breached and you should setup your systems and their security differently.
– Patrick Mevzek
yesterday
1
No. By my own conclusion this is not my only line of security. I never suggested otherwise.
– Philip Couling
yesterday