Do you happen to have a write up on the steps you took to achieve this? If not no worries. TIA.
It’s great that you figured it out and seems like you’ve done some interesting stuff there, hats off. My main point is that everything costs time and in cyber the good result is nothing: you must be very choosy to actually achieve anything useful in life. If you didn’t do it, would anyone actually be worse off?
You may have something different going on but I see a few things.
* SSL VPN is different to IPSEC. SSL is much more vulnerable if anything especially in Fortigates.
* With IPSEC if you’re that committed you might actually go as far as to only permit IKE and ESP from only specific IPs of the remote gateways. PIA but possible to do.
* With your case with tons of SSL attempts I’d think a geoblock would be a much simpler and just as if not more efficient solution. I bet those ASNs are in like 3-5 countries (maybe a dozen but still) and if you could block them without an impact then you probably don’t have user in those countries.
More Importantly: what did you actually achieve? I’m not saying you haven’t achieved anything, just challenging the idea.
* cleaning up the logs is nice but the business doesn’t care, it doesn’t help anyone, perhaps except someone in IT. If it did create a substantial percentage of log volume (I’d say 5+%) then yes it may be worth it just for the sakes of reducing the noise. I once wiped about 60% of firewall logs by just tweaking 1 rule, saved a ton of disk space and licensed ingestion.
* Did it make you any more secure? well, probably not if you have other controls right like account lockouts and MFA. In case of RCE in SSL VPN it might give you some peace of mind and might even prevent a real exploit but won’t reduce the urgency as it can’t guarantee anything.
that’s fair enough. a good way to learn. Just remember that if you’re learning at someone’s expense to even if there’s no tangible outcome straight away (as often with knowledge professions) it should add value in some other way one day or the other.
Most security controls and tools don’t do much because they are either misconfigured or inappropriate, and then people always cry how there’s no time to actually do anything after they spent all the time and money on something that makes no difference. Don’t fall into that trap, try to avoid doing things that don’t make an impact.
Threat feed in local-in policy?
If its just making sure to block access to SSLVPN, you can put the listening port on a loopback interface and point a VIP at the interface from your WAN. Add incoming address objects based on HTTP threat feeds and set the policy to deny. There is a lot of documentation about it.
If you also have concerns about IPSec attempts, you can add those port numbers as well.
There are a few approaches to this process, but the basics are pretty well covered online.
Agree. SSL is far more finicky. I spend more time auditing and dialing in my policies. As I do, I find im spending less time on it as I dial things in.
IPSEC is absolutely different. I dont use IPSEC for dial-in users, only specific DDNS or Static hosts (other appliances) - Maintaining a trustedhost list in our local-in policy is easy enough in this case. However, I worry less about IPSEC - being an open standard, its far more hardened.
I do apply a geoblock to our SSLVPN. I have traffic denied to long blocklists of subnets, I then allow any traffic from the US that doesnt already exist in my blocklists to attempt auth. If its not US based and not already blocked, its dropped by default.
Logs dont take up much data and are easy enough to store. I dont rely on my firewall to hold them. I store them in our syslog server. Outside of reviewing logs for additional IP ranges of concern, I also maintain them for HR. In the past we have had employees whom were abusing work-from-home privileges and being able to provide outside access audits for HR while building a case against someone was important.
Any more secure? Possibly. We do use MFA on our portal, account lockouts, rotating passwords and geoblocks. I also receive daily emails with filtered log entries that provide me with a 24-hour access cycle summary. Aside from trusting our configuration as best as can, we are able to have eyes on access and system use without additional hours and audit fatigue. I personally coded the automated reporting and its content so its telling me exactly what I want to know day to day and cutting out all the fluff or background noise that I dont need to know about.
As we’ve learned with ChangeHealthcare, you can have a million dollar budget for a SIEM or other security monitoring system, but if you dont have trained eyes on it every day its worthless.
In 7.2+ you can use feeds in your local-in-policies from what I understood. 7.0.x did not have that feature.
Ou could technically do it via loopback interface and use a normal policy then.