Skip to main content
przemo
przemo
New Member
September 28, 2016
Question

The intruder tries to connect via VPN

  • September 28, 2016
  • 8 replies
  • 24994 views

Hello,

 

I've an active VPN site-to-site tunnel between the headquarters and the branch office. I noticed in the logs, that since one week every day (more or less at the same time) someone makes one attempt to connect to the VPN on FGT at HQ and a moment later to the branch FGT.

Every time from similar IP addresses eg.:

216.218.206.94 216.218.206.66 216.218.206.122 216.218.206.82 216.218.206.118 216.218.206.78 216.218.206.74 216.218.206.114 216.218.206.110 216.218.206.126 216.218.206.86 216.218.206.98 184.105.139.79 184.105.139.71 I would like to ask you, is there any way to block specified IP address or group of addresses (blacklist) to prevent the connection with my devices? (The Control Panel isn't available from the Internet). And the key question: how the intruder knew that I started a VPN site-to-site connection? How found out our HQ and Branch IP address?

log eg:

date=2016-09-28 time=03:10:59 devname=FGT60D-XX-HQ devid=FGT60DXX logid=0101037128 type=event subtype=vpn level=error vd="root" logdesc="Progress IPsec phase 1" msg="progress IPsec phase 1" action=negotiate remip=216.218.206.94 locip=193.XXX.XXX.XXX remport=31902 locport=500 outintf="wan1" cookies="3e35c70729dfedef/0000000000000000" user="N/A" group="N/A" xauthuser="N/A" xauthgroup="N/A" assignip=N/A vpntunnel="N/A" status=failure init=remote mode=main dir=inbound stage=1 role=responder result=ERROR

date=2016-09-28 time=03:40:43 devname=FGT60D-XX-BRANCH devid=FGT60DXX logid=0101037128 type=event subtype=vpn level=error vd="root" logdesc="Progress IPsec phase 1" msg="progress IPsec phase 1" action=negotiate remip=216.218.206.66 locip=157.XXX.XXX.XXX remport=52951 locport=500 outintf="wan1" cookies="3e35c70729dfedef/0000000000000000" user="N/A" group="N/A" xauthuser="N/A" xauthgroup="N/A" assignip=N/A vpntunnel="N/A" status=failure init=remote mode=main dir=inbound stage=1 role=responder result=ERROR

    8 replies

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    September 28, 2016

    I'm seeing these attempts all the time, from the beginning of the year on. Hopefully, all PSKs are hard enough to crack, or I'll have to start using certs.

    BTW, how is using certificates different from using (long, random) PSKs? Both (I guess) are exchanged as hashes, I can make both equally long and random - any insights for a dummy?

     

    What you can do is create local-in policies, blocking access from that subnet altogether (216.218.206.0/24 or /21...). Local-in only affects traffic to the FGT (mgmt, IPsec, SSLVPN, DNS, NTP,..) not traffic aimed at the network behind it. If brute force blocking is too much, an IPS sensor or AppControl would be effective. Alas, UTM is not supported in local-in policies (feature request!).

    kelleycomputing
    kelleycomputing
    Explorer
    October 21, 2016

    I've noticed these same events occurring, and from what I've gathered, the "Shadow Server" organization is responsible for the majority of the alerts that you've mentioned (at least the ones with IP addresses within the 216.218.128.0/17 block). You can find more information about Shadow Server's ISAKMP vulnerability scanning on their blog: http://blog.shadowserver.org/2016/09/20/isakmp-scanning-and-potential-vulnerabilities/. They've also got a page detailing that project, but it appears to be down at this point in time: https://isakmpscan.shadowserver.org.

     

    I've contacted Shadow Server about the issues and they've notified me that end users can opt out of their scanning "service" by having the IP addresses in question whitelisted. This would, however, provide your IP addresses on a public whitelist (which may not be in your best interest).

     

    I've attempted to create firewall rules to block those scan attempts (and stop the alert logging related to those scans), but the rules that I've created don't seem to be working (I still receive notices regarding those scans, as if the VPN IPSec connection is being allowed even though a pretty general policy/rule is being created to try to block those connection attempts).

     

    If anyone has any recommendations of what type of policy can be created to try to block these attempts, I'd love to hear the details. The policy that I've created essentially attempts to prohibit connections from "any" source interface from the source IP block shown above (216.218.128.0/17) to "any" destination interface and "any" address on "All" protocols. I'm not sure how much more generalized I can get with that policy? 

    BarryM
    BarryM
    New Member
    November 15, 2016

    I used these commands to create a policy on the wan port.

    config firewall local-in-policy     edit 1         set intf "port1"         set srcaddr "Blocked VPN"         set dstaddr "Wan IP"         set service "ALL"         set schedule "always"     next end

    "Blocked VPN" is an IP group of the offending addresses. I chose to use my wan facing IP/32 as the destination since the attackers are hitting my IP first. If you have more than one wan IP you will need more than one identical policy.

     

    This is similar to applying Access Group rules to ports in Cisco routers but much simpler.

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    November 15, 2016

    If you have more than one wan IP you will need more than one identical policy.

     

    rather:

    If you have more than one wan IP you will need an address group as destination, and still only one policy.

    Terms & ConditionsAccessibility statement
    Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
    Fortinet Flag the Hack. Wednesday, August 26, 9:00 AM - 5:00 PM ET, COSM, Atlanta, GA.