Sophos Firewall v22 EAP is now available! Click here to learn more.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

"Multiple failed login attempts for WAN-facing portals on Sophos Firewall" - How to get IP

Hello,

We've seen a message on the Sophos Firewall WEB-UI leading us to this article:

"Multiple failed login (brute force) attempts for WAN-facing portals on Sophos Firewall"

https://support.sophos.com/support/s/article/KBA-000009932?language=en_US

We checked and indeed we see those (presumably) brute force attempts. The article now suggests to create an ACL exception rule to block the IPs or origin countries of the attackers. But it also states the following:

"Note: If the VPN portal and SSL VPN service share the same port and SSL VPN is enabled on WAN, the source IP for the failed login (brute force) attempt is shown as 127.0.0.1 in the log viewer."

And that is exactly what's happening to us - the only thing we are seeing is 127.0.0.1.

Now my question is: How can we find out the correct IP and/or origin country of the attackers? The article is not giving any clue about how to do this.

Any help is much appreciated. Thanks!



This thread was automatically locked due to age.
  • Hi,

    Thank you for reaching out to Sophos Community.

    The public IP is the one on the logs and for the location, you may use any public site to look it up.

    For example,https://whatismyipaddress.com and then input the IP address on the lookup 

    Erick Jan

    Global Community Engineer, Support & Services
    Are you a Sophos Partner? | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question, please use the 'Verify Answer' button.

    The award-winning home for Sophos Support videos! - Visit Sophos Techvids

    • Hello,

      thanks for the fast answer. But I think you misunderstood me.

      In the logs I can only see 127.0.0.1 (localhost). So there's nothing I can put in those public lookup sites. As the article points out this is because the VPN portal and SSL VPN service are sharing the same port. So what's the way to see the "correct" IP of the presumable attackers in the logs?

      • Hi Markus,

        Thank you for the correction; it's my bad. Let me check this further.

        Erick Jan

        Global Community Engineer, Support & Services
        Are you a Sophos Partner? | Product Documentation | @SophosSupport | Sign up for SMS Alerts
        If a post solves your question, please use the 'Verify Answer' button.

        The award-winning home for Sophos Support videos! - Visit Sophos Techvids

        • Hi Markus,

          Kindly try to check on the Authentication logs(access_server.log) in CLI by going to the Advance shell.

          tail -f /log/access_server.log

          An example would look like the following and check the Source IP

          2024-09-09 11:18:23Authenticationmessageid="17719" log_type="Event" log_component="VPN Portal Authentication" log_subtype="Authentication" status="Failed" user="proxy" user_group="" client_used="N/A" auth_mechanism="AD,AD,Local" reason="wrong credentials" src_ip="154.X.X.X" message="User proxy failed to login to VPN portal through AD,AD,Local authentication mechanism because of wrong credentials" name="" src_mac=""

          Erick Jan

          Global Community Engineer, Support & Services
          Are you a Sophos Partner? | Product Documentation | @SophosSupport | Sign up for SMS Alerts
          If a post solves your question, please use the 'Verify Answer' button.

          The award-winning home for Sophos Support videos! - Visit Sophos Techvids

          • Hello Erik,

            uhm, unfortunately my access_server.log looks completely different. There's no "Authenticationmessageid" for example and no failed login attempts to VPN portal etc.

            BUT I see a lot of the following messages, for example:

            MESSAGE   Sep 16 10:34:21.911755Z [access_server]: (update_admin_access_table): # Admin user authentication fail from IP 80.94.95.81
            MESSAGE   Sep 16 10:34:21.948862Z [access_server]: (update_admin_access_table): ## Admin user authentication failed from IP 80.94.95.81
            MESSAGE   Sep 16 10:34:21.985372Z [access_server]: (update_admin_access_table): ## Admin user authentication failed from IP 80.94.95.81
            MESSAGE   Sep 16 10:34:22.022104Z [access_server]: (update_admin_access_table): attempt_allowed: '4', attempts_duration: '90', block_for_minutes: '60'
            MESSAGE   Sep 16 10:34:22.022130Z [access_server]: (update_admin_access_table): Bruteforce Attack from IP 80.94.95.81 detected, counter 4

            Those messages scare me. This looks like an attempt to authenticate to the webadmin portal to me. But this isn't open to WAN.

            Any clue what those messages mean?

            And those messages are much younger than the "failed authentication" messages we see in the log viewer. Those are from sunday.

            When they happened I can only see those messages in the access_server.log:

            ERROR     Sep 15 21:12:21.405974Z [access_server]: check_auth_result: VPN/SSLVPN/MYACC Authentication Failed
            ERROR     Sep 15 21:12:25.146711Z [ADS_AUTH]: adsauth_bind: ldap_result failed: Invalid credentials
            ERROR     Sep 15 21:12:25.146738Z [ADS_AUTH]: adsauth_authenticate_user: '<internal IP>:636': bind failed for User: '<user account>'
            ERROR     Sep 15 21:12:25.146743Z [ADS_AUTH]: adsauth_authenticate_user: ADS Authentication Failed for User:'<user account>'
            ERROR     Sep 15 21:12:25.146841Z [ADS_AUTH]: adsauth_parse_error_msg: ad error no: 1326
            ERROR     Sep 15 21:12:25.172552Z [ADS_AUTH]: adsauth_bind: ldap_result failed: Invalid credentials
            ERROR     Sep 15 21:12:25.172574Z [ADS_AUTH]: adsauth_authenticate_user: '<internal  IP>:636': bind failed for User: '<user account>'
            ERROR     Sep 15 21:12:25.172579Z [ADS_AUTH]: adsauth_authenticate_user: ADS Authentication Failed for User:'<user account>'
            ERROR     Sep 15 21:12:25.172680Z [ADS_AUTH]: adsauth_parse_error_msg: ad error no: 1326
            ERROR     Sep 15 21:12:25.223516Z [ADS_AUTH]: adsauth_bind: ldap_result failed: Invalid credentials
            ERROR     Sep 15 21:12:25.223532Z [ADS_AUTH]: adsauth_authenticate_user: '<internal  IP>:636': bind failed for User: '<user account>'
            ERROR     Sep 15 21:12:25.223536Z [ADS_AUTH]: adsauth_authenticate_user: ADS Authentication Failed for User:'<user account>'
            ERROR     Sep 15 21:12:25.223646Z [ADS_AUTH]: adsauth_parse_error_msg: ad error no: 1326
            ERROR     Sep 15 21:12:25.229595Z [RADIUS_AUTH]: (cb_authenticate_user): Authentication failed for User: '<user account>'
            ERROR     Sep 15 21:12:25.230271Z [LDAP_AUTH]: ldapauth_search_user: <internal  IP>:636: search failed.. filter: '(userPrincipalName=<user account>)': Err: Operations error
            ERROR     Sep 15 21:12:25.230282Z [LDAP_AUTH]: ldapauth_authentgicate_user: '<internal  IP>:636': coudn't find USER DN using filter: (userPrincipalName=<user account>)
            ERROR     Sep 15 21:12:25.230490Z [access_server]: check_auth_result: VPN/SSLVPN/MYACC Authentication Failed

            No IP or origin country...

            Any help on the meaning of this is very much appreciated!

            Thanks!

            • Hi  ,

              "[access_server]: (update_admin_access_table)" - It is common log line in authentication fail and not specific to Webadmin Portal. (Applicable for all client including VPN Portal)

              Avoid port sharing between VPN Portal & SSLVPN if possible. It will help you identify actual IPs.

              • Hello ,

                ah ok, thanks. That's good to hear – about the "[access_server]: (update_admin_access_table)" I mean.

                The other thing about VPN Portal & SSL VPN: That's now to late, isn't it? We set up both the portal and SSL VPN to 443. Is this a bad practice? If so, what should we change? The Portal or SSL VPN? I'm afraid neither would be easy to adapt to for all of our users. In the SSL VPN case everybody would need to re-download the SSL configuration, am I correct?

                Anyway, isn't there still a way to see the initial IPs who tried to connect to the VPN Portal? The firewall should have logged those connections somewhere, shouldn't it?

                Thanks again!

                • Hi  ,

                  There is a way to detect IPs but it contains all VPN Portal login IPs (genuine + fail attempts)

                  Ex.: grep -rn "Non-OpenVPN client protocol detected" /log/sslvpn.log

                  • Thank you for the fast feedback!

                    OK, I see hundreds of IPs there. Without knowing which ones are the bad ones it seems I'm out of luck... Am I?

                    At least I've already blocked the IPs from the article I mentioned at the start of the thread.

                    So the only thing for the future would be to change either the VPN Portal port or the SSL VPN port, am I right? Which one?

                    • My preference is default settings

                      • Which are..?

                        According to this site (https://docs.sophos.com/nsg/sophos-firewall/20.0/help/en-us/webhelp/onlinehelp/AdministratorHelp/Administration/DeviceAccess/DeviceAccessBestPractices/index.html#ssl-vpn-port) it should be having the VPN Portal on port 443 and SSL VPN on port 8443. Correct?

                        That would mean we have to change the SSL VPN settings and every user has to re-download the SSL VPN configuration file again. Any experience with this? Should that work without any hiccups?

                        But thanks for all the advices/information.

                        So, to conclude: there's NO WAY to get the exact IPs and origin countries when SSL VPN and the VPN Portal share the same port?

                        • Hello everyone,

                          sorry for writing back so lately.

                          I just want to inform everybody who reads this threat that we did in fact change the SSL VPN port (back?) to the standard port of 8443. That worked without any hiccups. Every user had to re-download the SSL VPN configuration file, but this went smoother than anticipated.

                          Now we are able to see the IPs of every failed login attempt on SSL VPN or the VPN portal.

                          Tanks again!

                      • SFOS V21.0 will also tackle this kind of challenge by bringing the 3th party feeds. 

                        __________________________________________________________________________________________________________________