You Can't Try It If You Don't Knock It
Small and medium business branch installations often present some unique problems, and access for remote support can be a prevalent one. This is especially true when one wants to avoid opening unnecessary access from the Internet. Permitting access only from a jump-off point with a fixed IP address was a good approach; until the day came where that fixed IP address became unreachable during a customer crisis. Painful moments like these are the mother of new approaches.
So, how do we enable remote access from almost anywhere without increasing the attack footprint of a customer's router?
A few years ago, I was reading an old blog post by my friend Aaron Conaway where he talked about port knocking on Linux. This is a process where a predefined set of ports, accessed in a particular order, trigger access to a set of otherwise-closed services.
I became intrigued and started searching for people who had done this on IOS. I found a few posts, but all involved two processes that I prefer to avoid:
- Logging all packets on an interface for tracking the access sequence. As soon as we add a log keyword for an interface Access Control List (ACL), CEF is disabled and the router's performance suffers.
- Using a script to change the router's configuration to enable services. I'm not against using a script to change router configuration, but only if it's necessary. In this particular case, it isn't.
Using Control Plane Policing (CoPP) and lock-and-key dynamic ACLs, it isn't a difficult process to make this happen elegantly. If you're interested in giving it a try, here's how we get started.
Operation
All services that we want to permit are denied by default. Predefined knock triggers (UDP packets in this example) are permitted to reach the control plane. At this point they are dropped and logged by the CoPP configuration.
Once the knock sequence is verified, a dynamic ACL entry is created that permits traffic to the applicable services from the source address of the knock sequence.
Configuration
We'll start by establishing a sequence of five pseudo-random ports for the knock sequence itself. These can be TCP or UDP ports, but I'll stick with UDP ports for this example.
object-group service OG_Knock
udp eq 46543
udp eq 28654
udp eq 40204
udp eq 57566
udp eq 34515
We need to be sure that these ports are permitted by the inbound interface and/or firewall security mechanisms. They will be dropped once they reach the control plane. The process won't work if they are blocked before they reach this point because we are relying on CoPP logging for the trigger.
Next, we'll define the services that we want permitted after a successful knock. We'll use some common ones: SSH on port 22/tcp, and the AnyConnect access VPN in TLS/DTLS mode using ports 80/tcp, 443/tcp, and 443/udp.
object-group service OG_Knock_Services
tcp eq 22
tcp eq 80
tcp-udp eq 443
Once these are defined, we'll define a CoPP policy to deny attempts to our knock sequence.
ip access-list extended ACL_CoPP_Knock
permit object-group OG_Knock any any
!
class-map match-any CM_CoPP_Knock
match access-group name ACL_CoPP_Knock
!
policy-map PM_CoPP
class CM_CoPP_Knock
drop
!
control-plane host
service-policy input PM_CoPP
Then, we add CoPP logging of denied packets to generate a set of syslog events when the elements of the sequence have been triggered.
class-map type logging match-any CM_CoPP_Log
match packets dropped
!
policy-map type logging PM_CoPP_Log
class CM_CoPP_Log
log
!
control-plane host
service-policy type logging input PM_CoPP_Log
Here's where we resurrect the old lock and key dynamic ACLs to apply a dynamic means to permit our remote access.
This has been tested using inbound ACLs on interfaces, using the Zone-based Policy Firewall (ZBF/ZPF) and using CoPP itself. Anything that can define traffic based on an extended ACL should be able to use this mechanism, but I haven't tested beyond these.
ip access-list extended ACL_Internet_In
dynamic DACL_Internet_In permit object-group OG_Knock_Services any any
deny object-group OG_Knock_Services any any
permit ip any any
The "permit ip any any" statement is for proof of concept only. Definitely replace this with whatever permit/deny statements are necessary for your configuration.
Now to tie it all together, we enable sequence numbers in the router’s syslog entries and use an Embedded Event Manager (EEM) applet to detect the sequence, verify it, and add the appropriate entry to the dynamic ACL. No configuration changes to the router are made in the process. The sequence numbers are important to this application as the EEM applet uses them to verify that the ports were triggered in the correct order.
There are two key variables that we need to set for the script. They are the name of the extended ACL that the script will operate on, and the idle timeout for the dynamic ACL entry. If there is no traffic during the timeout period, the knock will need to be repeated to regain access.
service sequence-numbers
!
event manager environment _knock_Services ACL_Internet_In
event manager environment _knock_Timeout 1
!
event manager applet EEM_Knock
event tag _knock_Tag_E1 syslog pattern ".*%CP-6-UDP.*46543.$"
event tag _knock_Tag_E2 syslog pattern ".*%CP-6-UDP.*28654.$"
event tag _knock_Tag_E3 syslog pattern ".*%CP-6-UDP.*40204.$"
event tag _knock_Tag_E4 syslog pattern ".*%CP-6-UDP.*57566.$"
event tag _knock_Tag_E5 syslog pattern ".*%CP-6-UDP.*34515.$"
trigger occurs 5 period 1
correlate event _knock_Tag_E1 and event _knock_Tag_E2 and event _knock_Tag_E3 and event _knock_Tag_E4 and event _knock_Tag_E5
action 0000 info type event reqinfo tag _knock_Tag_E1
action 0010 regexp “^([0-9]+):.*DROP.* ([0-9.]+)" "$_syslog_msg" _knock_RegEx_Result _knock_Sequence_E1 _knock_Source_E1
action 0020 info type event reqinfo tag _knock_Tag_E2
action 0030 regexp “^([0-9]+):.*DROP.* ([0-9.]+)" "$_syslog_msg" _knock_RegEx_Result _knock_Sequence_E2 _knock_Source_E2
action 0040 info type event reqinfo tag _knock_Tag_E3
action 0050 regexp “^([0-9]+):.*DROP.* ([0-9.]+)" "$_syslog_msg" _knock_RegEx_Result _knock_Sequence_E3 _knock_Source_E3
action 0060 info type event reqinfo tag _knock_Tag_E4
action 0070 regexp “^([0-9]+):.*DROP.* ([0-9.]+)" "$_syslog_msg" _knock_RegEx_Result _knock_Sequence_E4 _knock_Source_E4
action 0080 info type event reqinfo tag _knock_Tag_E5
action 0090 regexp “^([0-9]+):.*DROP.* ([0-9.]+)" "$_syslog_msg" _knock_RegEx_Result _knock_Sequence_E5 _knock_Source_E5
action 0100 if $_knock_Sequence_E1 lt $_knock_Sequence_E2
action 0110 if $_knock_Sequence_E2 lt $_knock_Sequence_E3
action 0120 if $_knock_Sequence_E3 lt $_knock_Sequence_E4
action 0130 if $_knock_Sequence_E4 lt $_knock_Sequence_E5
action 0140 if $_knock_Source_E1 eq $_knock_Source_E2
action 0150 if $_knock_Source_E2 eq $_knock_Source_E3
action 0160 if $_knock_Source_E3 eq $_knock_Source_E4
action 0170 if $_knock_Source_E4 eq $_knock_Source_E5
action 0180 cli command "enable"
action 0190 cli command "access-template $_knock_Services D$_knock_Services host $_knock_Source_E1 any timeout $_knock_Timeout"
action 0200 end
action 0210 end
action 0220 end
action 0230 end
action 0240 end
action 0250 end
action 0260 end
action 0270 end
action 0280 exit
Ideally, I’d like to be able to have this pull the event sequence from the OG_Knock object group. I suspect that this might be possible using a TCL script rather than an applet, but expedience is going to win out over elegance for the moment. The applet converter at http://www.marcuscom.com/convert_applet/ will create a good beginning for the adventurous.
Thanks to Joe Clarke for his input on extracting variables from multiple trigger events and for the link to the applet-to-script converter.
Clients
Triggering the knock sequence itself requires an extra piece of software. This are available for almost all platforms.
For iOS: KnockOnD
For Android: PortKnocker
For Linux/Unix/macOS: knock (included in the knockd server download)
For Windows: KnockKnock
The Whisper in the Wires
This provides a poor man's two-factor authentication (2FA), but I wouldn't really bill it as this. This is mostly because the trigger ports are semi-fixed. This is more about reducing the attack footprint of the router while still enabling remote access for support. I use client-side SSH keys for SSH access, and cloud-based 2FA solutions for AnyConnect access in addition to this.
Originally published on the Cisco Support Communities site.