AC3100 / 380.70 Block incoming IP

[armsAC3100]

I am getting frequent incoming connection attempts to connect to my OVPN server from 185.200.118.0/24 . I do have certificate security setup so it should be fairly secure but I would like to eliminate it completely.

I have found several relatively complex posts with scripts to address similar issues.
Being only minimally competent in Linux I would like to keep it as simple as possible.

Why do I need more than the following line to cause the router to drop all requests (OVPN or other) from 185.200.118.xxx?

iptables -A INPUT -s 185.200.118.0/24 -j DROP

Thanks, Al

 

[ColinTaylor]

You are correct but you need to use -I instead of -A to insert the rule in the correct place. So this is your firewall-start script:

firewall-start

#!/bin/sh
iptables -I INPUT -s 185.200.118.0/24 -j DROP

In fact I've recently added exactly the same line to my firewall-start script!

EDIT: Actually I think there's a problem with this that I spotted the other day (and then forgot about). It might vary depending on the firmware, but I think because the VPN server starts after the firewall the ACCEPT rule for the VPN gets inserted before the DROP rule.

EDIT 2: OK to get this to work I had to move the rule to an openvpn-event script. This may or may not be necessary in your firmware.

EDIT 3: Updated code to that in post #6. Because there can be scenarios where the firewall is updated but the VPN server is not restarted is best to have both the firewall-start script and the openvpn-event script.

openvpn-event

#!/bin/sh
if [ "$1" = "tun21" ] || [ "$1" = "tun22" ]
then
    logger -t openvpn-event "Apply additional firewall rules"
    iptables -D INPUT -s 185.200.118.0/24 -j DROP
    iptables -I INPUT -s 185.200.118.0/24 -j DROP
fi

 

[armsAC3100]

You are correct but you need to use -I instead of -A to insert the rule in the correct place. So this is your firewall-start script:

EDIT 2: OK to get this to work I had to move the rule to an openvpn-event script. This may or may not be necessary in your firmware.

#!/bin/sh
logger -t openvpn-event "Apply additional firewall rules"
iptables -D INPUT -s 185.200.118.0/24 -j DROP
iptables -I INPUT -s 185.200.118.0/24 -j DROP

I created a file "/jffs/scripts/openvpn-event" with the code shown above. I do not see any logfile entry indicated that it was executed. Obviously I missed something.

Al

 

[ColinTaylor]

You should see it when the VPN server starts or stops. So either at boot time or when you toggle the VPN on/off button in the GUI.

Jun  4 13:04:28 openvpn[6011]: /usr/sbin/ip addr add dev tun21 10.8.0.1/24 broadcast 10.8.0.255
Jun  4 13:04:28 openvpn[6011]: updown.sh tun21 1500 1622 10.8.0.1 255.255.255.0 init
Jun  4 13:04:28 openvpn-event: Apply additional firewall rules
Jun  4 13:04:28 openvpn[6011]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Jun  4 13:04:28 openvpn[6011]: Socket Buffers: R=[122880->122880] S=[122880->122880]

 

[Martineau]

I created a file "/jffs/scripts/openvpn-event" with the code shown above.

I suggest you clone /jffs/scripts/openvpn-event from @john9527's openvpn-event script template so you can explicitly choose which openvpn-event trigger code is actually used by each individual Server/Client.

i.e. (assuming you are using OpenVPN Server #1) place your custom firewall rules in

/jffs/scripts/vpnserver1-route-up.sh

otherwise your code/rules will be applied for every openvpn-event for ALL servers and clients, which may cause confusion at a later date.

 

[ColinTaylor]

Good information from Martineau (and john9527). Below is an updated version of the openvpn-event script if you didn't want to use the "more versatile" solution.

#!/bin/sh
if [ "$1" = "tun21" ] || [ "$1" = "tun22" ]
then
    logger -t openvpn-event "Apply additional firewall rules"
    iptables -D INPUT -s 185.200.118.0/24 -j DROP
    iptables -I INPUT -s 185.200.118.0/24 -j DROP
fi

 

[armsAC3100]

You should see it when the VPN server starts or stops. So either at boot time or when you toggle the VPN on/off button in the GUI.

Jun  4 13:04:28 openvpn[6011]: /usr/sbin/ip addr add dev tun21 10.8.0.1/24 broadcast 10.8.0.255
Jun  4 13:04:28 openvpn[6011]: updown.sh tun21 1500 1622 10.8.0.1 255.255.255.0 init
Jun  4 13:04:28 openvpn-event: Apply additional firewall rules
Jun  4 13:04:28 openvpn[6011]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Jun  4 13:04:28 openvpn[6011]: Socket Buffers: R=[122880->122880] S=[122880->122880]

Colin, Thanks.... I solved the problem. My stupidity. Typo in the script file name!

Al

 

[Martineau]

Good information from Martineau (and john9527). Below is an updated version of the openvpn-event script if you didn't want to use the "more versatile" solution.

#!/bin/sh
if [ "$1" = "tun21" ] || [ "$1" = "tun22" ]
then
    logger -t openvpn-event "Apply additional firewall rules"
    iptables -D INPUT -s 185.200.118.0/24 -j DROP
    iptables -I INPUT -s 185.200.118.0/24 -j DROP
fi

Although you have now restricted the rule processing for only the OpenVPN servers, the script will still be executed multiple times - once for each of the possible server events,

Also, whilst it is extremely unlikely that having deleted the rule, the creation of the new rule would fail, it is best practice in this situation (where two separate processes rely on the existence of the same rule) to check if the rule already exists rather than blindly deleting the critical rule thereby eliminating the possibility of being exposed.

 

[ColinTaylor]

Although you have now restricted the rule processing for only the OpenVPN servers, the script will still be executed multiple times - once for each of the possible server events,

Also, whilst it is extremely unlikely that having deleted the rule, the creation of the new rule would fail, it is best practice in this situation (where two separate processes rely on the existence of the same rule) to check if the rule already exists rather than blindly deleting the critical rule thereby eliminating the possibility of being exposed.

No that's fine. This is a very specific case. Nothing "relies" on the existence of these rules. And multiple executions are not a problem. But your point is valid, one wouldn't normally do things this way.

 

[maxbraketorque]

Is there no way to accomplish this within the UI of a stock firmware or with a Merlin build using its UI? I'm not a noob, but I have no time to try to figure out scripts of this type. I guess there is no blacklist option that is part of the OVPN server command set?

 

[ColinTaylor]

Is there no way to accomplish this within the UI a stock firmware or with a Merlin build using its UI? I'm not a noob, but I have no time to try to figure out scripts of this type. I guess there is no blacklist option that is part of the OVPN server command set?

As mentioned in the other thread Network Services Filter won't work because that is for LAN to WAN connections. I don't use Merlin's firmware so I don't know all the options available to you. However you could try this "cheat" and see if it works. Like I said, I don't use Merlin's firmware so I can't test this.

 

[maxbraketorque]

As mentioned in the other thread Network Services Filter won't work because that is for LAN to WAN connections. I don't use Merlin's firmware so I don't know all the options available to you. However you could try this "cheat" and see if it works. Like I said, I don't use Merlin's firmware so I can't test this.
View attachment 13453

That's cute. I'll give it a try. Thanks much!

 

[ColinTaylor]

@maxbraketorque Having looked at this in more detail today I don't think the Virtual Server method will work.

The reason is the same as in post #2. When the VPN server starts up it places its own ACCEPT rule at the very beginning of the filter/INPUT chain. It also does the thing with the nat/PREROUTING chain. This means that the Virtual Server rule is never executed.

 

[maxbraketorque]

@maxbraketorque Having looked at this in more detail today I don't think the Virtual Server method will work.

The reason is the same as in post #2. When the VPN server starts up it places its own ACCEPT rule at the very beginning of the filter/INPUT chain. It also does the thing with the nat/PREROUTING chain. This means that the Virtual Server rule is never executed.

Yeah, I realized the same thing this morning when I woke up. I just checked the log now, and sure enough, there was another knock on the door of the router OVPN server last night with the port forward rule engaged.

I looked through the OVPN server startup options on the OVPN website, and I didn't see a blacklist command anywhere. Do you know if that's correct? Would seem like a nice feature to have.

 

[kfp]

I looked through the OVPN server startup options on the OVPN website, and I didn't see a blacklist command anywhere. Do you know if that's correct? Would seem like a nice feature to have.

These type of ACL is better to be handled in the OS/kernel/iptables than in the server software itself.

Maybe this can be handled with the openvpn-event user script?

Or even easier, maybe give Skynet a try?
https://www.snbforums.com/index.php?posts/115856/

 

[Martineau]

Yeah, I realized the same thing this morning when I woke up. I just checked the log now, and sure enough, there was another knock on the door of the router OVPN server last night with the port forward rule engaged.

I looked through the OVPN server startup options on the OVPN website, and I didn't see a blacklist command anywhere. Do you know if that's correct? Would seem like a nice feature to have.

If I may, could I clarify what your utltimate goal is?

At present the potential hacker is persistently knocking on the OpenVPN server door, presumably trying to breach the certificate+password combo and fortunately is being successfully blocked - ether with or without the additional blacklist INPUT chain drop rule.

Whilst I acknowledge your preference to have a GUI solution, if I understand your objective correctly, would it be fair to say that implementing both of the methods below would ultimately 'lock-down' the OpenVPN Server to your satisfaction?

1. 2-Factor OpenVPN server authentication.
2. Implement a Source IP ACL blacklist or whitelist in the OpenVPN server '--client-connect' script.

Am I on the right track?

 

[maxbraketorque]

If I may, could I clarify what your utltimate goal is?

At present the potential hacker is persistently knocking on the OpenVPN server door, presumably trying to breach the certificate+password combo and fortunately is being successfully blocked - ether with or without the additional blacklist INPUT chain drop rule.

Whilst I acknowledge your preference to have a GUI solution, if I understand your objective correctly, would it be fair to say that implementing both of the methods below would ultimately 'lock-down' the OpenVPN Server to your satisfaction?

1. 2-Factor OpenVPN server authentication.
2. Implement a Source IP ACL blacklist or whitelist in the OpenVPN server '--client-connect' script.

Am I on the right track?

Yes, that's the general idea in the sense that I'd like to be able to block certain IP ranges from ever knowing that a VPN server exists on the router. In reviewing the '--client-connect' definition on the OVPN website, it appears that this launches a script after a successful connection. Is that correct? If '--client-connect' goes into action after a successful login, then maybe Merlin FW + Skynet better suits my intent. I wonder why ASUS doesn't have a blacklist feature like this for the built-in router services. It seems so obvious. I'm also puzzled why OVPN doesn't have an automatic reject blacklist (or whitelist).

 

[Martineau]

Yes, that's the general idea in the sense that I'd like to be able to block certain IP ranges from ever knowing that a VPN server exists on the router.

I suspect that even with port scanning blockers e.g. Skynet there is no way you can truly obfuscate the existence of your OpenVPN server(s).

i.e. I would hope that my IP address is not on any blacklist but what are the chances that I would hit your custom OpenVPN server port on my first (and only attempt) and get a response?

In reviewing the '--client-connect' definition on the OVPN website, it appears that this launches a script after a successful connection. Is that correct? If '--client-connect' goes into action after a successful login, then maybe Merlin FW + Skynet better suits my intent.

​

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.'

However, I prefer to adopt a more paranoid stance, so I do use the OpenVPN

'--client-connect'

feature to decide on a user by user basis from/when/what they can access on my LAN

Spoiler: /jffs/scripts/VPNClientConnect.sh

    while read LINE
        do
            #Say "***DEBUG Check LINE=>$LINE<"
            case "$LINE" in
            ifconfig-push* | staticip* )
                Parse "$LINE" " " KEYWORD IP_ADDR SUBNET_MASK
                # Assign static IP address to client 'echo -e $KEYWORD $IP_ADDR $SUBNET_MASK >> $CCD_FILE'
                Assign_Static_IP
                ;;
            *passthru*)                                             # My pseudo OpenVPN server directive
                # This client will 'pass-thru' the router and use the VPN client specified
                # e.g. pass-thru 2
                Parse "$LINE" " " KEYWORD VPN_NUM
                PASSTHRU=1
                #Say "***DEBUG KEYWORD="$KEYWORD "VPN_NUM="$VPN_NUM
                ;;
            *forcedns*)                                             # My pseudo OpenVPN server directive
                # This client cannot override the pushed DNS
                # e.g. forcedns 10.0.0.254
                Parse "$LINE" " " KEYWORD FORCED_DNS
                FORCEDNS=1
                #Say "***DEBUG KEYWORD="$KEYWORD "FORCED_DNS="$FORCED_DNS
                ;;
            *lanonly*)                                              #  My pseudo OpenVPN server directive
                # This client cannot passthru outbound via the WAN or any VPN Client tunnel; only LAN resources are accessible
                # v384.xx Partially Superceded by 'Client will use VPN to access=LANONLY' GUI option"
                LANONLY=1
                #LAN_RESOURCES=$(echo $LINE | cut -d' ' -f2-)       # Explicit LAN resources my extra!
                LAN_RESOURCES=$(echo $LINE | awk '{$1=""; print $0}')   # Explicit LAN resources my extra! allow #comments
                #Say "***DEBUG KEYWORD="$KEYWORD
                ;;
            *wanonly*)                                              #  My pseudo OpenVPN server directive
                # This client cannot access the LAN; only WAN is accessible
                # v384.xx Uses 'Client will use VPN to access=INTERNETONLY' GUI option" for ALL clients
                WANONLY=1
                #Say "***DEBUG KEYWORD="$KEYWORD
                ;;
            *wol*)
                # This client is allowed to issue WOL commands to LAN devices
                # e.g. wol xx:xx:xx:xx:xx:xx
                #      wol xxx.xxx.xxx.xxx
                Parse "$LINE" " " KEYWORD WOL_DEVICE
                WOL_LIST=$WOL_LIST" "$WOL_DEVICE
                #Say "***DEBUG KEYWORD="$KEYWORD $WOL_DEVICE ">"$WOL_LIST"<"
                ;;
            *allowip*)
                # List of ALLOWED remote IP addresses
                Say "Psuedo command 'allowip' is being enforced....."
                ALLOWED_ACL=$(echo $LINE | cut -d' ' -f2-)
                #Say "***DEBUG KEYWORD="$KEYWORD "ALLOWED_CL=>"$ALLOWED_ACL"<"
                ;;
            *blockip*)
                # List of BLOCKED remote IP addresses
                Say "Psuedo command 'blockip' is being enforced....."
                BLOCKED_ACL=$(echo $LINE | cut -d' ' -f2-)
                #Say "***DEBUG KEYWORD="$KEYWORD "BLOCKED_CL=>"$BLOCKED_ACL"<"
                ;;
            *allowperiod*)
                # List avail periods hh:59-hh:mm,prime,overnight
                Say "Psuedo command 'allowperiod' is being enforced....."
                AVAIL_PERIODS=$(echo $LINE | cut -d' ' -f2-)
                #Say "***DEBUG KEYWORD="$KEYWORD "AVAIL_PERIODS=>"$AVAIL_PERIODS"<"
                ;;
            *restrictperiod*)
                # List restricted times hh:mm-hh:mm,online,overnight
                Say "Psuedo command 'restrictperiod' is being enforced....."
                RESTRICTED_PERIODS=$(echo $LINE | cut -d' ' -f2-)
                Say "***DEBUG KEYWORD="$KEYWORD "RESTRICTED_PERIODS=>"$RESTRICTED_PERIODS"<"
                ;;
            *)
                Say "RAW - '"$LINE"'"
                echo -e "$LINE" >> $CCD_FILE        # Assume user has RTFM'd ADVANCED CCD directive & specified correct syntax!!!
                                                    # i.e. ifconfig-push,push,push-reset,push-remove,iroute,iroute-ipv6,disable and config
                ;;
            esac
        done < $CCD_USER_ARGS

..and optionally immediately ABORT the connection if it is 'suspicious'

 

[Martineau]

Continued from post post #18

e.g. User 'SGA5' did indeed make a connection (Passed PAM authentication)

1. Will be assigned a static IP address
2. Will be allowed to WOL the two NAS servers
3. Will be allowed access to specific LAN resources (IPCams)
4. Wasn't in the 'restricted period'
5. but the source address was on the 'blockip' blacklist ACL so the SGA5 client was terminated by OpenVPN and a security notification email was sent.​

Jun 13 13:10:27 RT-AC68U daemon.notice ovpn-server2[1818]: xxx.xxx.xxx.xxx TLS: Initial packet from [AF_INET6]::ffff:xxx.xxx.xxx.xxx:56217, sid=xxxxxxxxxxxxxxxxxxx
Jun 13 13:10:28 RT-AC68U daemon.notice ovpn-server2[1818]: xxx.xxx.xxx.xxx VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, CN=client, emailAddress=me@myhost.mydomain
Jun 13 13:10:28 RT-AC68U daemon.notice ovpn-server2[1818]: xxx.xxx.xxx.xxx PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Jun 13 13:10:28 RT-AC68U daemon.notice ovpn-server2[1818]: xxx.xxx.xxx.xxx TLS: Username/Password authentication succeeded for username 'SGA5'
Jun 13 13:10:28 RT-AC68U daemon.notice ovpn-server2[1818]: xxx.xxx.xxx.xxx Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Jun 13 13:10:28 RT-AC68U daemon.notice ovpn-server2[1818]: xxx.xxx.xxx.xxx [client] Peer Connection Initiated with [AF_INET6]::ffff:xxx.xxx.xxx.xxx:56217
Jun 13 13:10:28 RT-AC68U daemon.notice ovpn-server2[1818]: client/xxx.xxx.xxx.xxx MULTI_sva: pool returned IPv4=10.16.0.2, IPv6=(Not enabled)

Jun 13 13:10:28 RT-AC68U user.warn (VPNClientConnect.sh): 22847 v4.80 VPN Server 2 Client user 'SGA5' CCD configuration starting.... [/tmp/openvpn_cc_78e8367557529a5b.tmp]
Jun 13 13:10:28 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Processing Client_username file '/jffs/configs/openvpn/ccd2/client_SGA5'

Jun 13 13:10:28 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'staticip' will assign I/P address 10.16.0.22 to Client user 'SGA5'
Jun 13 13:10:28 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'allowip' is being enforced.....
Jun 13 13:10:28 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'blockip' is being enforced.....
Jun 13 13:10:29 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'restrictperiod' is being enforced.....
Jun 13 13:10:29 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'lanonly' will BLOCK ALL LAN access except to 'IPGroup' CAMERAS
Jun 13 13:10:30 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'lanonly' will BLOCK ALL LAN access except to 10.88.8.120 (CAM-W-JPT3815W.Martineau.lan)
Jun 13 13:10:30 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'lanonly' will BLOCK ALL LAN access except to 10.88.8.121 (CAM-L-F18918W.Martineau.lan)
Jun 13 13:10:30 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'lanonly' will BLOCK ALL LAN access except to 10.88.8.122 (CAM-W-JPT3815W.Martineau.lan)
Jun 13 13:10:30 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'lanonly' will BLOCK ALL LAN access except to 10.88.8.123 (CAM-L-IP2M841B.Martineau.lan)
Jun 13 13:10:30 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'lanonly' will BLOCK ALL LAN access except to 10.88.8.125 (CAM-W-IP2M841B.Martineau.lan)
Jun 13 13:10:30 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'lanonly' will BLOCK ALL LAN access except to 10.88.8.148 (RaspberryPiB.Martineau.lan)
Jun 13 13:10:30 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'forcedns' (8.8.4.4) will be applied to I/P 10.16.0.22
Jun 13 13:10:31 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'wol' (ether-wake) will be applied to MAC=XX:XX:XX:XX:XX:XX (10.88.8.197) DS-416.Martineau.lan
Jun 13 13:10:31 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command 'wol' (ether-wake) will be applied to MAC=XX:XX:XX:XX:XX:XX (10.88.8.195) DS-110J.Martineau.lan
Jun 13 13:10:31 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command **DEBUG PERIOD=00:59-05:00 FROM=>00:59< TO >05:00<
Jun 13 13:10:31 RT-AC68U user.warn (VPNClientConnect.sh): 22847 Psuedo command VPN Server 2 Client I/P xxx.xxx.xxx.xxx address is not PERIOD restricted

Jun 13 13:10:31 RT-AC68U user.warn (VPNClientConnect.sh): 22847 ***ERROR VPN Server 2 Client I/P xxx.xxx.xxx.xxx address is on BLOCKED ACL list - connection REFUSED

Jun 13 13:10:31 RT-AC68U user.warn (VPNClientConnect.sh): 22847 VPN Server 2 Client CCD configuration ended.

Jun 13 13:10:31 RT-AC68U daemon.warn ovpn-server2[1818]: client/xxx.xxx.xxx.xxx WARNING: Failed running command (--client-connect): external program exited with error status: 94
Jun 13 13:10:31 RT-AC68U daemon.notice ovpn-server2[1818]: client/xxx.xxx.xxx.xxx PUSH: Received control message: 'PUSH_REQUEST'
Jun 13 13:10:31 RT-AC68U daemon.notice ovpn-server2[1818]: client/xxx.xxx.xxx.xxx Delayed exit in 5 seconds
Jun 13 13:10:31 RT-AC68U daemon.notice ovpn-server2[1818]: client/xxx.xxx.xxx.xxx SENT CONTROL [client]: 'AUTH_FAILED' (status=1)
Jun 13 13:10:36 RT-AC68U daemon.notice ovpn-server2[1818]: client/xxx.xxx.xxx.xxx SIGTERM[soft,delayed-exit] received, client-instance exiting

Now no doubt it may be possible for the hacker to craft some clever method to prevent the script from terminating illegal connections (given it has already somehow presumably obtained the Certificate+password combo!) but hopefully the email has been already sent.

As @kfp pointed out, it shouldn't be necessary for OpenVPN to enforce blacklist/whitelist/ACLs but it allows at least some way of an additional heads-up and be forewarned to revoke/regenerate the appropriate certificates etc.

So it may be prudent to resurrect the 3-year old thread regarding the implementation of Google Authenticator for my OpenVPN Servers...as surely Two-Factor authentication should now be standard on the ASUS routers?​

 

[kfp]

So it may be prudent to resurrect the 3-year old thread regarding the implementation of Google Authenticator for my OpenVPN Servers...as surely Two-Factor authentication should now be standard on the ASUS routers?[/COLOR][/FONT][/LEFT]

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