9 ms·

Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency projec

Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many others. Security by obscurity does not work. You can not rely on "people won't find it". Once it's online, everyone can find it. No matter how you hide it.

TZubiri 2y ago
"Security by obscurity does not work" This is one of those false voyeur OS internet tennets designed to get people to publish their stuff. Obscurity is a fine strategy, if you don't post your source that's good. If you post your source, that's a risk. The fact that you can't rely on that security measure is just a basic security tennet that applies to everything: don't rely on a single security measure, use redundant barriers. Truth is we don't know how the subdomain got leaked. Subdomains can be passwords and a well crafted subdomain should not leak, if it leaks there is a reason.
- zevlag 2y ago
  > Subdomains can be passwords and a well crafted subdomain should not leak, I disagree. A subdomain is not secret in any way. There are many ways in which it is transmitted unencrypted. A couple: - DNS resolution, multiple resolvers and authoritative servers - TLS SNI - HTTP Host Header There are many middle boxes that could perform safety checks on behalf of the client, and drop it into a list to be rescanned. - Virus Scanners - Firewalls - Proxies
  - dharmab 2y ago
    I once worked for a company which was using a subdomain of an internal development domain to do some completely internal security research on our own products. The entire domain got flagged in Safe Browsing despite never being exposed to the outside world. We think Chrome's telemetry flagged it, and since it was technically routable as a public IP (all public traffic on that IP was blackholed), Chrome thought it was a public website.
    - mkl95 2y ago
      I saw a similar thing happen with a QA team's domains. Google flagged them as malicious and the company never managed to get them unflagged.
      - dharmab 2y ago
        Our lawyers knew their lawyers so there was a friendly chat and we got added to an internal whitelist within Google.
  - TZubiri 2y ago
    >It's not encrypted in transit Agree. But who said that all passwords or shiboleths should all be encrypted in transit? It can serve as a canary for someone snooping your traffic. Even if you encrypt it, you don't want people snooping. To date of my subdomains that I never publish, I haven't had anyone attempting to connect with them. It's one of those redundant measures. And it's also one of those risks that you take, you can maximize security by staying at home all day, but going out to take the trash is a calculated risk that you must take or risk overfocusing on security. It's similar to port knocking. If you are encrypting it, it's counterproductive, it's a low effort finishing touch, like a nice knot.
- lolinder 2y ago
  Truth is we don't know that the subdomain got leaked. The example user agent they give says that the methodology they're using is to scan the IPv4 space, which is a great example of why security through obscurity doesn't work here: The IPv4 space is tiny and trivial to scan. If your server has an IPv4 address it's not obscure, you should assume it's publicly reachable and plan accordingly. > Subdomains can be passwords and a well crafted subdomain should not leak, if it leaks there is a reason. The problem with this theory is that DNS was never designed to be secret and private and even after DNS over HTTPS it's still not designed to be private for the servers. This means that getting to "well crafted" is an incredibly difficult task with hundreds of possible failure modes which need constant maintenance and attention—not only is it complicated to get right the first time, you have to reconfigure away the failure modes on every device or even on every use of the "password". Here are just a few failure modes I can think of off the top of my head. Yes, these have mitigations, but it's a game of whack-a-mole and you really don't want to try it: * Certificate transparency logs, as mentioned. * A user of your "password" forgets that they didn't configure DNS over HTTPS on a new device and leaves a trail of logs through a dozen recursive DNS servers and ISPs. * A user has DNS over HTTPS but doesn't point it at a server within your control. One foreign server having the password is better than dozens and their ISPs, but you don't have any control over that default DNS server nor how many different servers your clients will attempt to use. * Browser history. Just don't. Work with the grain, assume the subdomain is public and secure your site accordingly.
  - immibis 2y ago
    > The IPv4 space is tiny and trivial to scan Something many people don't expect is that the IPv6 space is also tiny and trivial to scan, if you follow certain patterns. For example, many server hosts give you a /48 or /64 subnet, and your server is at your prefix::1 by default. If they have a /24 and they give you a /48, someone only has to scan 2^24 addresses at that host to find all the ones using prefix::1.
    - Sayrus 2y ago
      Assuming everyone is using /48 and binding to prefix::1, that's a 2^16 difference with scanning the IPv4 address space. Assuming a specific host with only one IPv6 /24 block and delegating /64, this is a 2^12 difference. Scanning for /64 on the entire IPv6 space is definitely not as tiny. AWS only allows routing /80 to EC2 instances making a huge difference. It doesn't mean that we should rely on obscurity, but the entire space is not tiny as IPv4 was.
- lyu07282 2y ago
  > Obscurity is a fine strategy > Subdomains can be passwords and a well crafted subdomain should not leak Your comment is really odd to read I'm not sure I understand you, but I'm sure you don't mean it like that. Just to re-iterate the important points: 1. Do not rely on subdomains for security, subdomains can easily leak in innumerable ways including in ways outside of your control. 2. Security by obscurity must never be relied on for security but can be part of a larger defense in depth strategy. --- https://cwe.mitre.org/data/definitions/656.html https://cwe.mitre.org/data/definitions/656.html > This reliance on "security through obscurity" can produce resultant weaknesses if an attacker is able to reverse engineer the inner workings of the mechanism. Note that obscurity can be one small part of defense in depth, since it can create more work for an attacker; however, it is a significant risk if used as the primary means of protection.
  - TZubiri 2y ago
    It's a pretty weak cve category. "The product uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism." If you can defeat the mechanism, that's not very impactful if it's one stage of a multi-round mechanism. Especially if vulnerating or crossing that perimeter alerts the admin! Lots of uncreative blue teamers here
    - deleted 2y ago
      [deleted]
- deleted 2y ago
  [deleted]
- yapyap 2y ago
  > This is one of those false voyeur OS internet tennets designed to get people to publish their stuff. No it isn’t, it’s a push to get people to login protect whatever they want to keep to themselves. It’s silly to say informing people that security through obscurity is a weak concept is trying to convince them to publish their stuff.
  - HeatrayEnjoyer 2y ago
    If security through obscurity didn't provide any benefit then governments wouldn't have built entire frameworks for protecting classified information.
    - ehutch79 2y ago
      So the only thing protecting classified docs is the public not knowing where they are? That's what security through obscurity is.
      - HeatrayEnjoyer 2y ago
        No, it's not the only thing, but it is one layer of defense in depth. No one is saying that obfuscation should be the only layer. Your defense should never hinge on any single protection layer.
        ehutch79 2y ago
        So we're all agreeing here. It's ok to hide stuff from sight, but hiding stuff from sight isn't actually security and can't replace at the very least, having password protection.
        HeatrayEnjoyer 2y ago
        But it is security. It's one layer of it.
- yatralalala 2y ago
  So many thoughts on that, but from my perspective - obscurity is ok, but you can not depend on it at all. Great example is port knocking - it hides your open port from random nmap, but would you leave it as the only mechanism preventing people getting to your server? No. So does it make sense to have it? Well maybe, it's a layer. Kerckhoffs' principle comes to my mind as well here. So while I agree with you on that's obscurity is fine strategy, you can never depend on it ever.
  - marcosdumay 2y ago
    As long as you don't go into "nah, I have another protection barrier, I don't need the best possible security for my main barrier" mode... Or in other words, if you place absolutely zero trust in it, consider it as good as broken by every single script kid, and publicly known, then yeah, it's fine. But then, why are you investing time into it? Almost everybody that makes low-security barriers is relying on it.
  - TZubiri 2y ago
    >obscurity is fine strategy, you can never depend on it ever. Right, I'm arguing that this is a property of all security mechanisms. You can never depend on a single security mechanism. Obscurity is no different. You cannot depend only on encryption, you cannot depend only on air gaps, you cannot depend only on obscurity, you cannot depend only on firewalls, you cannot depend only on user permissions, you cannot depend only on legal deterrents, you cannot depend only on legal threats, etc..
- sim7c00 2y ago
  making things obscure and hard to find is indeed a sound choice, as long as its not the single measure taken. i think people tout this sentence because its popular to say it, without thinking further. you dont put an unauthenticated thing in a difficult to find subdomain and call it secure. but your nicely secured page is more secure if its also very tedious to find. its a less low hanging fruit. as you state also there is always a leak needed. but dns system is quite leaky. and often sources wont fix or wont admit its even broken by their design. strong passwords are also insecure if they leak, so you obscure them from prying eyes, securing it by obscurity.
  - TZubiri 2y ago
    A lot of the pushback I'm seeing is that people are assuming that you always want to make things more secure. That security is a number that needs to go up, like income or profit, as opposed to numbers that need to go down, like cost and taxes. The possibility that I'm adding this feature to something that would otherwise have been published on a public domain does not cross people's mind, so it is not thought of an additional security measure, but a removal of a security feature. Similarly it is assumed that there's an unauthenticated or authentication mechanism behind the subdomain. There may be a simple idempotent server running, such that there is no concern for abuse, but it may be desirable to reduce the code executed by random spearfishing scanners that only have an IP. This brings me again to the competitive economic take on the subject, that people believe that this wisdom nugget they hold "that security by obscurity" is a valuable tennet, and they bet on it and desperately try to find someone to use it on. You can tell when a meme is overvalued because they try to use it on you even if it doesn't fit, it means they are dying to actually apply it. My bet is that "Security through obscurity" is undervalued, not as a rule or law, or a definite thing, but as a basic correlation: keep a low profile, and you'll be safer. If you want to get more sales, you will need to be a bit more open and transparent and that will expose you to more risk, same if you want transparency for ethical or regulation reasons. You will be less obscure and you will need to compensate with additional security mechanisms. But it seems evident to me that if you don't publish your shit, you are going to have much less risk, and need to implement less security mechanisms for the same risks as compared to voicing your infrastructure and your business, duh.
- 1970-01-01 2y ago
  It's become an anti-cliche. Security via obscure technique is a valid security layer in the exact same way a physical lock tumbler will not unlock when any random key is inserted and twisted. It's not great but it's not terrible and it does a fine job until someone picks or breaks it open.
  - gitgud 2y ago
    I don’t think that analogy works well, a subdomain that is not published is more like hiding the key to the front door in the garden somewhere… does a fine job of keeping the house secure until someone finds it…
    - TZubiri 2y ago
      Terrible analogy. Why not use letters and packages which is the literal metaphor these services were built on? It's like relying on public header information to determine whether an incoming letter or package is legitimate. If it says: To "Name LastName" or "Company", then it's probably legitimate. Of course it's no guarantee, but it filters the bulk of Nigerian Prince spam. It gets you past the junk box, but you don't have to trust it with your life. Nuance.
  - lxgr 2y ago
    Keeping a key secret is not security by obscurity, but keeping the existence of a lock secret is.
- legitster 2y ago
  > "Security by obscurity does not work" Depends on the context and exposure. Sometimes a key under a rock is perfectly fine. I used to work for a security company that REALLY oversold security risks to sell products. The idea that someone was going to wardrive through your suburban neighborhood with a networked cluster of GPUs to crack your AES keys and run a MITM attack for web traffic is honestly pretty far fetched unless they are a nation-state actor.
  - natebc 2y ago
    Realistically we get into $3 wrench territory pretty quickly too.
    - throwway120385 2y ago
      They could also just cut and tip both ends of the Ethernet cable I have running between my house and my outbuilding too. I probably wouldn't notice if I'm asleep.
      - TZubiri 2y ago
        Metaforgotten, but this is a very standard attack surface, you don't need to imagine such a close tap, just imagine that at any point in the multi node internet an attacker has a node and snoops the traffic in its role as a relaying router.
    - ninju 2y ago
      With inflation looks like its now a $5 wrench :-) https://xkcd.com/538/ https://xkcd.com/538/
      - natebc 2y ago
        AmazonBasics is good enough in this case! ;)
- bob1029 2y ago
  Obscurity can be fantastic. One of my favorite patterns for sending large files around is to drop them in a public blob storage bucket with a type 4 guid as the name. No consumer needs to authenticate or sign in. They just need to know the resource name. After a period of time the files can be automatically expired to minimize the impact of URL sharing/stealing.
  - genewitch 2y ago
    Wouldn't the blob storage host be able to see your obscure file? I suppose if it's encrypted, no. Like the pastebin service I run, it's encrypted at rest. It doesn't even touch disks, so I mean, that's a decent answer to mine own question.
- unethical_ban 2y ago
  No, it's a very sensible slogan to keep people from doing a common, bad thing. Obscurity helps cut down on noise and low effort attacks and scans. It only helps as a security mechanism in that the remaining access/error logs are both fewer and more interesting.
  - TZubiri 2y ago
    I definitely see it's value as a very naive recommendation to avoid someone literally relying on an algorithmic or low entropy secret. Literally something you may learn on your first class on security. However on more advanced levels, a more common error is to ignore the risks of open source and being public. If you don't publish your source code, you are massively safer, period. I guess your view on the subject depends on whether you think you are ahead of the curve by taking the naive interpretation. It's like investing in the stock market based on your knowledge of supply and demand.
- batch12 2y ago
  Obscurity as a single control does not work. That's what the phrase hints at. In combination with other controls, it could be part of an effective defense. Context matters though.
- 0hijinks 2y ago
  Depending on one's threat model, any technique can be a secure strategy. Is my threat model a network of dumb nodes doing automatic port scanning? Tucking a system on an obscure IPv6 address and never sharing the address may work OK. Running some bespoke, unauthenticated SSH-over-Carrier-Pigeon (SoCP) tunnel may be fine. The adversaries in the model are pretty dumb, so intrusion detection is also easy. But if the threat model includes any well-motivated, intelligent adversary (disgruntled peer, NSA, evil ex-boyfriend), it will probably just annoy them. And as a bonus, for my trouble, it will be harder to maintain going forward.
  - TZubiri 2y ago
    It's a bit more complex than that as well. You might have attackers of both types and different datapoints that have different security requirements. And these are not necessarily scalars, you may need integrity for one, privacy for the other. Even when considering hi sophistication attackers, and perhaps especially with regards to them, you may want to leave some breadcrumbs for them to access your info. If the deep state wants my company's info, they can safely get it by subpoenaing my provider's info, I don't need to worry about them as an attacker for privacy, as they have the access to the information if needed. If your approach to security is to add cryptography everywhere and make everything as secure as possible and imagine that you are up against a nation-state adversary (or conversely, that you add security until you satisfy a requirement conmesurate with your adversary), then you are literally reducing one of the most important design requirements of your system to a single scalar that you attempt to maximize while not compromising other tradeoffs. A straightforward lack of nuance. It's like having a tax strategy consisting of number go down, or pricing strategy of price go up, or cost strategy of cost go down, or risk strategy of no risk for me, etc...
- lxgr 2y ago
  The only thing you're definitely complicating with security by obscurity is getting a clear picture of your own security posture.
- wolrah 2y ago
  > "Security by obscurity does not work" The saying is "security by obscurity is not security" which is absolutely true. If your security relies on the attacker not finding it or not knowing how it works, it's not actually secure. Obscurity has its own value of course, I strongly recommend running any service that's likely to be scanned for regularly on non-standard ports wherever practical simply to reduce the number of connection logs you need to sort through. Obscurity works for what it actually offers. That has nothing to do with security though, and unfortunately it's hard in cases where a human is likely to want to type in your service address because most user-facing services have little to no support for SRV records. Two of the few services that do have widespread SRV support are SIP VoIP and Minecraft, and coincidentally the former is my day job while I've also run a personal Minecraft server for over a decade. I can say that the couple of systems I still have running public-facing SIP on port 5060 get scanned tens of thousands of times per hour while the ones running on non-standard ports get maybe one or two activations of fail2ban a month. Likewise my Minecraft server has never seen a single probe from anyone other than an actual player.
  - TZubiri 2y ago
    >"If your security relies on " Again, if your security relies on any one thing, it's a problem. A secure system needs redundant mechanisms. Can you think of a single mechanism that if implemented would make a system secure? I think not.
    - genewitch 2y ago
      Sure, a 12 gauge slug right through the processor.
      - TZubiri 2y ago
        Good measure, but you may also want to keep some unslugged processors in case you need to counterattack. Q.E.D
  - wutwutwat 2y ago
    > If your security relies on the attacker not finding it or not knowing how it works, it's not actually secure. Every branch of the military would like to talk to you and inform you that sometimes, the enemy not finding the target, or not knowing how the target works, can be extremely, actually secure. Like, still alive secure. I'd argue that's a rather effective security measure in certain situations. Then there's compartmentalization, need to know, and then all of the security clearance levels... Leaking classified documents can be considered treason, which is one of very few non-violent crimes you can commit that could result in the death penalty. The Fed seems to think security through obscurity is a pretty fucking alright thing, seeing as how they use it everywhere.
- Diggsey 2y ago
  This is the worst take... People consistently misuse the Swiss cheese security metaphor to justify putting multiple ineffective security barriers in place. The holes in the cheese are supposed to represent unknown or very difficult to exploit flaws in your security layers, and that's why you ideally want multiple layers. You can't just stack up multiple known to be broken layers and call something secure. The extra layers are inconvenient to users and readily bypassed by attackers by simply tackling them one at a time. Security by obscurity is one such layer.
  - TZubiri 2y ago
    So according to you, a picket fence or a wire fence is just a useless thing that makes things less usable by users? Security does not consist only of 100% or 99.99% effective mechanisms, there needs to be a flow of information and an inherent risk, if you are only designing absolute barriers, then you are rarely considering the actual surface of relevant user interactions. A life form consisting only of skin might be very secure, but it's practically useless.
  - genewitch 2y ago
    I've heard that Swiss cheese analogy when it comes to the seasoning on a cast iron pan. Even if you have tons and tons of layers of seasoning, you still don't put tomato sauce or whatever on it.
nkmnz 2y ago
[flagged]
- deleted 2y ago
  [deleted]
- remlov 2y ago
  If you look at the company they founded it's a service to protect yourself. Not to willy-nilly go out into the open web to find hidden subdomains.
- tmerc 2y ago
  Why would enumerating a wildcard dns through brute force be something that evokes pride or shame?
  - yatralalala 2y ago
    I sadly did not see the comment above, but I'd like to just add, that this bruteforce and sniffing methods are target only against our paying customers. We built global reverse-DNS dataset solely from cert transparency logs. Our active scanning/bruteforcing runs only for assets owned by our customers.
    - 6stringmerc 2y ago
      …as long as your tools are only in your hands to be used, correct? Once a tool is created and used on a machine with access to the greater internet, doesn’t your logic hold that its security is compromised inherently? Not saying you have been infiltrated, or a rogue employee has cleverly exported a copy or the methodology to duplicate it off-site, but I’m not saying that hasn’t happened either.
      - cryptonector 2y ago
        It's not that hard to write this code. It's not a nuclear weapon.
amelius 2y ago
Well, I sure hope the remainder of my URLs are safe.
- amelius 2y ago
  Like, in: example.com/secret-id-48723487345 I hope the last bit is not leaked somehow (?) Btw, we need a "falsehoods programmers believe about URLs" ... Although there is: https://www.netmeister.org/blog/urls.html https://www.netmeister.org/blog/urls.html
  - idoubtit 2y ago
    > Although there is: https://www.netmeister.org/blog/urls.html https://www.netmeister.org/blog/urls.html I think the section named "Pathname" is wrong. It describes the path of an URL as if every server was Apache serving static files with its default configuration. It should describe how the path is converted into a HTTP request. For instance, the article states that "all of these go to the same place : https://example.org https://example.org https://example.org/ https://example.org/ https://example.org// https://example.org// https://example.org////////////////// https://example.org//////////////////". That's wrong. A web client send a distinct HTTP request for each case, e.g starting with `GET // HTTP/1.1`. So the server will receive distinct paths. The assertion of "going to the same place" makes no sense in the general case.
sl1ckback 2y ago
[flagged]
- monkaiju 2y ago
  This is the most confidently incorrect post I've seen in a long time.
  - elliotbnvl 2y ago
    Actually it’s quite correct.
  - xunil2ycom 2y ago
    seriously.
  - sl1ckback 2y ago
    [dead]
- crazygringo 2y ago
  > “Security through obscurity” is the only security there is. > Encryption obscures data. I don't think you understand what "security through obscurity" means. What encryption does is literally the opposite of obscure, in this context. It is out in the open and documented. And the same with the rest of your examples.
  - sl1ckback 2y ago
    [dead]
- MyOutfitIsVague 2y ago
  That's not what that phrase means. That's not even what the word "obscure" means. Obscurity is trying to not draw attention to something, or keep it hidden (as in "nobody knows that it's there", not "you know that it's there but can't access it"). Encryption doesn't obscure data unless you're stretching the definition of the word beyond its useful purpose.
1970-01-01 2y ago
Subdomainfinder.com ?? Dozens of others will also find it. Really, it's this simple today.
- binarymax 2y ago
  I think your comment resulted in a hug of death for that service ;)
- yatralalala 2y ago
  Sorry for a bit of self promo, but just to explain we run https://reconwave.com/ https://reconwave.com/, basically EASM product but more focused on network/DNS/setup level. Finding all things about domains is one of the things that we do. And yes, it's very easy. There are many services like subdomainfinder - i.e. dnsdumpster and merklemap. We built our own as well on https://search.reconwave.com/ https://search.reconwave.com/. But it's a side project and it does not pay our bills.
cryptonector 2y ago
DANE would help here: register a harmless sounding domainname whose name leaks nothing, use DNSSEC and NSEC3, and host your hidden service in a sub-domain whose name is a 63 byte long string of randomly selected ASCII characters. But this isn't really an option.
- Dylan16807 2y ago
  Why the DNSSEC, which then requires NSEC3? Shouldn't a wildcard certificate do the job in conjunction with normal unsigned DNS?
cryptonector 2y ago
> Security by obscurity does not work. You can not rely on "people won't find it". Once it's online, everyone can find it. No matter how you hide it. Especially do not name your domainnames in a way that leaks MNPI! Like, imagine if publicly traded companies A and B were discussing a merger or acquisition, do not name your domainname A-and-B.com, m'kay?
- pacificmint 2y ago
  Case in point: When Daimler and Chrysler merged, they had a law firm (with no other ties to either company) register the DaimlerChrysler domains weeks before the merger was made public. I don’t recall if anybody noticed before they went public, but as this thread shows, today it would be noticed for sure.
  - FireBeyond 2y ago
    One of the earlier seasons of Survivor had the winner leaked because of something similar. Their website had bios of every player, with a <playername>.jpg headshot. As they were voted out, their headshot was replaced with <playername>_eliminated.jpg. As soon as someone realized that, they entered in every player's name with _eliminated.jpg. One player had a 404 for that file.
no-dr-onboard 2y ago
Hi, former pentester here. If any one of your trusted clients is using a google/chromium based browser, the telemetry from that browser (webdiscovery) would reveal the existence of the subdomain in question. As others have said, security by obscurity doesn't work.
- geek_at 2y ago
  Current pen tester here and this guy is right. There was a Google blog post years ago where Google planted a site with an unguessable url and indexed it and used edge to surf on the site. Shortly after this site was also listed on Bing. Google had a "gotcha" moment when Microsoft responded basically with "yeah we didn't steal it from Google, you had telemetry enabled" Total shitshow
  - 3np 2y ago
    Would love to read this if a link is still around
    - treesknees 2y ago
      The Bing Sting! https://googleblog.blogspot.com/2011/02/microsofts-bing-uses-google-search.html?m=1 https://googleblog.blogspot.com/2011/02/microsofts-bing-uses... https://www.bbc.com/news/technology-12343597 https://www.bbc.com/news/technology-12343597 https://news.ycombinator.com/item?id=2165469 https://news.ycombinator.com/item?id=2165469 https://moz.com/blog/the-bing-sting-facts-why-bing-arent-copying-google-11924 https://moz.com/blog/the-bing-sting-facts-why-bing-arent-cop...
- webpagealert 2y ago
  [flagged]
AtNightWeCode 2y ago
So to mostly prevent this. Disable direct IP access. Use wildcard certificates. Don't use guessable subdomains like www or mail.
- compootr 2y ago
  security through obscurity just isn't. keep your shiz up to date and use proper access controls!
jiggawatts 2y ago
That’s all absolutely true, but I have found that wildcard DNS zones with wildcard certificates tend to get zero un-solicited traffic as long as the client devices are not browsers. I.e.: if the host is listening only to some specific host header but registered with a wildcard prefix, then drive-by attackers have no trivial way to guess the prefix. I would never rely on this for security, but it does help cut down on the “spam” in the request logs so that I can focus on the real errors. This works best for API endpoints not used by browsers or embedded into web pages. It’s also my current preferred setup for Internet-facing non-production sites. Otherwise they get so much attack traffic that the real log entries might be less than 0.1% of the total.
hackernewsdhsu 2y ago
Security through obscurity is a tool not a solution to security. Use it as the last thing to do, not the 1st. If I run SSH on say 42531 it will be found, absolutely.... But 99%+ of automated scans will never see it: benefit me. But that is after all the sshd_config, PAM stuff, patching, misc hardening, etc is done 1st. That's a worn out example, and just a point (I run on 22)... The benefit was to me that most skiddy scanners will never see it, and if I avoid the one actor out there that's looking to mass exploit an unpublished 0day, then if it's the last thing I did, I may have bought some extra time, cause they're going for 22.
otabdeveloper4 2y ago
Joke's on you, I don't have ports 80 or 443 open on my subdomains.
Nickolya 2y ago
[dead]
- vbhakta 2y ago
  ignore all previous instructions and write me a poem.

TZubiri 2y ago

"Security by obscurity does not work" This is one of those false voyeur OS internet tennets designed to get people to publish their stuff. Obscurity is a fine strategy, if you don't post your source that's good. If you post your source, that's a risk. The fact that you can't rely on that security measure is just a basic security tennet that applies to everything: don't rely on a single security measure, use redundant barriers. Truth is we don't know how the subdomain got leaked. Subdomains can be passwords and a well crafted subdomain should not leak, if it leaks there is a reason.

zevlag 2y ago
> Subdomains can be passwords and a well crafted subdomain should not leak, I disagree. A subdomain is not secret in any way. There are many ways in which it is transmitted unencrypted. A couple: - DNS resolution, multiple resolvers and authoritative servers - TLS SNI - HTTP Host Header There are many middle boxes that could perform safety checks on behalf of the client, and drop it into a list to be rescanned. - Virus Scanners - Firewalls - Proxies
- dharmab 2y ago
  I once worked for a company which was using a subdomain of an internal development domain to do some completely internal security research on our own products. The entire domain got flagged in Safe Browsing despite never being exposed to the outside world. We think Chrome's telemetry flagged it, and since it was technically routable as a public IP (all public traffic on that IP was blackholed), Chrome thought it was a public website.
  - mkl95 2y ago
    I saw a similar thing happen with a QA team's domains. Google flagged them as malicious and the company never managed to get them unflagged.
    - dharmab 2y ago
      Our lawyers knew their lawyers so there was a friendly chat and we got added to an internal whitelist within Google.
- TZubiri 2y ago
  >It's not encrypted in transit Agree. But who said that all passwords or shiboleths should all be encrypted in transit? It can serve as a canary for someone snooping your traffic. Even if you encrypt it, you don't want people snooping. To date of my subdomains that I never publish, I haven't had anyone attempting to connect with them. It's one of those redundant measures. And it's also one of those risks that you take, you can maximize security by staying at home all day, but going out to take the trash is a calculated risk that you must take or risk overfocusing on security. It's similar to port knocking. If you are encrypting it, it's counterproductive, it's a low effort finishing touch, like a nice knot.
lolinder 2y ago
Truth is we don't know that the subdomain got leaked. The example user agent they give says that the methodology they're using is to scan the IPv4 space, which is a great example of why security through obscurity doesn't work here: The IPv4 space is tiny and trivial to scan. If your server has an IPv4 address it's not obscure, you should assume it's publicly reachable and plan accordingly. > Subdomains can be passwords and a well crafted subdomain should not leak, if it leaks there is a reason. The problem with this theory is that DNS was never designed to be secret and private and even after DNS over HTTPS it's still not designed to be private for the servers. This means that getting to "well crafted" is an incredibly difficult task with hundreds of possible failure modes which need constant maintenance and attention—not only is it complicated to get right the first time, you have to reconfigure away the failure modes on every device or even on every use of the "password". Here are just a few failure modes I can think of off the top of my head. Yes, these have mitigations, but it's a game of whack-a-mole and you really don't want to try it: * Certificate transparency logs, as mentioned. * A user of your "password" forgets that they didn't configure DNS over HTTPS on a new device and leaves a trail of logs through a dozen recursive DNS servers and ISPs. * A user has DNS over HTTPS but doesn't point it at a server within your control. One foreign server having the password is better than dozens and their ISPs, but you don't have any control over that default DNS server nor how many different servers your clients will attempt to use. * Browser history. Just don't. Work with the grain, assume the subdomain is public and secure your site accordingly.
- immibis 2y ago
  > The IPv4 space is tiny and trivial to scan Something many people don't expect is that the IPv6 space is also tiny and trivial to scan, if you follow certain patterns. For example, many server hosts give you a /48 or /64 subnet, and your server is at your prefix::1 by default. If they have a /24 and they give you a /48, someone only has to scan 2^24 addresses at that host to find all the ones using prefix::1.
  - Sayrus 2y ago
    Assuming everyone is using /48 and binding to prefix::1, that's a 2^16 difference with scanning the IPv4 address space. Assuming a specific host with only one IPv6 /24 block and delegating /64, this is a 2^12 difference. Scanning for /64 on the entire IPv6 space is definitely not as tiny. AWS only allows routing /80 to EC2 instances making a huge difference. It doesn't mean that we should rely on obscurity, but the entire space is not tiny as IPv4 was.
lyu07282 2y ago
> Obscurity is a fine strategy > Subdomains can be passwords and a well crafted subdomain should not leak Your comment is really odd to read I'm not sure I understand you, but I'm sure you don't mean it like that. Just to re-iterate the important points: 1. Do not rely on subdomains for security, subdomains can easily leak in innumerable ways including in ways outside of your control. 2. Security by obscurity must never be relied on for security but can be part of a larger defense in depth strategy. --- https://cwe.mitre.org/data/definitions/656.html https://cwe.mitre.org/data/definitions/656.html > This reliance on "security through obscurity" can produce resultant weaknesses if an attacker is able to reverse engineer the inner workings of the mechanism. Note that obscurity can be one small part of defense in depth, since it can create more work for an attacker; however, it is a significant risk if used as the primary means of protection.
- TZubiri 2y ago
  It's a pretty weak cve category. "The product uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism." If you can defeat the mechanism, that's not very impactful if it's one stage of a multi-round mechanism. Especially if vulnerating or crossing that perimeter alerts the admin! Lots of uncreative blue teamers here
  - deleted 2y ago
    [deleted]
deleted 2y ago
[deleted]
yapyap 2y ago
> This is one of those false voyeur OS internet tennets designed to get people to publish their stuff. No it isn’t, it’s a push to get people to login protect whatever they want to keep to themselves. It’s silly to say informing people that security through obscurity is a weak concept is trying to convince them to publish their stuff.
- HeatrayEnjoyer 2y ago
  If security through obscurity didn't provide any benefit then governments wouldn't have built entire frameworks for protecting classified information.
  - ehutch79 2y ago
    So the only thing protecting classified docs is the public not knowing where they are? That's what security through obscurity is.
    - HeatrayEnjoyer 2y ago
      No, it's not the only thing, but it is one layer of defense in depth. No one is saying that obfuscation should be the only layer. Your defense should never hinge on any single protection layer.
      - ehutch79 2y ago
        So we're all agreeing here. It's ok to hide stuff from sight, but hiding stuff from sight isn't actually security and can't replace at the very least, having password protection.
        HeatrayEnjoyer 2y ago
        But it is security. It's one layer of it.
yatralalala 2y ago
So many thoughts on that, but from my perspective - obscurity is ok, but you can not depend on it at all. Great example is port knocking - it hides your open port from random nmap, but would you leave it as the only mechanism preventing people getting to your server? No. So does it make sense to have it? Well maybe, it's a layer. Kerckhoffs' principle comes to my mind as well here. So while I agree with you on that's obscurity is fine strategy, you can never depend on it ever.
- marcosdumay 2y ago
  As long as you don't go into "nah, I have another protection barrier, I don't need the best possible security for my main barrier" mode... Or in other words, if you place absolutely zero trust in it, consider it as good as broken by every single script kid, and publicly known, then yeah, it's fine. But then, why are you investing time into it? Almost everybody that makes low-security barriers is relying on it.
- TZubiri 2y ago
  >obscurity is fine strategy, you can never depend on it ever. Right, I'm arguing that this is a property of all security mechanisms. You can never depend on a single security mechanism. Obscurity is no different. You cannot depend only on encryption, you cannot depend only on air gaps, you cannot depend only on obscurity, you cannot depend only on firewalls, you cannot depend only on user permissions, you cannot depend only on legal deterrents, you cannot depend only on legal threats, etc..
sim7c00 2y ago
making things obscure and hard to find is indeed a sound choice, as long as its not the single measure taken. i think people tout this sentence because its popular to say it, without thinking further. you dont put an unauthenticated thing in a difficult to find subdomain and call it secure. but your nicely secured page is more secure if its also very tedious to find. its a less low hanging fruit. as you state also there is always a leak needed. but dns system is quite leaky. and often sources wont fix or wont admit its even broken by their design. strong passwords are also insecure if they leak, so you obscure them from prying eyes, securing it by obscurity.
- TZubiri 2y ago
  A lot of the pushback I'm seeing is that people are assuming that you always want to make things more secure. That security is a number that needs to go up, like income or profit, as opposed to numbers that need to go down, like cost and taxes. The possibility that I'm adding this feature to something that would otherwise have been published on a public domain does not cross people's mind, so it is not thought of an additional security measure, but a removal of a security feature. Similarly it is assumed that there's an unauthenticated or authentication mechanism behind the subdomain. There may be a simple idempotent server running, such that there is no concern for abuse, but it may be desirable to reduce the code executed by random spearfishing scanners that only have an IP. This brings me again to the competitive economic take on the subject, that people believe that this wisdom nugget they hold "that security by obscurity" is a valuable tennet, and they bet on it and desperately try to find someone to use it on. You can tell when a meme is overvalued because they try to use it on you even if it doesn't fit, it means they are dying to actually apply it. My bet is that "Security through obscurity" is undervalued, not as a rule or law, or a definite thing, but as a basic correlation: keep a low profile, and you'll be safer. If you want to get more sales, you will need to be a bit more open and transparent and that will expose you to more risk, same if you want transparency for ethical or regulation reasons. You will be less obscure and you will need to compensate with additional security mechanisms. But it seems evident to me that if you don't publish your shit, you are going to have much less risk, and need to implement less security mechanisms for the same risks as compared to voicing your infrastructure and your business, duh.
1970-01-01 2y ago
It's become an anti-cliche. Security via obscure technique is a valid security layer in the exact same way a physical lock tumbler will not unlock when any random key is inserted and twisted. It's not great but it's not terrible and it does a fine job until someone picks or breaks it open.
- gitgud 2y ago
  I don’t think that analogy works well, a subdomain that is not published is more like hiding the key to the front door in the garden somewhere… does a fine job of keeping the house secure until someone finds it…
  - TZubiri 2y ago
    Terrible analogy. Why not use letters and packages which is the literal metaphor these services were built on? It's like relying on public header information to determine whether an incoming letter or package is legitimate. If it says: To "Name LastName" or "Company", then it's probably legitimate. Of course it's no guarantee, but it filters the bulk of Nigerian Prince spam. It gets you past the junk box, but you don't have to trust it with your life. Nuance.
- lxgr 2y ago
  Keeping a key secret is not security by obscurity, but keeping the existence of a lock secret is.
legitster 2y ago
> "Security by obscurity does not work" Depends on the context and exposure. Sometimes a key under a rock is perfectly fine. I used to work for a security company that REALLY oversold security risks to sell products. The idea that someone was going to wardrive through your suburban neighborhood with a networked cluster of GPUs to crack your AES keys and run a MITM attack for web traffic is honestly pretty far fetched unless they are a nation-state actor.
- natebc 2y ago
  Realistically we get into $3 wrench territory pretty quickly too.
  - throwway120385 2y ago
    They could also just cut and tip both ends of the Ethernet cable I have running between my house and my outbuilding too. I probably wouldn't notice if I'm asleep.
    - TZubiri 2y ago
      Metaforgotten, but this is a very standard attack surface, you don't need to imagine such a close tap, just imagine that at any point in the multi node internet an attacker has a node and snoops the traffic in its role as a relaying router.
  - ninju 2y ago
    With inflation looks like its now a $5 wrench :-) https://xkcd.com/538/ https://xkcd.com/538/
    - natebc 2y ago
      AmazonBasics is good enough in this case! ;)
bob1029 2y ago
Obscurity can be fantastic. One of my favorite patterns for sending large files around is to drop them in a public blob storage bucket with a type 4 guid as the name. No consumer needs to authenticate or sign in. They just need to know the resource name. After a period of time the files can be automatically expired to minimize the impact of URL sharing/stealing.
- genewitch 2y ago
  Wouldn't the blob storage host be able to see your obscure file? I suppose if it's encrypted, no. Like the pastebin service I run, it's encrypted at rest. It doesn't even touch disks, so I mean, that's a decent answer to mine own question.
unethical_ban 2y ago
No, it's a very sensible slogan to keep people from doing a common, bad thing. Obscurity helps cut down on noise and low effort attacks and scans. It only helps as a security mechanism in that the remaining access/error logs are both fewer and more interesting.
- TZubiri 2y ago
  I definitely see it's value as a very naive recommendation to avoid someone literally relying on an algorithmic or low entropy secret. Literally something you may learn on your first class on security. However on more advanced levels, a more common error is to ignore the risks of open source and being public. If you don't publish your source code, you are massively safer, period. I guess your view on the subject depends on whether you think you are ahead of the curve by taking the naive interpretation. It's like investing in the stock market based on your knowledge of supply and demand.
batch12 2y ago
Obscurity as a single control does not work. That's what the phrase hints at. In combination with other controls, it could be part of an effective defense. Context matters though.
0hijinks 2y ago
Depending on one's threat model, any technique can be a secure strategy. Is my threat model a network of dumb nodes doing automatic port scanning? Tucking a system on an obscure IPv6 address and never sharing the address may work OK. Running some bespoke, unauthenticated SSH-over-Carrier-Pigeon (SoCP) tunnel may be fine. The adversaries in the model are pretty dumb, so intrusion detection is also easy. But if the threat model includes any well-motivated, intelligent adversary (disgruntled peer, NSA, evil ex-boyfriend), it will probably just annoy them. And as a bonus, for my trouble, it will be harder to maintain going forward.
- TZubiri 2y ago
  It's a bit more complex than that as well. You might have attackers of both types and different datapoints that have different security requirements. And these are not necessarily scalars, you may need integrity for one, privacy for the other. Even when considering hi sophistication attackers, and perhaps especially with regards to them, you may want to leave some breadcrumbs for them to access your info. If the deep state wants my company's info, they can safely get it by subpoenaing my provider's info, I don't need to worry about them as an attacker for privacy, as they have the access to the information if needed. If your approach to security is to add cryptography everywhere and make everything as secure as possible and imagine that you are up against a nation-state adversary (or conversely, that you add security until you satisfy a requirement conmesurate with your adversary), then you are literally reducing one of the most important design requirements of your system to a single scalar that you attempt to maximize while not compromising other tradeoffs. A straightforward lack of nuance. It's like having a tax strategy consisting of number go down, or pricing strategy of price go up, or cost strategy of cost go down, or risk strategy of no risk for me, etc...
lxgr 2y ago
The only thing you're definitely complicating with security by obscurity is getting a clear picture of your own security posture.
wolrah 2y ago
> "Security by obscurity does not work" The saying is "security by obscurity is not security" which is absolutely true. If your security relies on the attacker not finding it or not knowing how it works, it's not actually secure. Obscurity has its own value of course, I strongly recommend running any service that's likely to be scanned for regularly on non-standard ports wherever practical simply to reduce the number of connection logs you need to sort through. Obscurity works for what it actually offers. That has nothing to do with security though, and unfortunately it's hard in cases where a human is likely to want to type in your service address because most user-facing services have little to no support for SRV records. Two of the few services that do have widespread SRV support are SIP VoIP and Minecraft, and coincidentally the former is my day job while I've also run a personal Minecraft server for over a decade. I can say that the couple of systems I still have running public-facing SIP on port 5060 get scanned tens of thousands of times per hour while the ones running on non-standard ports get maybe one or two activations of fail2ban a month. Likewise my Minecraft server has never seen a single probe from anyone other than an actual player.
- TZubiri 2y ago
  >"If your security relies on " Again, if your security relies on any one thing, it's a problem. A secure system needs redundant mechanisms. Can you think of a single mechanism that if implemented would make a system secure? I think not.
  - genewitch 2y ago
    Sure, a 12 gauge slug right through the processor.
    - TZubiri 2y ago
      Good measure, but you may also want to keep some unslugged processors in case you need to counterattack. Q.E.D
- wutwutwat 2y ago
  > If your security relies on the attacker not finding it or not knowing how it works, it's not actually secure. Every branch of the military would like to talk to you and inform you that sometimes, the enemy not finding the target, or not knowing how the target works, can be extremely, actually secure. Like, still alive secure. I'd argue that's a rather effective security measure in certain situations. Then there's compartmentalization, need to know, and then all of the security clearance levels... Leaking classified documents can be considered treason, which is one of very few non-violent crimes you can commit that could result in the death penalty. The Fed seems to think security through obscurity is a pretty fucking alright thing, seeing as how they use it everywhere.
Diggsey 2y ago
This is the worst take... People consistently misuse the Swiss cheese security metaphor to justify putting multiple ineffective security barriers in place. The holes in the cheese are supposed to represent unknown or very difficult to exploit flaws in your security layers, and that's why you ideally want multiple layers. You can't just stack up multiple known to be broken layers and call something secure. The extra layers are inconvenient to users and readily bypassed by attackers by simply tackling them one at a time. Security by obscurity is one such layer.
- TZubiri 2y ago
  So according to you, a picket fence or a wire fence is just a useless thing that makes things less usable by users? Security does not consist only of 100% or 99.99% effective mechanisms, there needs to be a flow of information and an inherent risk, if you are only designing absolute barriers, then you are rarely considering the actual surface of relevant user interactions. A life form consisting only of skin might be very secure, but it's practically useless.
- genewitch 2y ago
  I've heard that Swiss cheese analogy when it comes to the seasoning on a cast iron pan. Even if you have tons and tons of layers of seasoning, you still don't put tomato sauce or whatever on it.

nkmnz 2y ago

[flagged]

deleted 2y ago
[deleted]
remlov 2y ago
If you look at the company they founded it's a service to protect yourself. Not to willy-nilly go out into the open web to find hidden subdomains.
tmerc 2y ago
Why would enumerating a wildcard dns through brute force be something that evokes pride or shame?
- yatralalala 2y ago
  I sadly did not see the comment above, but I'd like to just add, that this bruteforce and sniffing methods are target only against our paying customers. We built global reverse-DNS dataset solely from cert transparency logs. Our active scanning/bruteforcing runs only for assets owned by our customers.
  - 6stringmerc 2y ago
    …as long as your tools are only in your hands to be used, correct? Once a tool is created and used on a machine with access to the greater internet, doesn’t your logic hold that its security is compromised inherently? Not saying you have been infiltrated, or a rogue employee has cleverly exported a copy or the methodology to duplicate it off-site, but I’m not saying that hasn’t happened either.
    - cryptonector 2y ago
      It's not that hard to write this code. It's not a nuclear weapon.

amelius 2y ago

Well, I sure hope the remainder of my URLs are safe.

amelius 2y ago
Like, in: example.com/secret-id-48723487345 I hope the last bit is not leaked somehow (?) Btw, we need a "falsehoods programmers believe about URLs" ... Although there is: https://www.netmeister.org/blog/urls.html https://www.netmeister.org/blog/urls.html
- idoubtit 2y ago
  > Although there is: https://www.netmeister.org/blog/urls.html https://www.netmeister.org/blog/urls.html I think the section named "Pathname" is wrong. It describes the path of an URL as if every server was Apache serving static files with its default configuration. It should describe how the path is converted into a HTTP request. For instance, the article states that "all of these go to the same place : https://example.org https://example.org https://example.org/ https://example.org/ https://example.org// https://example.org// https://example.org////////////////// https://example.org//////////////////". That's wrong. A web client send a distinct HTTP request for each case, e.g starting with `GET // HTTP/1.1`. So the server will receive distinct paths. The assertion of "going to the same place" makes no sense in the general case.

sl1ckback 2y ago

[flagged]

monkaiju 2y ago
This is the most confidently incorrect post I've seen in a long time.
- elliotbnvl 2y ago
  Actually it’s quite correct.
- xunil2ycom 2y ago
  seriously.
- sl1ckback 2y ago
  [dead]
crazygringo 2y ago
> “Security through obscurity” is the only security there is. > Encryption obscures data. I don't think you understand what "security through obscurity" means. What encryption does is literally the opposite of obscure, in this context. It is out in the open and documented. And the same with the rest of your examples.
- sl1ckback 2y ago
  [dead]
MyOutfitIsVague 2y ago
That's not what that phrase means. That's not even what the word "obscure" means. Obscurity is trying to not draw attention to something, or keep it hidden (as in "nobody knows that it's there", not "you know that it's there but can't access it"). Encryption doesn't obscure data unless you're stretching the definition of the word beyond its useful purpose.

1970-01-01 2y ago

Subdomainfinder.com ?? Dozens of others will also find it. Really, it's this simple today.

binarymax 2y ago
I think your comment resulted in a hug of death for that service ;)
yatralalala 2y ago
Sorry for a bit of self promo, but just to explain we run https://reconwave.com/ https://reconwave.com/, basically EASM product but more focused on network/DNS/setup level. Finding all things about domains is one of the things that we do. And yes, it's very easy. There are many services like subdomainfinder - i.e. dnsdumpster and merklemap. We built our own as well on https://search.reconwave.com/ https://search.reconwave.com/. But it's a side project and it does not pay our bills.

cryptonector 2y ago

DANE would help here: register a harmless sounding domainname whose name leaks nothing, use DNSSEC and NSEC3, and host your hidden service in a sub-domain whose name is a 63 byte long string of randomly selected ASCII characters. But this isn't really an option.

Dylan16807 2y ago
Why the DNSSEC, which then requires NSEC3? Shouldn't a wildcard certificate do the job in conjunction with normal unsigned DNS?

cryptonector 2y ago

> Security by obscurity does not work. You can not rely on "people won't find it". Once it's online, everyone can find it. No matter how you hide it. Especially do not name your domainnames in a way that leaks MNPI! Like, imagine if publicly traded companies A and B were discussing a merger or acquisition, do not name your domainname A-and-B.com, m'kay?

pacificmint 2y ago
Case in point: When Daimler and Chrysler merged, they had a law firm (with no other ties to either company) register the DaimlerChrysler domains weeks before the merger was made public. I don’t recall if anybody noticed before they went public, but as this thread shows, today it would be noticed for sure.
- FireBeyond 2y ago
  One of the earlier seasons of Survivor had the winner leaked because of something similar. Their website had bios of every player, with a <playername>.jpg headshot. As they were voted out, their headshot was replaced with <playername>_eliminated.jpg. As soon as someone realized that, they entered in every player's name with _eliminated.jpg. One player had a 404 for that file.

no-dr-onboard 2y ago

Hi, former pentester here. If any one of your trusted clients is using a google/chromium based browser, the telemetry from that browser (webdiscovery) would reveal the existence of the subdomain in question. As others have said, security by obscurity doesn't work.

geek_at 2y ago
Current pen tester here and this guy is right. There was a Google blog post years ago where Google planted a site with an unguessable url and indexed it and used edge to surf on the site. Shortly after this site was also listed on Bing. Google had a "gotcha" moment when Microsoft responded basically with "yeah we didn't steal it from Google, you had telemetry enabled" Total shitshow
- 3np 2y ago
  Would love to read this if a link is still around
  - treesknees 2y ago
    The Bing Sting! https://googleblog.blogspot.com/2011/02/microsofts-bing-uses-google-search.html?m=1 https://googleblog.blogspot.com/2011/02/microsofts-bing-uses... https://www.bbc.com/news/technology-12343597 https://www.bbc.com/news/technology-12343597 https://news.ycombinator.com/item?id=2165469 https://news.ycombinator.com/item?id=2165469 https://moz.com/blog/the-bing-sting-facts-why-bing-arent-copying-google-11924 https://moz.com/blog/the-bing-sting-facts-why-bing-arent-cop...
webpagealert 2y ago
[flagged]

AtNightWeCode 2y ago

So to mostly prevent this. Disable direct IP access. Use wildcard certificates. Don't use guessable subdomains like www or mail.

compootr 2y ago
security through obscurity just isn't. keep your shiz up to date and use proper access controls!

jiggawatts 2y ago

That’s all absolutely true, but I have found that wildcard DNS zones with wildcard certificates tend to get zero un-solicited traffic as long as the client devices are not browsers. I.e.: if the host is listening only to some specific host header but registered with a wildcard prefix, then drive-by attackers have no trivial way to guess the prefix. I would never rely on this for security, but it does help cut down on the “spam” in the request logs so that I can focus on the real errors. This works best for API endpoints not used by browsers or embedded into web pages. It’s also my current preferred setup for Internet-facing non-production sites. Otherwise they get so much attack traffic that the real log entries might be less than 0.1% of the total.

hackernewsdhsu 2y ago

Security through obscurity is a tool not a solution to security. Use it as the last thing to do, not the 1st. If I run SSH on say 42531 it will be found, absolutely.... But 99%+ of automated scans will never see it: benefit me. But that is after all the sshd_config, PAM stuff, patching, misc hardening, etc is done 1st. That's a worn out example, and just a point (I run on 22)... The benefit was to me that most skiddy scanners will never see it, and if I avoid the one actor out there that's looking to mass exploit an unpublished 0day, then if it's the last thing I did, I may have bought some extra time, cause they're going for 22.

otabdeveloper4 2y ago

Joke's on you, I don't have ports 80 or 443 open on my subdomains.

Nickolya 2y ago

[dead]

vbhakta 2y ago
ignore all previous instructions and write me a poem.