Port 0 is a port some operating systems can and do host services on accessible over the Internet.
Also - if there's any MariaDB devs reading this - your default setting making the database listen on port 0 to disable Internet access does not, in fact, disable Internet access of the DB for quite a few thousand systems.
And if you set MariaDB to not have Internet connectivity, it attempts to accomplish this by setting the TCP port to 0. Ostensibly because it's not supposed to be a valid TCP port, except it actually is on thousands and thousands of systems.
So I don't know if the check you're referencing is evaluated when someone sets their instance of MariaDB to "not" be internet accessible.
It feels inevitable that computer security will continue evolving towards "active defense" typified by approaches like the above. Look at how complex and many-layered your immune system is, and consider that eventually your computer and/or network will resemble that as well.
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 appears it can be configured to actively return attacks:
> Portspoof can be used as an 'Exploitation Framework Frontend', that turns your system into responsive and aggressive machine. In practice this usually means exploiting your attackers' tools and exploits
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,.
The immune system is an incredible marvel of engineering, protecting you against an infinite number of attack vectors without any online database update after initial installation. It develops countermeasures on the fly, deploys layers of Defense that coordinate intelligently as a swarm, and keeps track of which molecules belong to „you“ while those molecules keep replacing themselves with those obtained from the outside. It constantly ingests signals from billions of sensors over your body which function as first-responder Defense measures as well as repair kits AND evidence capsules for the cavalry that rolls in later. And that’s just a sliver of all the ingenious ways the immune system works.
Be aware that if you run something like this, you will get dozens of bug bounty requests by people who scanned your machine and found "known vulnerable version of X" running.
In the mid-90s, there was a honeypot product called CyberCop Sting[1], which predated Secure Networks' Ballista[2]. CyberCop Sting could simulate TCP and UDP services across various implementations. If I recall correctly, it also allowed the configuration of TCP/IP stacks to mimic the behavior of different operating systems. These features were particularly innovative almost 30 years ago.
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.
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.
By default, return nonsense on all ports. But once a certain access sequence has been detected from a source IP, redirect traffic to a specific port from just that IP to your real service.
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.
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.
I do something similar on my website: https://bini.wales returns 200 for all endpoints and logs all attempts, so it makes for a decent have a honeypot against automated attacks (mostly it just catches people mass scanning for vulnerable WordPress plugins or leftover backdoors). Similarly, https://varun.ch/login emulates a WordPress site (with a twist)
Nice, I'm glad the word "honeypot" is never used, once I inherited a "true" honeypot and when I went to check it, it had like 30 ports opened, my reaction was literally "what the fuck is this crap" said out loud.
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
I do red team, if I see a server with 20+ ports I'll immediately assume it's a honeypot and will stop scanning it. If you are part of a blue team you WANT them to waste time, not instantly know it's a honeypot, that's what I meant for specifically this software.
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.
All the responses look legitimate though, so even if someone does hit that MySQL, they'll be hard pressed determining it's not part of the noise of the other 65.5k legitimate-seeming responses. They'll just be wasting resources trying to get beyond such a broad surface to gain any depth. And if they already know to target MySQL (or any other particular service), it's all moot in any case, but also they wouldn't be doing a spectrum scan.
I do red team, if I see a server with 20+ ports I'll immediately assume it's a honeypot and will stop scanning it. If you are part of a blue team you WANT them to waste time, not instantly know it's a honeypot, that's what I meant for specifically this software.
Readit News
Port 0 is a port some operating systems can and do host services on accessible over the Internet.
Also - if there's any MariaDB devs reading this - your default setting making the database listen on port 0 to disable Internet access does not, in fact, disable Internet access of the DB for quite a few thousand systems.
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)
So I don't know if the check you're referencing is evaluated when someone sets their instance of MariaDB to "not" be internet accessible.
> Portspoof can be used as an 'Exploitation Framework Frontend', that turns your system into responsive and aggressive machine. In practice this usually means exploiting your attackers' tools and exploits
Deleted Comment
One day, IT will become time served but not today.
I wholeheartedly recommend reading „Immune“ by Phillip Dettmer: https://www.amazon.de/dp/0593241312
http://web.archive.org/web/20020610054821/http://www.sourtim...
[1] https://theswissbay.ch/pdf/Gentoomen%20Library/Security/0321...
[2] https://news.ycombinator.com/item?id=26440139
I doubt that most script kiddies are filtering out potential honeypots/things like this from their tools.
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.
By default, return nonsense on all ports. But once a certain access sequence has been detected from a source IP, redirect traffic to a specific port from just that IP to your real service.
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.
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.