Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Replies 14 replies
  • Answers 4 answers
  • Subscribers 40 subscribers
  • Views 3796 views
  • Users 0 members are here
Options
Suggested

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

Markus Quirmbach

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!



Edited TAGs
[edited by: Erick Jan at 2:37 PM (GMT -7) on 17 Sep 2024]
  • 0

    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
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • 0 in reply to Erick Jan

    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?

  • 0 in reply to Markus Quirmbach

    Hi Markus,

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

    Erick Jan
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • 0

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

    __________________________________________________________________________________________________________________

  • 0 in reply to Markus Quirmbach

    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
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • 0 in reply to LuCar Toni

    Ah yes, I already took a look at version 21. Seems to be a good update when it comes out.  Slight smile

  • 0 in reply to Erick Jan

    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!

  • 0 in reply to Markus Quirmbach

    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.

  • 0 in reply to Bhavik24

    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!

  • 0 in reply to Markus Quirmbach

    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

Unfiltered HTML