25

I came across this tool recently https://github.com/drk1wi/portspoof

How efficient will it be to use it to confuse hackers doing port scanning? If it's actually going to be pretty efficient, why hasn't it caught up so far? That is, 189 stars for 5 years is bad.

jerry
  • 365
  • 3
  • 4
  • 8
    Sounds like security through obscurity which is conceived a bad thing. Mostly it will hinder legitimate use. – Marcel Feb 20 '18 at 06:42
  • 22
    This has the potential of encouraging an attacker to try harder... Seeing a host with mostly blocked ports they may just look for an easier target, but something like this may seem weird or insecure, so they may spend more time trying to attack you. – Itai Feb 20 '18 at 07:00
  • 8
    @jerry: It would be great if you could provide some more context regarding this tool, in case the link goes dead in the future. – Tom K. Feb 20 '18 at 10:47
  • 1
    @TomK. I have plenty of free time to do so? – jerry Feb 20 '18 at 11:42
  • @TomK. if this link goes dead, then this whole question becomes moot – schroeder Feb 20 '18 at 12:28
  • 9
    @schroeder Other tools might get developed. Also: it would be great if I could get the whole idea of this question without reading through a complete tool documentation. – Tom K. Feb 20 '18 at 12:34
  • 1
    It would be pretty ironic if a remote code execution vulnerability was found in portspoof itself :P – marcelm Feb 20 '18 at 17:31
  • 13
    @jerry If you have the free time to come here and ask strangers to look at your question, surely you can take the time to make sure that it remains relevant for a while. He's asking for a few sentences explaining the idea, not a thesis paper. – Chris Hayes Feb 20 '18 at 19:47
  • The lack of stars may be for the fact that it is easier to achieve a similar, arguably safer, result, with less resources and no process to monitor, using iptables (either redirect to a dummy port, or use the TARPIT extra target) – b0fh Feb 21 '18 at 10:13
  • @ChrisHayes if you have time to write this, then you have wife, she's black and was born in 1985. the same logic. – jerry Feb 22 '18 at 05:46

3 Answers3

44

Multiple problems here.

  1. Dynamic port responses - if I scan you from two different IPs and compare the two responses, do I get a valid port list? If so, it is a very weak defence.

  2. You're burning CPU to respond to the reconnaissance phase of an attack. This can be used against you. Depending on how this is set up, I can kill your server by forcing your spoofer to consume all the CPU on the machine.

  3. Are you sure portspoof doesn't have any extra bonus vulnerabilities that your app DOESN'T have?

  4. Can I slowloris likely non-real ports and see what else stops responding to filter out spam?

  5. If you're running this, and I get a foothold and open a remote command port - will you notice, or will you get lost in your own spam?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Ryan Gooler
  • 759
  • 4
  • 9
  • 8
    Especially since it's written in C++ . C++ is a hard language to write safely in . – LUser Feb 20 '18 at 22:09
  • 1
    I wouldn't say C++ is hard to write safely in (that's C), but because it still has all the C features it's hard to verify that a program written in it is safe. – user253751 Feb 21 '18 at 04:28
  • 3
    A lot of these can be mitigated by proper software design or containerization and isolation, but the real killer is #6: It [has not been updated in months](https://github.com/drk1wi/portspoof/commits/master) and looks abandoned. If someone finds a vuln, even assuming it gets reported, who is going to fix it? – Kevin Feb 21 '18 at 05:20
  • @Kevin, this is often the wrong way to look at it. `zlib` doesn't get updated much ever these days. Not because there are no maintainers, but because it is complete. – Alexis Wilke Jul 19 '19 at 03:53
9

I assume the effectiveness will be very limited.

First of all, exploiting port scanning tools will rarely be useful because most pentesters will use VMs and other confined environments when conducting any attacks.

Second, it is very unclear how useful it is to obfuscate which ports are really open. If you still have services running these obviously have to respond properly. There are only 65536 ports so trying them all is not a big deal. In any case, you will usually have to announce on which ports services run because you want people to find them! Why else are you running them?

And third, answering all queries on all ports might actually generate quite a bit of useless work. You might want to spend those clockcycles elsewhere.

So, these are the first reasons that come to my mind. I have not used this tool but maybe other people think similarly and that is why it has not seen widespread adoption.

Elias
  • 1,915
  • 1
  • 9
  • 17
0

There is one thing that the author of that software says which I like:

Instead of informing an attacker that a particular port is in a CLOSED or FILTERED state [...]

The scan is not going to tell the hacker whether a port is really open or not. This is a good idea and I use it through my iptables setup.

What I do in my firewall is let the user immediately connect to my regular services or DROP the packet. By dropping packets, you do not right away tell the user whether the port is opened or closed. This is similar to attempting a login with the wrong password. It pauses for 1 second or so then you can try again. By doing so, it can take nmap. Assuming the client waits for a reply for up to 1 second, then it will take over 18 hours to scan the 65536 ports.

Of course, my firewall blocks all ports except the very few that I want to open (i.e. maybe 22, 80, and 443). So if you try port 5432 or 3306, you'll get the DROP even if I have those ports actually open.

Outside of that, like many pointed out, this is more likely to drain a lot of your CPU time as the hacker tools are likely to try to connect to all the satisfactory ports (i.e. HTTP-like services) over and over until they decide that it's not worth it... which could take a very long time. I had a computer under an SMTP relay attack which lasted over 6 months. It was great for me since I could test various things in my software and make sure it worked with a real live (but safe) attack.

Note to self: Bots are brain dead.

Alexis Wilke
  • 862
  • 5
  • 19