MariaDB explicitly checks if the port is non-zero before listening on a TCP socket:

https://github.com/MariaDB/server/blob/ae998c22b2ce4f1023a6c...

> if (mysqld_port)

> activate_tcp_port(mysqld_port, &listen_sockets, false);

if (mysqld_port) means "if mysqld_port is different from 0"

This seems to be at least in MariaDB 5.5 (year 2012)

You can even use it under Linux if you wish btw, you just can't bind to it, but you can have your firewall redirect port 0 to something else.

IMO this is still a passive type of security through obfuscation. Active defence would be more like returning zip bombs to known intruders in order to crash the process.

IT is growing up gradually. It's only had a few decades to worry about security and I've seen most of them.

One day, IT will become time served but not today.

I'm not sure I like this analogy since the immune system regularly malfunctions and damages the host (allergies, cancer, etc) but then again, it does draw some concerning parallels,.

AI should enable high quality and deep honeypots. It's perfect for the current llm capabilities... Just look good enough.

Our skin doesn't pretend to be a mouth I don't think.

https://en.wikipedia.org/wiki/List_poisoning

Am I missing something or is it truly infinite?

I guess it'll be obvious that a server is running portspoof after you find that 3 random services that nobody uses anymore seem to be running, but now that you know the host is up, which ports do you tinker with?

If you assume that scanning/attacking each port on each server takes about the same effort, you are better off finding a machine where the scan/attack has a higher chance of being successful, even if you can tell which ports are spoofed and not worth attacking.

Maybe you can run portspoof locally on 127.0.0.35 and compare which responses seem different (data, timings) from what you get back, but the space is suddenly 5000x bigger than the handful of ports that normally seem to be open and ports on other servers may seem more likely to yield success.

I agree, returning legit banners on common ports is likely to get you looked at more rather than less, since most tools are not accounting for situations where every single port is open, indicating false positives. This is a common scenario on penetration tests, and while it does end up wasting time, I'd rather not give attackers any more reason to be looking at my infra. I would prefer port knocking, which is kinda of the polar opposite approach to this.

Yea, thinking about it for a minute I would expect limited threat models this tool would help with. I think for broad attacks, this would only be somewhat effective if deployed on tens of millions of hosts so it becomes impractical because the adversary is just finding and interacting with the honeypots.

If you are specifically getting targeted, there might be a slight delay by having the adversary try and exploit the honeypot ports, but if you're running a vulnerable service you still get exploited.

Also if you're a vendor, when prospective customers security teams scan you, you'll have some very annoying security questionnaires to answer.

Not a network security expert, but the level of traffic necessary to figure out whats real would probably trip other detection mechanisms in the process.

If you're worried about mass internet scans, I can see the downsides. But if you're worried about a targeted attacker scanning just your organization’s IP ranges, this seems like it would hinder them quite a bit.

You also now have to worry about vulnerabilities in portspoof.

iptables rule redirects all closed ports on the machine to the one portspoof listens to: https://github.com/drk1wi/portspoof/blob/c3f3c34531c59df229e...

Then it calls getsockopt to find out what the original port was: https://github.com/drk1wi/portspoof/blob/c3f3c34531c59df229e...

why? A single process can bind to multiple ports. I don't know what's the hard limit actually, or how much memory it would use. Probably a port redirect would just be simpler.

nat-redirection

Yea, that statement confused me as well.

Isn't that precisely what a honeypot is meant to do though? Having ports open so that script kiddies get excited they get access to something, but the something just isn't anything? Having a honeypot that is locked down doesn't really seem like a honeypot at that point

Perhaps one of us misunderstands the term honeypot, it could be me, but IMO this seems perfectly usable to create a honeypot system on your network.

A honeypot is used to attract and detect an attacker, usually logging their actions and patterns for analysis or blocking. This tool could use more logging beyond just iptables, and sure it’s not _by itself_ a honeypot, but the idea isn’t that far off.

All that aside, the GitHub page suggests this “enhances OS security” which I don’t buy one bit. Sure it provides some obfuscation against automated service scanners, but if you have a MySQL server listening on 3306, and an attacker connects to 3306, they’re still talking to MySQL. Doesn’t matter if all the other 65534 ports are serving garbage responses.

For TCP services, it won't send a large packet until the "client" provides a correct ACK packet to complete the three way handshake.

This would indeed be pants-on-head for UDP.

Amplification attacks are mainly a concern with UDP because UDP does not have a return routability check, while TCP does.

You will get the WordPress scans regardless of what you return.

Fascinating. I was going to ask if there were similar projects. It seems like an obvious thing to do and I was mildly surprised that it never occurred to me and majorly surprised that this was the first time I'm hearing about the idea.

iptables only provides one of the two approaches detailed, namely the "ack" portion. For the "fake a random real service on each port" portion you'd need something additional like this.

If it was the case that the way all attackers worked was to have one ready exploit and only scan the port on which that exploit could work, then why are there good guys even seeing port scanning at all?

Haven't looked into this too deeply but there is a difference between delaying a response (requests get stuck in the tarpit) vs providing a useless but valid response. This approach always provides a response, so it uses more resources than ignoring the request, but less resources than keeping the connection open. Once the response is sent the connection can be closed, which isn't quite how a tarpit behaves. The Linux kernel only needs to track open requests in memory so if connections are closed, they can be removed from the kernel and thus use no more resources than a standard service listening on a port.

There is a small risk in that the service replies to requests on the port, though, as replies get more complicated to mimic services, you run the risk of an attacked exploiting the system making the replies. Another way of putting it, this attempts to run a server that responds to incoming requests on every port, in a way that mimics what might run on each port. If so, it technically opens up an attack surface on every port because an attacker can feed it requests but the trade-off is that it runs in user mode and could be granted nil permissions or put on a honeypot machine that is disconnected from anything useful and heavily tripwired for unusual activity. And the approach of hardcoding a response to each port to make it appear open is itself a very simple activity, so the attack surface introduced is minimal while the utility of port scanning is greatly reduced. The more you fake out the scanning by behaving realistically to inputs, the greater the attack surface to exploit, though.

And port scanning can trigger false postives in network security scans which can then lead to having to explain why the servers are configured this way and that some ports that should always be closed due to vulnerability are open but not processing requests, so they can be ignored, etc.

Provided you make the source for any derivative works available to your customers.

It’s not uncommon that in situations where that’s undesirable (e.g. a closed-source C library that statically links a GPL’d project) that the library owner pays a fee for a separate license allowing that closed-source distribution.

Also, this is sometimes done when it’s not strictly legally necessary, either for risk avoidance or as a way to support the project in corporate environments where “licensing fee” gets waved through but “donation” gets blocked.

You can buy your way out of the GPL if the authors are willing to relicense.

Stallman was actually an advocate of doing this.

https://www.fsf.org/blogs/rms/selling-exceptions

I believe the author is saying they're willing to relicense the software for commercial integrations.

The original copyright holder can enforce what they like

Per the README

    it binds to just ONE tcp port per a running instance !
    Configure your firewall rules:
    iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 1:65535 -j REDIRECT --to-ports 4444

>So... Security through obscurity?

This is not a valid criticism on its own.

Security through obscurity is bad when obscurity is the only thing stopping an attacker. It's a meme because obscurity is not a substitute for stronger security mechanisms. That does not mean it cannot be an appropriate compliment to them, however.

If I wanted to hide a gold bar, sticking it in an open hole behind a painting on the wall wouldn't be particularly great security. As soon as a robber found the hole, the entirety of my security is compromised.

If I put it in a safe on the wall, it's much more secure. The robber has to drill through the lock to get the gold bar.

If I put it in a safe behind a painting on the wall, the robber has to discover that there's a safe there before they're able to attempt drilling through it. Bypassing the painting is trivial compared to bypassing the safe, but the painting reduces the chance of the actual safe being attacked (up until it doesn't!)

Security should be layered. Obscurity will generally be the weakest of those layers, but that doesn't mean that it has no value. As long as you're not using obscurity as a replacement for stronger mechanisms, there's nothing wrong with leveraging it as part of a larger overall security posture.

Accepted cryptography is also security through obscurity. The thing is that the amount of obscurity must be quantified. Cryptanalysis allows one to calculate these quantities of "obscurity." Then, a full study of effectiveness combines that with the costs associated with brute-forcing the bounds arrived at by the cryptanalysis.

Other parts of infosec are the same, but often with less well-quantified measures of effectiveness. E.g. memory hardening techniques like FORTIFY_SOURCE and MTE are effective in raising the difficulty of exploiting memory vulnerabilities, but under some conditions the vulnerabilities may still be exploitable.

Before using labels like "security through obscurity" one has to first answer: how much does the technique raise the cost for attackers? This is what articles about security systems (including this one) should focus on. In the end, hacking, like most things, comes down to economics.

People who criticize 'security through obscurity' don't know how hard it is to reverse engineer shit.

Either that or they're researchers or adversaries playing a game. Because trying to figure out WTF is going on is hard, so any clues you can extract from your targets makes things easier.

When you see someone probing every single port on the box, you know they’re either a bad actor, or a security tool. No legit user is going to keep hammering ports without a known service.

Bad actors you can either block or counter attack. Security tools should be registering their address with whatever internal tracker you’re using so they can be white listed.

The objective here is to give script kiddies and other spray-and-pray attackers the finger.

Look up post-exploit mitigations, such as ASLR and pointer authentication. These are mechanisms that only become relevant when software has already been breached. In most cases, they cannot entirely prevent further progress by the attacker, just make it significantly harder.

Similar principle (only on the other end).

Security through obscurity is somewhat helpful even though it can be defeated. Take camouflage and honeypots for example. It would probably be unwise to use this without a thorough audit of the code however.