What's new

AC3100 / 380.70 Block incoming IP

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

@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.
 
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 :p

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..
Code:
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

Code:
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!:oops:
 
I think it wants this dir to be 755 as well
Code:
 Jun 13 20:34:19 RT-AC68U user.err syslog: in openpam_check_path_owner_perms(): /tmp/mnt/RT-AC68U/: insecure ownership or permissions
 
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.
Code:
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. :p So that's HTTPS, OpenVPN, PPTP and RDP.
 
Persistent buggers. :p 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.
 
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.
 
...
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.
 
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.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top