Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Need help using traffic shaping to created severely degraded SSH

    Scheduled Pinned Locked Moved Traffic Shaping
    13 Posts 4 Posters 1.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      fmaxwell
      last edited by

      @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.

      1 Reply Last reply Reply Quote 0
      • E
        EMWEE
        last edited by

        You posted a screenshot of a firewall rule with 2222.

        1 Reply Last reply Reply Quote 0
        • F
          fmaxwell
          last edited by

          @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."

          ![Screen Shot 2015-05-24 at 3.56.48 AM.png](/public/imported_attachments/1/Screen Shot 2015-05-24 at 3.56.48 AM.png)
          ![Screen Shot 2015-05-24 at 3.56.48 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-05-24 at 3.56.48 AM.png_thumb)

          1 Reply Last reply Reply Quote 0
          • E
            EMWEE
            last edited by

            Post a screen of your WAN rules.

            1 Reply Last reply Reply Quote 0
            • F
              fmaxwell
              last edited by

              @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.}

              1 Reply Last reply Reply Quote 0
              • BBcan177B
                BBcan177 Moderator
                last edited by

                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

                "Experience is something you don't get until just after you need it."

                Website: http://pfBlockerNG.com
                Twitter: @BBcan177  #pfBlockerNG
                Reddit: https://www.reddit.com/r/pfBlockerNG/new/

                1 Reply Last reply Reply Quote 0
                • E
                  EMWEE
                  last edited by

                  Don't open the port at all.

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

                  1 Reply Last reply Reply Quote 0
                  • F
                    fmaxwell
                    last edited by

                    @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.

                    1 Reply Last reply Reply Quote 0
                    • F
                      fmaxwell
                      last edited by

                      @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.

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        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

                        1 Reply Last reply Reply Quote 0
                        • F
                          fmaxwell
                          last edited by

                          @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

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.