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

    pfSense: Attack from internal IP on service SSH with danger 10.

    Scheduled Pinned Locked Moved General pfSense Questions
    9 Posts 5 Posters 1.7k 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.
    • M
      mauro.tridici
      last edited by

      Dear Users,

      recently I activated a SIEM to collect (at least) the logs produced by pfSense v.2.6.
      pfSense instance is named pfSense_LAN_SRV and, on top of it , I created some VLANs.
      One of these VLANs is identified by the following subnet 192.168.100.0/40.
      In particular, the IP address 192.168.100.40 is a device belonging to the technological systems of the data center.

      Taking a look at the SIEM dashboard, I noticed that the IP address 192.168.100.40 is trying to ssh to the pfsense:

      auth.log:May 11 00:14:19 pfSense_LAN_SRV sshd[10807]: Failed password for root from 192.168.100.40 port 2276 ssh2
      auth.log:May 11 00:14:19 pfSense_LAN_SRV sshguard[1039]: Attack from "192.168.100.40" on service SSH with danger 10.
      auth.log:May 11 00:14:19 pfSense_LAN_SRV sshd[10807]: Failed password for root from 192.168.100.40 port 2276 ssh2
      auth.log:May 11 00:14:19 pfSense_LAN_SRV sshguard[1039]: Attack from "192.168.100.40" on service SSH with danger 10.
      auth.log:May 11 00:14:19 pfSense_LAN_SRV sshd[10807]: Failed password for root from 192.168.100.40 port 2276 ssh2
      auth.log:May 11 00:14:19 pfSense_LAN_SRV sshguard[1039]: Attack from "192.168.100.40" on service SSH with danger 10.
      auth.log:May 11 00:14:19 pfSense_LAN_SRV sshguard[1039]: Blocking "192.168.100.40/32" for 120 secs (3 attacks in 0 secs, after 1 abuses over 0 secs.)
      auth.log:May 11 00:14:19 pfSense_LAN_SRV sshd[10807]: Fssh_packet_write_wait: Connection from authenticating user root 192.168.100.40 port 2276: Permission denied [preauth]
      auth.log:May 11 00:16:39 pfSense_LAN_SRV sshguard[1039]: 192.168.100.40: unblocking after 140 secs

      In your opinion, is it a false positive? or it is a real problem.
      Since pfsense_LAN_SRV is the gateway for the network 192.168.100.0/24, could you please help me to identify the firewall rule I need to add in order to block this attack attempt without disrupting the route outward?

      Many thanks in advance,
      Mauro

      S johnpozJ stephenw10S GertjanG 4 Replies Last reply Reply Quote 0
      • S
        SteveITS Galactic Empire @mauro.tridici
        last edited by

        @mauro-tridici Is this device running a probe or network scan? Is it infected?

        To block create a rule on that VLAN from 192.168.100.40 to This Firewall, port 22/TCP.

        Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
        Upvote ๐Ÿ‘ helpful posts!

        1 Reply Last reply Reply Quote 1
        • johnpozJ
          johnpoz LAYER 8 Global Moderator @mauro.tridici
          last edited by

          @mauro-tridici I am with @SteveITS this is most likely some prob your running on this 100.40 box.. Did you recently change the ssh password on pfsense?

          What is this 100.40 box there are many tools that you might be running that might want to login to ssh to check stuff, that either you now have a mismatch in your password or never setup on your probing box.

          An intelligent man is sometimes forced to be drunk to spend time with his fools
          If you get confused: Listen to the Music Play
          Please don't Chat/PM me for help, unless mod related
          SG-4860 24.11 | Lab VMs 2.8, 24.11

          1 Reply Last reply Reply Quote 1
          • M
            mauro.tridici
            last edited by

            Hi @SteveITS @johnpoz ,

            thank you for your fast reply.
            I don't know if the device is infected or not, I'm still investigating.

            Using nmap against this particular IP, I see that port 80 is open.
            Opening 192.168.10040:80 on a browser I can read the following lines:

            "Onboard touch for chiller remote monitoring"
            "Onboard Touch is a web-based solution that makes it possible to monitor the chiller operation and to diagnose any problems as soon as they arise. The user interface can be displayed on the browser, no software is therefore required and it can be run on both PC and mobile devices such as tablets and smartphones.

            Onboard Touch works via a three-nodes connection: the chiller, the monitoring server, the Web portal.

            The hardware of Onboard Touch consists of a GSM/UMTS gateway installed on the chiller: in case of plants with multiple chillers, only one gateway is installed, with a three-wire communication connection linking it to the other chillers. Whenever there are mobile connection problems, one can use an Ethernet cable connection to the customers LAN."

            I'm going to block it using the rule you suggested.
            I'm not able to understand if it is a false positive or not.

            What's your recommendation in this case?
            Thanks for the help,
            Mauro

            S 1 Reply Last reply Reply Quote 0
            • S
              SteveITS Galactic Empire @mauro.tridici
              last edited by

              @mauro-tridici I would find out what device that is, and ask why it's trying to connect to things on the network. Sounds like https://www.geoclima.com/on-board-touch/.

              Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
              When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
              Upvote ๐Ÿ‘ helpful posts!

              M 1 Reply Last reply Reply Quote 1
              • M
                mauro.tridici @SteveITS
                last edited by

                @steveits thank you.

                I'm going to contact the people who install it.
                Last question: do you think that I can add the same rule (the one that you suggested) to all the VLAN defined in pfSense (excluding the management lan interface)?

                Lets' say, something like that...
                Example:
                on OFFICE_VLAN interface: block OFFICE_VLAN net * -> This Firewall 22/TCP and 80/443/TCP (for the GUI)

                Thank you in advance,
                Mauro

                johnpozJ 1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator @mauro.tridici
                  last edited by

                  @mauro-tridici said in pfSense: Attack from internal IP on service SSH with danger 10.:

                  In your opinion, is it a false positive?

                  No it's not false, it's a real SSH connection attempt.

                  But, yes, why is that device able to try to connect? If that's not part of your infrastructure it probably shouldn't have access to ssh on the firewall.

                  Steve

                  1 Reply Last reply Reply Quote 1
                  • johnpozJ
                    johnpoz LAYER 8 Global Moderator @mauro.tridici
                    last edited by

                    @mauro-tridici said in pfSense: Attack from internal IP on service SSH with danger 10.:

                    I'm going to contact the people who install it.

                    So this 100.40 box is something some other company/service installed - what is it suppose to be doing? Is it suppose to be scanning your network for stuff - like a qualys scanning appliance or something?

                    You might just need to configure it so it can talk to your ssh on your firewall - if that is something your wanting to do with the box, etc.

                    But yeah normally its a good idea to block all access to the firewall admin features, ssh/web gui etc. from devices on your network that are not meant to admin the firewall.

                    If this network is your default lan interface, it comes out of the box with an anti-lock out rule.. Which so that would have to be disabled if you want to limit what IPs can talk to pfsense admin ports on that network.

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 24.11 | Lab VMs 2.8, 24.11

                    1 Reply Last reply Reply Quote 1
                    • GertjanG
                      Gertjan @mauro.tridici
                      last edited by Gertjan

                      @mauro-tridici

                      Most easy known solution : only accept really trusted devices on your pfSense LAN.
                      From this LAN network, you could connect your own device - that you should trust - and access pfSense. You can even lock down to access to just one LAN IP : the one your device will get when it is connected.

                      All other users : use another LAN called OPT2. From this OPT2, devices they can do what they want, but they should only be able to contact pfSense over port 53, UDP and TCP. Block the rest with destination .LAN2 IP pfSense.

                      No "help me" PM's please. Use the forum, the community will thank you.
                      Edit : and where are the logs ??

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