Hacker News Reader

Comment by habibur | Hacker News Reader

Sometimes I think custom writing your own http server might not be a bad idea after all.

Lots of security holes in your custom write? Yes! But the hacker needs to be dedicated to exploiting your one server specifically to find it.

In exchange you are safe from of all those : vulnerabilities in the wild => script kiddies => mass exploitation => your are now hacked type of situations.

View on HN

Relying on obfuscation as part of your security posture is a fantastic idea IMO. Just be prepared for what happens if a human figures out your specific puzzle box.

We like exposing our private B2B web services in such a way that an attacker would be led to think the web server is totally fucked up or otherwise mis-configured if they don't understand the proprietary protocol. It's not that they could never understand it, but it would take a significant, targeted effort to even begin attacking our system in a direct fashion. Even if they figure out the obfuscation, they are still going to have to fight through a moat of PBKDF2 & hardware tokens.

To me, obfuscation is all about minimizing the impact of automated, mass, 0-day assaults. Some person will always be able to walk back something another person built. You can mitigate legions of scripts by cleverly dropping TCP connections when a resource isn't requested in just the right way.

Another fun option is to build a honey pot around your web service which has the ability to ferret naughty TCP pipes off to the hacker matrix where you then simulate all manner of PII-rich data sources for them to worry about (instead of your actual business).

> To me, obfuscation is all about minimizing the impact of automated, mass, 0-day assaults.

It's the infosec equivalent of not needing to outrun the bear, just your friend.

Make your stack annoying enough to attack and attackers will move on to other targets.

Security through obscurity is great for preventing low-effort attacks at low-scale, yes.

The market for security skills tends to be more interested in protecting targets that can draw high-effort attacks, or low-effort attacks at scale, so there's good reason for the "security through obscurity = bad" meme. You won't get in trouble by incorrectly assuming "security through obscurity = bad," but you can definitely get in trouble by incorrectly generalizing "security through obscurity = good enough." It makes sense to err in the direction of least damage.

I don't see how this could be true for an HTTP server. If we were discussing some custom protocol, sure. But with HTTP, you are far more likely to repeat well-known mistakes and vulnerabilities that have long-since been eliminated from the popular HTTP servers.

That's an interesting point. I would love to see someone testing this assumption.

This is a great idea where people can submit their own web servers that have some basic functionalities and are on the side would be users who gets points/karma for exploiting them under some threshold like 3 hours. Maybe something like DevCon's Capture-the-Flag but online.

> In exchange you are safe from of all those : vulnerabilities in the wild => script kiddies => mass exploitation => your are hacked type of situations.

Not sure about that... You might commit some of the same mistakes that they did

Exactly what I was thinking. You’re more likely just to have a wide open and highly/easily penetrable/vulnerable server up for grabs at that point.

Presumably you'll have less features. I wrote a web server (in the 90s, so forgivable?), and I only implemented GET and query string for the API data, and nothing fancy, no cache headers, no redirects, no multipart, no gzip, no content-encoding negotiation, etc. Some of the APIs it hosted were ultimately hacked (thru encryption of the encrypted query string via plain DES, and the key was determined), but, so far as I know, it was not itself ever compromised.

Not impossible that your web server was 100% secure, but I doubt it because I think that I have never seen a server that didn't eventually need security patches.

I left the company and then about ten years later it was turned off. It was in C but was pretty mature framework, not C style strings. And the code was just “validate assumption for parsing, else return error” then “parse the next few bytes else return error”. Very simple small number of parameters, explicit length limits everywhere. And it was a public AOL end point so widely and continually attacked by people. I was there for maybe 7 years after deploying it and nothing (known) happened in that time.

Ah yes, that would make sense.

I encourage you to test this theory at your earliest convenience.

writing your own on top of established networking lib will have much less code thus smaller attack surface.

Reply on news.ycombinator.com