The intruder tries to connect via VPN

[przemo]

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

[ede_pfau]

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]

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]

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]

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.

[BarryM]

I should have clarified. If you using more than one port and wan IP for load balancing, use another identical policy on the second (or more) port(s).

[tanr]

Is the only VPN connection between your HQ and  the branch office, or do you allow dialup-clients to connect?

If you only have the VPN between two static IPs perhaps you could set up a local-in-policy on each FortiGate for each wan port, to allow UDP/500 and UDP/4500 only from those IPs, with a later local-in-policy for each wan port to deny UDP/500 and UDP/4500 for all IPs.

I'm seeing the same VPN attempts myself and am considering implementing this sort of local-in-policy since I don't need to support dialup-clients.

[rohitchoudhary1978]

Message meets Alert condition date=2018-11-06 time=09:05:46 devname=FW_2 devid=FG600CXXXXX logid="0101037128" type="event" subtype="vpn" level="error" vd="root" eventtime=1541475345 logdesc="Progress IPsec phase 1" msg="progress IPsec phase 1" action="negotiate" remip=216.218.206.106 locip=x.x.x.x remport=5861 locport=500 outintf="port4" 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" Message meets Alert condition date=2018-11-06 time=09:01:39 devname=FW_2 devid=FG600CXXXXX logid="0101037128" type="event" subtype="vpn" level="error" vd="root" eventtime=1541475099 logdesc="Progress IPsec phase 1" msg="progress IPsec phase 1" action="negotiate" remip=216.218.206.126 locip=x.x.x.x remport=44018 locport=500 outintf="port4" 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" I think i should apply the same formula from local in policy

[emnoc]

You can't block everything in the  big internet, I would secure the  site2site and  use a strong PSK. This  attach was found probably by a udp.port scanner if I had to  guess and is harmless