I had two ac88u's hacked recently with last 384.5 firmware

[PolarBear]

Someone at 185.200.118.xxx has recently started sending (from May 31) login attempts to my AC86U OpenVPN server. Only a few attempts per day which is interesting.

Exactly this. Started on 20 April 2018. About once or twice per day.

Seems to be registered to no-mans-land dot m247 dot com. Quite a few references on the Internet to this domain in a similar context.

Apr 20 23:44:42 openvpn[16132]: 185.200.118.57 TLS: Initial packet from [AF_INET6]::ffff:185.200.118.57:40541, sid=12121212 12121212
Apr 20 23:45:43 openvpn[16132]: 185.200.118.57 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Apr 20 23:45:43 openvpn[16132]: 185.200.118.57 TLS Error: TLS handshake failed
Apr 20 23:45:43 openvpn[16132]: 185.200.118.57 SIGUSR1[soft,tls-error] received, client-instance restarting

 

[maxbraketorque]

...

Also note the limitation mentioned by Martineau - this will protect you if you have forwarded ports, but not if the target is the router's built-in OpenVPN service.

ok, so network services filter doesn't work for built-in router OVPN server.

 

[ColinTaylor]

@maxbraketorque @PolarBear The issue with 185.200.118.57 is not connected with the original subject of this thread.

The 185.200.118.57 issue has already been discussed here.

 

[Lancairone]

No. You want to block the source IP, not the destination.

Also note the limitation mentioned by Martineau - this will protect you if you have forwarded ports, but not if the target is the router's built-in OpenVPN service.

I'm trying to restrict my outgoing and incoming network stream on the WAN side of the router to always go thru my OpenVPN server IP address on Port 443 (TCP) and not allow communications from the router WAN on any other ports nor with UDP protocol if possible. I would also like to block modem access from my LAN as well. For a few devices (e.g. TVs), I would like run these particular devices without the constraints above. In attempt to achieve these objectives I'm doing the following:

1) On the VPN/VPN Server/Traffic Redirect with Strict Policy Rules, I'm using the following VPN Traffic Routing Rules:

Rules for routing client traffic through the tunnel (Max Limit : 100)
Description Source IP Destination IP Iface
Default VPN out 192.168.xxx.0/24 0.0.0.0 VPN
Default VPN in 0.0.0.0 192.168.xxx.0/24 VPN
TV out <TV IP address> 0.0.0.0 WAN
TV in 0.0.0.0 <TV IP address> WAN

2) On the Firewall/Network Services Filter I'm using a whitelist (rather than blacklist) with the following Firewall Routing Table Rules:

Source IP Port Range Dest IP Port Range Protocol
192.168.xxx.0/24 443 <VPN IP> 443 TCP
<VPN IP> 443 192.168.xxx.0/24 443 TCP

With this implementation, I can still ping my modem address 192.168.100.1 from my LAN. What am I doing wrong, do I not properly understand the whitelist, or is there a better way to achieve my objectives?

Also, I've read opinions about leaving OpenVPN running continuously on the ASUS router that suggest this configuration may not be so secure. I would be interested in hearing thoughts on an additional ethernet restricted (no wi-fi) OpenVPN router behind the ASUS router in terms of whether this will provide any additional security for keeping a continuous OpenVPN connection(s) running between my Home Router and the OpenVPN server particularly for more sensitive data streams?

Thanks in advance for the transparent open source firmware solution and the community of support for helping solve this type of issue. I'm a believer!

Lancairone

 

[The H-Man Cometh]

No. You want to block the source IP, not the destination.

Also note the limitation mentioned by Martineau - this will protect you if you have forwarded ports, but not if the target is the router's built-in OpenVPN service.

Sorry, but can someone provide a specific example of the correct settings required to block the subnets (in this example) on the Firewall -> Network Services Filter tab? For example, would it be:

Source IP = 185.0.0.0/8 (or /24 ???)
Port Range (the first Port Range column) = 1:65535
Destination IP = <Leave_Empty>
Port Range (the second Port Range column) = <Leave_Empty>
Protocol = TCP (and another entry for UDP)

Would that work to block any inbound traffic from IP addresses beginning with 185? Or if not correct, can someone please provide a correct example in its entirety? Many thanks.

 

[ColinTaylor]

Would that work to block any inbound traffic from IP addresses beginning with 185?

Network Services Filter will not do this. NSF blocks traffic forwarded from the LAN to the WAN, not in the other direction.

However as noted previously, if you're trying to stop the messages thrown out by OpenVPN then NSF is completely the wrong tool because the traffic is terminating at the router not the LAN. What specifically are you trying to achieve?

 

[The H-Man Cometh]

Network Services Filter will not do this. NSF blocks traffic forwarded from the LAN to the WAN, not in the other direction.

However as noted previously, if you're trying to stop the messages thrown out by OpenVPN then NSF is completely the wrong tool because the traffic is terminating at the router not the LAN. What specifically are you trying to achieve?

AiProtection is picking up a lot of IPS/IDS hits with Source IP = 68.183.158.79 and Destination IP = <Router_WAN_IP>. I thought there might be an easy way via the GUI to just block/reject anything and everything from that IP address, or from 68.*.*.* in general (or from any other collection of IPs). In Post #22 I thought that's what RMerlin was describing, but maybe I am mis-understanding the feature. The description on the NSF tab does read more like what you are saying... just thought in reading through this thread there might be an easy way to block all traffic from specific WAN IPs. Thanks.

 

[L&LD]

AiProtection is picking up a lot of IPS/IDS hits with Source IP = 68.183.158.79 and Destination IP = <Router_WAN_IP>. I thought there might be an easy way via the GUI to just block/reject anything and everything from that IP address, or from 68.*.*.* in general (or from any other collection of IPs). In Post #22 I thought that's what RMerlin was describing, but maybe I am mis-understanding the feature. The description on the NSF tab does read more like what you are saying... just thought in reading through this thread there might be an easy way to block all traffic from specific WAN IPs. Thanks.

Have you had a look at what Adamm's Skynet script can (easily) do for you?

https://www.snbforums.com/threads/release-skynet-router-firewall-security-enhancements.16798/

 

[ColinTaylor]

AiProtection is picking up a lot of IPS/IDS hits with Source IP = 68.183.158.79 and Destination IP = <Router_WAN_IP>.

The default firewall rules will drop all this traffic anyway, so the messages are largely irrelevant. As has been noted before by RMerlin and others, those messages tend to just scare and confuse people for no good reason.

 

[The H-Man Cometh]

Have you had a look at what Adamm's Skynet script can (easily) do for you?

https://www.snbforums.com/threads/release-skynet-router-firewall-security-enhancements.16798/

Thanks, I have not yet. I'm sure it's easy and effective, but was just really hoping to stick with a generic install, relying only on what the GUI provides by default.

 

[The H-Man Cometh]

The default firewall rules will drop all this traffic anyway, so the messages are largely irrelevant. As has been noted before by RMerlin and others, those messages tend to just scare and confuse people for no good reason.

Understood, and agree that most messages are not worth further action. But when a particular IP such as the one I mentioned keeps banging away at the router, over and over again, for multiple consecutive days, I thought it might be helpful to just add a rule in NSF to block it completely, but maybe that's not possible. Still confused then as to what RMerlin was referring to in Post #22. The way I read that post is that he was using NSF to block specific IPs/subnets?

 

[ColinTaylor]

Still confused then as to what RMerlin was referring to in Post #22. The way I read that post is that he was using NSF to block specific IPs/subnets?

Yes it is confusing the way he has written it. I had to re-read it a few times and even checked the iptables rules being generated. Merlin's post is correct but the whole post must be read as one. You can't just read the first sentence in isolation because it's misleading.

The key phrase is "this will protect you if you have forwarded ports". This is almost certainly not going to be the case, so the second statement is more relevant, "but not if the target is the router's built-in OpenVPN service" (or any other service terminating at the router). So Merlin references Martineau's post #35 which is correct - if you want to drop unsolicited traffic it needs to be done on the INPUT chain. NSF does not do this.

 

[Zonkd]

Thanks, I have not yet. I'm sure it's easy and effective, but was just really hoping to stick with a generic install, relying only on what the GUI provides by default.

Man I did the same for years until I got a spare router to experiment with. I wasn't in my comfort zone installing scripts on my main router for risk of taking it offline. After a year of use I've developed full confidence and think Skynet adds tremendous value to owning an ASUS router.

 

[L&LD]

Thanks, I have not yet. I'm sure it's easy and effective, but was just really hoping to stick with a generic install, relying only on what the GUI provides by default.

You owe it to yourself to try out the available scripts, starting with amtm by thelonelycoder to get you started in the gentlest way possible.

With the ever-increasing complexity that the online world brings us, using scripts such as this is as 'generic' as it gets in 2019.