1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

AC3100 / 380.70 Block incoming IP

Discussion in 'Asuswrt-Merlin' started by armsAC3100, Jun 4, 2018.

  1. maxbraketorque

    maxbraketorque Senior Member

    Joined:
    Dec 6, 2015
    Messages:
    381
    @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.
     
  2. Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!
  3. Martineau

    Martineau Very Senior Member

    Joined:
    Jul 8, 2012
    Messages:
    1,603
    Location:
    UK
    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:
    [email protected]:/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:
     
  4. kfp

    kfp Senior Member

    Joined:
    Jun 26, 2014
    Messages:
    271
    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
     
  5. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    5,516
    Location:
    UK
    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.
     
  6. kfp

    kfp Senior Member

    Joined:
    Jun 26, 2014
    Messages:
    271
    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.
     
  7. ColinTaylor

    ColinTaylor Part of the Furniture

    Joined:
    Mar 31, 2014
    Messages:
    5,516
    Location:
    UK
    I guess they would claim that there's nothing wrong (bad) with only port scanning. The worst such offender is SHODAN.
     
Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!