Who uses knockd in 2018 to secure OpenVPN?

[Zonkd]

I am curious as to whether anyone still has the knockd port-knocking package working in the latest firmwares for added protection of their OpenVPN servers or similar. It appears as though knockd was last spoken about in 2016. We keep taking about ways to reduce the number of attempts on OpenVPN servers. Perhaps using knockd to keep ports closed until required would compliment the best practices of using ports other than 1194 and 443 and blocking overseas connection attempts altogether with Skynet?

 

[Bamsefar]

Well that is a good question - however that only applies during the time the connection is to be established. When it is connected, the port that is OpenVPN is always open (until disconnecting the client) - so my next questions will be, the logical one: Yes we can make it harder to establish new connection (when none is connected), but how is this improving already connected devices?

Example: Let's say I have my mobile phone connected when I am not at home, like ALL the time. So the only time the port knocking will be helpful is when I am at home - but none what so ever when I am out of my home since the first thing that will happen is that my mobile "will call home and set up a OpenVPN connection that will always be connected" until I get home again.

 

[Martineau]

Yes we can make it harder to establish new connection (when none is connected), but how is this improving already connected devices?

It clearly doesn't?

i.e. not sure if I understand your query, but just to clarify...., is your concern that established/authenticated OpenVPN sessions are somehow inherently vulnerable?

If so, then perhaps the quickest way to add additional security would be to only establish your home VPN tunnel thru an existing VPN tunnel?, with 'knockd' (or similar) 'protecting' the initial tunnel?

 

[Zonkd]

It clearly doesn't?

i.e. not sure if I understand your query, but just to clarify...., is your concern that established/authenticated OpenVPN sessions are somehow inherently vulnerable?

If so, then perhaps the quickest way to add additional security would be to only establish your home VPN tunnel thru an existing VPN tunnel?, with 'knockd' (or similar) 'protecting' the initial tunnel?

I think what @Bamsefar means to say is that the port must remain open while the VPN server is in use, therefore in his particular scenario where his device is permanently connected to the VPN server it would not make sense to configure port knocking. And that is correct. That said, it would make sense and be beneficial for any user who doesn't regularly use their VPN server. It simply allows the VPN server port to remain closed while you aren't connected, and during that time port scanners shouldn't find it, and unwanted connection attempts shouldn't be possible (unless they send the valid port knock sequence to open the port).

 

[sbsnb]

I think what @Bamsefar means to say is that the port must remain open while the VPN server is in use, therefore in his particular scenario where his device is permanently connected to the VPN server it would not make sense to configure port knocking. And that is correct. That said, it would make sense and be beneficial for any user who doesn't regularly use their VPN server. It simply allows the VPN server port to remain closed while you aren't connected, and during that time port scanners shouldn't find it, and unwanted connection attempts shouldn't be possible (unless they send the valid port knock sequence to open the port).

Can't the firewall be configured to drop packets destined to the VPN port that don't originate from an IP that successfully "knocked" on the correct ports? Or maybe default to blocking all connections to VPN port and then successful port knocking triggers an exception for that IP.

 

[Bamsefar]

That would only work if your client has a static IP adress...

 

[Zonkd]

Can't the firewall be configured to drop packets destined to the VPN port that don't originate from an IP that successfully "knocked" on the correct ports? Or maybe default to blocking all connections to VPN port and then successful port knocking triggers an exception for that IP.

I couldn't give you an answer to that. @Adamm might know whether the ASUS firewall could be made to achieve similar functionality. I'm still wondering if anyone has got the knockd package working properly before.

 

[Bamsefar]

Well you could use this code if you like...

iptables -N KNOCKING
iptables -N GATE1
iptables -N GATE2
iptables -N GATE3
iptables -N PASSED

-- Default handling
-iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -j KNOCKING
iptables -A GATE1 -p tcp --dport 3334 -m recent --name AUTH1 --set -j DROP
iptables -A GATE1 -j DROP

iptables -A GATE2 -m recent --name AUTH1 --remove
iptables -A GATE2 -p tcp --dport 4455 -m recent --name AUTH2 --set -j DROP
iptables -A GATE2 -j GATE1

iptables -A GATE3 -m recent --name AUTH2 --remove
iptables -A GATE3 -p tcp --dport 5666 -m recent --name AUTH3 --set -j DROP
iptables -A GATE3 -j GATE1

iptables -A PASSED -m recent --name AUTH3 --remove
iptables -A PASSED -p tcp --dport 1194 -j ACCEPT
iptables -A PASSED -j GATE1

iptables -A KNOCKING -m recent --rcheck --seconds 10 --name AUTH3 -j PASSED
iptables -A KNOCKING -m recent --rcheck --seconds 10 --name AUTH2 -j GATE3
iptables -A KNOCKING -m recent --rcheck --seconds 10 --name AUTH1 -j GATE2
iptables -A KNOCKING -j GATE1

 

[sbsnb]

That would only work if your client has a static IP adress...

Why? I port knock from 10.1.1.2 and that's added to IPTABLES. Ten minutes later I knock from 10.1.1.100 and that's added to IPTABLES while 10.1.1.2 is removed.

 

[Zonkd]

Well you could use this code if you like...

iptables -N KNOCKING
iptables -N GATE1
iptables -N GATE2
iptables -N GATE3
iptables -N PASSED

-- Default handling
-iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -j KNOCKING
iptables -A GATE1 -p tcp --dport 3334 -m recent --name AUTH1 --set -j DROP
iptables -A GATE1 -j DROP

iptables -A GATE2 -m recent --name AUTH1 --remove
iptables -A GATE2 -p tcp --dport 4455 -m recent --name AUTH2 --set -j DROP
iptables -A GATE2 -j GATE1

iptables -A GATE3 -m recent --name AUTH2 --remove
iptables -A GATE3 -p tcp --dport 5666 -m recent --name AUTH3 --set -j DROP
iptables -A GATE3 -j GATE1

iptables -A PASSED -m recent --name AUTH3 --remove
iptables -A PASSED -p tcp --dport 1194 -j ACCEPT
iptables -A PASSED -j GATE1

iptables -A KNOCKING -m recent --rcheck --seconds 10 --name AUTH3 -j PASSED
iptables -A KNOCKING -m recent --rcheck --seconds 10 --name AUTH2 -j GATE3
iptables -A KNOCKING -m recent --rcheck --seconds 10 --name AUTH1 -j GATE2
iptables -A KNOCKING -j GATE1

Have you tested this out?

 

[Zonkd]

Why? I port knock from 10.1.1.2 and that's added to IPTABLES. Ten minutes later I knock from 10.1.1.100 and that's added to IPTABLES while 10.1.1.2 is removed.

I get what you're saying, you suggest a system to whitelist the IP address from which the valid port knock was received. I think that could cause problems for roaming clients that don't keep a static IP. OpenVPN offers a --float option precisely because devices (think mobile) may need to change their port or IP address during an established VPN session. Really it doesn't matter where the valid port knock came from. The OpenVPN server handles authentication.

For your interest, from the OpenVPN Man Page:

--float
Allow remote peer to change its IP address and/or port number,
such as due to DHCP (this is the default if --remote is not
used). --float when specified with --remote allows an OpenVPN
session to initially connect to a peer at a known address, how-
ever if packets arrive from a new address and pass all authenti-
cation tests, the new address will take control of the session.
This is useful when you are connecting to a peer which holds a
dynamic address such as a dial-in user or DHCP client.
Essentially, --float tells OpenVPN to accept authenticated pack-
ets from any address, not only the address which was specified
in the --remote option.

 

[Bamsefar]

Have you tested this out?

I played around with this a yesr or two ago... I do not use this anymore....

 

[Alfsu]

I wonder if Fail2Ban could be implemented through entware, it works real well in debian 9 when configured with a jail for the openvpn server.

 

[RMerlin]

I wonder if Fail2Ban could be implemented through entware, it works real well in debian 9 when configured with a jail for the openvpn server.

fail2ban is a resource pig from an embedded device's point of view as it requires Python.

 

[Alfsu]

fail2ban is a resource pig from an embedded device's point of view as it requires Python.

Noted!

Sent from my ONEPLUS A3000 using Tapatalk