Dictionary Attack On VPN

[MikeMarks]

We have been having unknown person(s) been attacking our firewall for the past few weeks with a Dictionary Attack. They even went the length of finding one of out IT staff on Linkedin and try to get his Globalprotect Login.  

Luckily they have not been able to gain access, but I want to create a rule that will autoblocks any attempts that do not use the correct login format by IP address or User name.

So far when manually input the IP's in a block rule we have after they have tried.

Any thoughts or suggestions are appreciated

[reaper]

how about switching to SAML authentication? 

that by itself should be a good deterrent as the attacker will know they'll need to tackle MFA as well and can no longer just dictionary their way through your login

you could also add client certificate authentication as an extra security measure and deterrent

are they attacking the portal or globalprotect agent?

[PC-TomS]

They are attacking our portal and we use SAML.  I would still like to configure some type of protection without impacting our users.

I set up a policy with the Palo Alto Networks GlobalProtect Authentication Brute Force Attempt and it blocked some attempts until they figured out that increasing the interval between attempts would not trigger the rule.

We are implementing client certs, but I just want to drop the constant attempts from specific IPs without having to add them manually to a block list.

I'm guessing there are other ways to do this too.

[BPry]

@PC-TomS,

If you have the ability to feed the IPs in as an EDL this is easy enough with a custom report and the API. Something like this for the custom report:

      <entry name="Failed_GP_Login">
        <type>
          <globalprotect>
            <sortby>repeatcnt</sortby>
            <aggregate-by>
              <member>public_ip</member>
              <member>srcuser</member>
            </aggregate-by>
            <values>
              <member>repeatcnt</member>
            </values>
          </globalprotect>
        </type>
        <period>last-15-minutes</period>
        <topn>5000</topn>
        <topm>50</topm>
        <caption>Failed_GP_Login</caption>
        <query>( error eq 'Authentication failed: Invalid username or password' )</query>
      </entry>

Then you can run the job via the API:

api?type=report&async=yes&reporttype=custom&reportname=Failed_GP_Login
# Runs the report and returns the job ID. If you convert the reponse to a dictionary the job would be at ['response']['result']['job']. Allow enough time for the job to run (60 seconds should be sufficient, varies by environment and platform).#


api?type=op&cmd=<show><report><id>' + str(job_id) + '</id></report></show>'
# Collect the report so that you can actually analyze it. Again you'll want to convert the response to a dictionary. I've included a better Python example here #

report_dict = xmltodict.parse(request_report.content) # Convert the response #
OrdDict = report_dict['response']['result']['report']['entry'] 
root = OrdDict
for element in root:
    recorded_session = [(element['public_ip']),(element['srcuser']),(element['repeatcnt'])]
    public_ip = recorded_session[0]
    src_user = recorded_session[1]
    repeat_count = recorded_session[2]

This is just a starting point, but what I've chosen to care about in particular is the three fields listed. I utilize a REDIS database to increment the failed login count for both the IP and the user. What this allows is to set a threshold for the number of failed logins we determine is acceptable before we block them; you could alternatively simply utilize a similar account to block any source which failed to login to GlobalProtect if you don't want to provide any sort of leeway.

Then you can just have the script update your EDL to block any of the sources that you don't care to have accessing resources and send any alerting that you would care to send to indicate that the address/user has been blocked.