AC3100 / 380.70 Block incoming IP

[maxbraketorque]

@Martineau, Thanks for all the comments and suggestions. I am using certificate+password and sending data via UDP, so I it sounds like I'm reasonably safe. I've got some other things that are going to keep me busy for a while, but I'll eventually implement the --client-connect script setup at add an extra layer of protection.

 

[Martineau]

Agree with everything you said, to implement more fine grained ACL the up/down script hooks is the best place to do it.

With VPNFilter and their recent botch of the Asus Router App opening WAN, 2FA should be top on their list. If not, I don’t know what they’re thinking

I've installed Google Authenticator 2FA onto my RT-AC68U, and it generates the QR code/secret key to be scanned/imported to the Google Authenticator App on my Andoid phone, which is now apparently generating TOTPs for 'RT-AC68U'

I have configured VPN Server 2 to use the Google Authenticator PAM, but despite the module being present on the Entware drive, my test VPN client fails to authenticate..

admin@RT-AC68U:/jffs/scripts# l s -lah / opt /lib/security/pam_google_authenticator.so
-rwxr-xr-x    1 admin    root       23.0K May 12 07:33 /opt/lib/security/pam_google_authenticator.so

Syslog

Jun 13 20:34:19 RT-AC68U user.err syslog: in openpam_check_path_owner_perms(): /tmp/mnt/RT-AC68U/: insecure ownership or permissions
Jun 13 20:34:19 RT-AC68U user.err syslog: in try_module(): /opt/lib/security/pam_google_authenticator.so: Operation not permitted
Jun 13 20:34:19 RT-AC68U user.err syslog: in openpam_load_module(): no /opt/lib/security/pam_google_authenticator.so found


Jun 13 20:34:19 RT-AC68U daemon.notice ovpn-server2[11305]: xxx.xxx.xxx.xxx PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1

Jun 13 20:34:19 RT-AC68U daemon.warn ovpn-server2[11305]: xxx.xxx.xxx.xxx PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn-plugin-auth-pam.so
Jun 13 20:34:19 RT-AC68U daemon.err ovpn-server2[11305]: xxx.xxx.xxx.xxx TLS Auth Error: Auth Username/Password verification failed for peer


Jun 13 20:34:19 RT-AC68U daemon.notice ovpn-server2[11305]: xxx.xxx.xxx.xxx Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Jun 13 20:34:19 RT-AC68U daemon.notice ovpn-server2[11305]: xxx.xxx.xxx.xxx [client] Peer Connection Initiated with [AF_INET6]::ffff:xxx.xxx.xxx.xxx:39432
Jun 13 20:34:20 RT-AC68U daemon.notice ovpn-server2[11305]: xxx.xxx.xxx.xxx PUSH: Received control message: 'PUSH_REQUEST'
Jun 13 20:34:20 RT-AC68U daemon.notice ovpn-server2[11305]: xxx.xxx.xxx.xxx Delayed exit in 5 seconds
Jun 13 20:34:20 RT-AC68U daemon.notice ovpn-server2[11305]: xxx.xxx.xxx.xxx SENT CONTROL [client]: 'AUTH_FAILED' (status=1)

I've probably missed something really basic o had a PEBCAK moment, so I'll call it a day....unless someone can spot the error!

 

[kfp]

I think it wants this dir to be 755 as well

 Jun 13 20:34:19 RT-AC68U user.err syslog: in openpam_check_path_owner_perms(): /tmp/mnt/RT-AC68U/: insecure ownership or permissions

 

[ColinTaylor]

Colin, Thanks.... I solved the problem.

Just for curiosity I thought I'd log the dropped packets from that subnet instead of just dropping them silently.

Jun 12 22:49:43 SRC=185.200.118.79 PROTO=UDP DPT=1194
Jun 13 01:19:39 SRC=185.200.118.46 PROTO=UDP DPT=443
Jun 13 01:33:03 SRC=185.200.118.89 PROTO=TCP DPT=1723
Jun 13 09:56:45 SRC=185.200.118.53 PROTO=UDP DPT=1194
Jun 13 12:07:19 SRC=185.200.118.46 PROTO=UDP DPT=443
Jun 13 14:20:34 SRC=185.200.118.73 PROTO=TCP DPT=1723
Jun 13 15:46:12 SRC=185.200.118.67 PROTO=TCP DPT=3389
Jun 13 22:29:33 SRC=185.200.118.69 PROTO=UDP DPT=1194
Jun 13 23:53:37 SRC=185.200.118.46 PROTO=UDP DPT=443
Jun 14 02:28:51 SRC=185.200.118.80 PROTO=TCP DPT=1723
Jun 14 04:11:57 SRC=185.200.118.50 PROTO=TCP DPT=3389
Jun 14 10:37:04 SRC=185.200.118.46 PROTO=UDP DPT=1194
Jun 14 11:41:59 SRC=185.200.118.46 PROTO=UDP DPT=443
Jun 14 14:36:48 SRC=185.200.118.49 PROTO=TCP DPT=1723
Jun 14 16:11:01 SRC=185.200.118.85 PROTO=TCP DPT=3389
Jun 14 23:12:18 SRC=185.200.118.79 PROTO=UDP DPT=1194
Jun 15 00:07:45 SRC=185.200.118.46 PROTO=UDP DPT=443
Jun 15 01:42:02 SRC=185.200.118.74 PROTO=TCP DPT=1723
Jun 15 03:44:51 SRC=185.200.118.56 PROTO=TCP DPT=3389
Jun 15 11:03:25 SRC=185.200.118.47 PROTO=UDP DPT=1194
Jun 15 11:59:57 SRC=185.200.118.46 PROTO=UDP DPT=443
Jun 15 13:58:59 SRC=185.200.118.85 PROTO=TCP DPT=1723
Jun 15 16:25:39 SRC=185.200.118.89 PROTO=TCP DPT=3389
Jun 15 22:39:16 SRC=185.200.118.39 PROTO=UDP DPT=1194
Jun 16 00:38:10 SRC=185.200.118.46 PROTO=UDP DPT=443
Jun 16 02:33:45 SRC=185.200.118.35 PROTO=TCP DPT=1723
Jun 16 04:04:41 SRC=185.200.118.39 PROTO=TCP DPT=3389
Jun 16 10:25:55 SRC=185.200.118.44 PROTO=UDP DPT=1194
Jun 16 11:40:21 SRC=185.200.118.46 PROTO=UDP DPT=443
Jun 16 13:13:02 SRC=185.200.118.36 PROTO=TCP DPT=1723
Jun 16 21:53:47 SRC=185.200.118.88 PROTO=UDP DPT=1194
Jun 17 01:12:43 SRC=185.200.118.57 PROTO=TCP DPT=1723
Jun 17 01:13:52 SRC=185.200.118.46 PROTO=UDP DPT=443

Persistent buggers. So that's HTTPS, OpenVPN, PPTP and RDP.

 

[kfp]

Persistent buggers. So that's HTTPS, OpenVPN, PPTP and RDP.

From quite a few different IPs too, those IPs seem to be labelled as bad acting port scanning on various IP reputation sites already, I wonder why the ISP haven’t deal with this.

 

[ColinTaylor]

From quite a few different IPs too, those IPs seem to be labelled as bad acting port scanning on various IP reputation sites already, I wonder why the ISP haven’t deal with this.

I guess they would claim that there's nothing wrong (bad) with only port scanning. The worst such offender is SHODAN.

 

[maxbraketorque]

...

​

Most experts speculate that hosting a UDP Openvpn Server is less likely to attract attention, whereas they concede a TCP OpenVPN Server is inevitably going to attract unwanted attention, yet this is deemed 'normal Internet' noise so the 'advice' is 'don't worry about it' - ignore it.

...

Just yesterday I started sending my ASUS router log to a syslog server on my NAS, and I was shocked at what I saw. The ASUS OVPN server is receiving approximately 8 login attempts per minute. Its been like that since I started sending log entries to the syslog server yesterday. Presumably I'm safe, but that's a rather scary number of attempt per minute. Maybe I need to get that blacklist connection script running sooner rather than later.

 

[skeal]

Just yesterday I started sending my ASUS router log to a syslog server on my NAS, and I was shocked at what I saw. The ASUS OVPN server is receiving approximately 8 login attempts per minute. Its been like that since I started sending log entries to the syslog server yesterday. Presumably I'm safe, but that's a rather scary number of attempt per minute. Maybe I need to get that blacklist connection script running sooner rather than later.

Use a different port like 21317 (I made that up) the port scanners use the most obvious ports.

 

[maxbraketorque]

Use a different port like 21317 (I made that up) the port scanners use the most obvious ports.

That's a good idea. I'll try that.