Blocking repetitive OpenVPN attacks - INPUTFW and REDINPUT after OVPNINPUT

Security Firewall Rules
1

Hello,
I see in FW config (cgi-bin/iptables.cgi) that INPUTFW are REDINPUT are after OVPNINPUT: therefore any block rule created for RED or Firewall input (using cgi-bin/firewall.cgi) does not apply to OpenVPN service.

How do you block through WebUI (cgi-bin/firewall.cgi) IP addresses to connect to your OpenVPN?

For the record, I have a FW Group called Bad Guys that is blocked in all chains: “Firewall Rules” - both in and out, " Incoming Firewall Access" - incoming, " Outgoing Firewall Access" - outgoing.
Basically I used all options cgi-bin/firewall.cgi offers, but that does not protect OpenVPN.

I am aware that I can use firewall.local, but this is burden - anything I put in cgi-bin/firewall.cgi, I also have to copy in firewall.local.

In my oppinion, OVPNINPUT should be protected by REDINPUT or INPUTFW…

Thoughts?

2

My apologies if I misunderstand your question. I mostly don’t know what I am talking about.

A drop or reject rule for all protocols, with input “Bad guys” and destination OpenVPN network would not work?

3

I did a test: I added a rule as you suggested: I do not see it landing in OVPNBLOCK (this chain is in front of OVPNINPUT, OVPNINPUT contains the rules for allowing OPenVPN traffic). The rules land in chains that are after OVPNINPUT - so using GUI I can’t block any access to OpenVPN. (apart from location block and HOSTILE that are in front of OVPNINPUT)

And, for clarity, the existing rules are constructed using “any” in each of the FW entry, therefore my expectation was that “any” also protects OpenVPN service. My surprise when I found it did not protected OpenVPN was big.

image
image1175×193 13.8 KB

image
image1268×172 11.8 KB

image
image1164×226 16.8 KB

4

Until GUI will allow us to use OVPNBLOCK chain, here is an not so elegant solution to replicate INPUTFW inside OVPNBLOCK…

iptables -t filter -A OVPNBLOCK -s `iptables -L INPUTFW | grep -e ^DROP | awk '{ print $4"," }' | sed '/[a-zA-Z]/d'|tr -d '\n' |sed 's/.$//'` -j DROP
iptables -t filter -A OVPNBLOCK -s `iptables -L INPUTFW | grep -e ^LOG | awk '{ print $4"," }' | sed '/[a-zA-Z]/d'|tr -d '\n' |sed 's/.$//'` -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "OVPNBLOCK"
5

Maybe you should engage the developers in the bug report system. Unless we are missing something this looks a bug to me.

6

Bug 12876 has been successfully created

2 Likes
7

I believe that the OVPINPUT chain is dealt with earlier to make sure that any rules put into the FW WUI will not accidentally block the OpenVPN Operation. If OVPINPUT came before the Firewall WUI then any rule added there could block or interfere with the OpenVPN traffic.

The OpenVPN access is well protected with the choice of encryption protocol and the addition of TLS Channel protection. If additional rules are wanted/required for the OpenVPN interface then that is what firewall.local is intended for.

8

Fair enough, however the user interface in the wui should be changed, e.g. removing the openvpn network from the input field and also this situation should be documented in the wiki…

9

Ah, I had forgotten that the openvpn was available in the firewall wui. That means some things can still be controlled or blocked in the firewall wui.

My iptables knowledge is not good enough to understand what is being done in ovpninput versus the firewall wui.

Will need to wait for input from more knowledgeable people.

1 Like
10

Not quite.
The chains used by that page are behind OVPNINPUT, so no, we can’t control through that interface any OpenVPN access

11

After running for a few days with these lines in firewall.local and checking that OVPNBLOCK gets populated with all DROP rules, I see in OpenVPN logs that offender still reach OpenVPN service.

In other words OVPNBLOCK chain did not stopped it - I checked the chain, it contains a Drop action for IP range of offender.

:pensive: