Need help using traffic shaping to created severely degraded SSH

[fmaxwell]

I've spent the last two days attempting to use limiters to severely degrade (bandwidth, latency, and packet loss) traffic to an SSH honeypot server.  The purpose is to tie up Chinese hackers who are attacking SSH servers.

I've failed, over and over, and I do not know what is wrong.

I have an SSH honeypot server running on port 2222 on a (virtual) computer with a LAN IP of 192.168.0.202.  It's been working fine internally and externally without the limits.
I have a NAT rule to forward packets from WAN_Address, port 22 to 192.168.0.202, port 2222.  It works fine.
I have an unassociated Filter rule to pass packets destined for 192.168.0.202, port 2222.  It also works fine.

I have treated two limiters:  TarpitIn and TarpitOut.  Each is currently set at a megabit per second with no additional latency or packet loss.

Every time I attempt to use them in any filter rule (not just the one in question), traffic ceases flowing.  The log file still shows that the rule is passing the packets.

I'm at an utter loss and would welcome any help that anyone could provide.  I've included a few screen captures to show the associated rules and limits.

Regards,
  Fred

Note:  Although the descriptions of the limits indicate that there is packet loss and extra latency (delay), there is none now (while I debug).

[EMWEE]

Open port 22 on your WAN not 2222. 2222 should be open on your honeypot.

I dont understand your reason to open SSH on your WAN. Just keep it closed.

[fmaxwell]

@EMWEE:

Open port 22 on your WAN not 2222. 2222 should be open on your honeypot.

Port 22 is open on the WAN.  Otherwise, it would not work when I remove the limiters.

If you look at the NAT rule, you will see that port 22 on the WAN forwards to port 2222 on the honeypot.

[EMWEE]

You posted a screenshot of a firewall rule with 2222.

[fmaxwell]

@EMWEE:

You posted a screenshot of a firewall rule with 2222.

Yes.  The NAT rule (also posted above and attached here) is what opens up the WAN port number 22.  The Firewall rule is what opens up the redirected LAN port number 2222.

Without the limits in place, everything works.

• The hacker connects to the standard SSH port (22)

• The NAT forwarding rule redirects the traffic to my honeypot server at 192.168.0.202 on port 2222.

• The firewall rule sees traffic destined for 192.168.0.202, port 2222, and passes the traffic, logging it to the firewall log.

@EMWEE:

I dont understand your reason to open SSH on your WAN. Just keep it closed.

Because that's the standard SSH port that hackers try access. I want them to connect and waste their time trying to log on.  If I put the server at 2222, then they won't find it.  They will come in on the SSH port (22), get rejected or blocked, and never reach the honeypot.

From a how-to on kippo, the SSH honeypot:

"Now kippo uses port 2222 to run its honeypot on, in order to send evil hackers to that port you need to use your home router (which hopefully can do port forwarding) to send all traffic for port 22 to 2222. I’m not going to explain how to do this because everyone’s router is different. So go ahead and configure that port forwarding ready for when we start kippo."


[EMWEE]

Post a screen of your WAN rules.

[fmaxwell]

@EMWEE:

Post a screen of your WAN rules.

I've enclosed them here.  Thanks.

{Removed screenshot of rules.  The person who made the request for the rules did not do so in order to answer my question.}

[BBcan177]

Why not install the package pfBlockerNG and limit which IPs can access the open ssh port plus block known malicious IPs.

https://forum.pfsense.org/index.php?topic=86212.0

[EMWEE]

Don't open the port at all.

Remove the bullshit rules. Your firewall blocks traffic not listed by default.

[fmaxwell]

@EMWEE:

Don't open the port at all.

Remove the {expletive} rules. Your firewall blocks traffic not listed by default.

I'm not soliciting opinions on my tarpitting project.  I asked for assistance getting traffic shaping limits working.  If you don't know how to do that, then say so.  I will thank you for trying and will wait for someone who does know how.

My purpose is not to block or reject traffic.  It is to tarpit systems mounting brute force dictionary SSH attacks.

[fmaxwell]

@BBcan177:

Why not install the package pfBlockerNG and limit which IPs can access the open ssh port plus block known malicious IPs.

I have pfBlockerNG installed and use it extensively.

But using it to block SSH won't provide me with evidence to use in reporting those making SSH brute force attacks.  I won't be able to analyze the malicious payloads they deliver to determine what they do and with what systems they communicate.  I won't be able to study the ACL changes they try to make.

I just got about half a dozen such attackers shut down by Amazon Web Services using evidence gathered by the SSH honeypot, but I don't wish to continue to have my log files filling up at such a high rate and so much of my bandwidth being used in the process.

[stephenw10]

You are probably hitting this: https://redmine.pfsense.org/issues/4326
Set the limiter on the LAN side or try a 2.2.3 snapshot where I believe a patch has now gone in: https://redmine.pfsense.org/issues/4596

Steve

[fmaxwell]

@stephenw10:

You are probably hitting this: https://redmine.pfsense.org/issues/4326
Set the limiter on the LAN side or try a 2.2.3 snapshot where I believe a patch has now gone in: https://redmine.pfsense.org/issues/4596

Steve

Steve,

Thank you!  A quick scan of that bug looks like it's a good bet as to the source of the problem.  I've been pulling my hair out trying to figure out what's wrong.  Everything's working and then I insert the two limit queues into the firewall rule and everything just stops.

Regards,
  Fred