Hi all,
After searching the forum, there is not a lot of using fail2ban with OPNsense. I wanted to create a centralized fail2ban server: meaning, if a person/IP is banned on one service, it should be banned for all of them and in the first line of defence, not only deep inside my network.
So I did some digging and found the following fail2ban action on Github:
https://github.com/fail2ban/fail2ban/pull/2761/files
Which lead me to something like this:
(https://i.postimg.cc/fLXcfZD4/fail2ban-strategy.png) (https://i.postimg.cc/fLXcfZD4/fail2ban-strategy.png)
It works like this:
- HAproxy forwarding requests to the services in the DMZ
- all services log failed attempts to the log-dataset
- one centralized fail2ban instance (in the NAS-network, which is quite tightly locked-down) has access to all logs and takes action for wrong passwords
- if an IP is banned, it updates the alias on OPNsense via API correspondingly, instantly dropping further requests from this IP
It seems to have been working out quite nicely, but since I am rather new to OPNsense, some questions came up:
- Is it a good idea security wise, or does it rather weaken my network:
- I am a bit anxious of using the API, and storing such powerful keys outside the firewall. Is there a way of storing them encrypted yet still usable in the f2b action? Can I limit the access of this key? It only needs to be able to update an alias, it would be nice if I could prohibit it from doing more.
- Is the route e.g Nextcloud > Logs > f2b server > Firewall a possible attack vector? Assuming Nextcloud is highjacked, could some command injection in the logs screw with fail2ban and get access to its VM and therefore API key?
- Is the curl command secure for transmitting the API-key? It calls the https adress of my firewall, so I would guess yes, but I am not sure if this is sufficient? Additional VPN tunnel, or is this an overkill?
- I like a lot the instantaneous action in case of wrong passwords attempts: if any service is hit with the maximum number of wrong passwords, the alias is instantly updated (in contrast to regularly retrieving a file), preventing the attacker from trying other services. BUT: it does not kill the current state. Assuming I am hacking my Nextcloud, as the state is established, even after f2b updated the alias, I can still keep trying passwords and even get access when finally entering the correct one. Is there a way of killing the state by API? Or some workaround?
The ssh dummy-server is not working yet. I would like to see anybody instantly blocked who tries to reach my 22 (nobody with good intentions does). I tried creating a dummy server with IPFW, logging all ssh attempts and feeding this log to f2b. But, seems like all firewall logging (apparently also pf and iptable) in iocage jails actually write to the host systems logs, which are too cluttered for f2b.
It would work, if I actually run an accessible SSH server on my dummy, but I would rather like to stay invisible for any SSH attempts. Any alternatives of preferably clean logging of incoming connections on certain ports?
I listed 22 and 23 for the "honeypot". Any other ports, that are usually a sign of bad intentions? RDP port maybe?
And this connection is not yet established, I thought a simple port-forward to the dummy should do, or is there a better way?
Thanks for reading, looking forward to hear any feedback about this concept.
Cheers