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

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 

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.

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

• Log files for modules
• SSH to the firewall using PuTTY

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=""

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

• Log files for modules
• SSH to the firewall using PuTTY

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=""

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 Markus Quirmbach ,

"[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 Bhavik24 ,

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 Markus Quirmbach ,

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!