Example: Configure a Filter to Block Telnet and SSH Access
Requirements
You need two devices running Junos OS with a shared network link. No special configuration beyond basic device initialization (management interface, remote access, user login accounts, etc.) is required before configuring this example. While not a strict requirement, console access to the R2 device is recommended.
Our content testing team has validated and updated this example.
Overview and Topology
In this example, you create an IPv4 stateless firewall filter that logs and rejects Telnet or SSH packets sent to the local Routing Engine, unless the packet originates from the 192.168.1.0/30 subnet. The filter is applied to the loopback interface to ensure that only traffic destined to the local device is affected. You apply the filter in the input direction. An output filter is not used. As a result all locally generated traffic is allowed.
-
To match packets originating from a specific subnet or IP prefix, you use the
source-addressIPv4 match condition applied in the input direction. -
To match packets destined for the Telnet port and SSH ports, you use the
protocol tcpmatch condition combined with aport telnetandport sshIPv4 match conditions applied in the input direction.
Example Topology
Figure 1 shows the test topology for this example. The firewall filter is applied to the R2 device, making it the device under test (DUT). The R1 and the R2 devices share a link that is assigned a subnet of 192.168.1.0/30. Both devices have loopback addresses assigned from the 192.168.255.0/30 prefix using a /32 subnet mask. Static routes provide reachability between loopback addresses because an interior gateway protocol is not configured in this basic example.
Configuration
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.
By design the sample filter restricts Telnet and SSH access to R2 unless it originates from the shared subnet at R1. If you use SSH or Telnet to access the R2 device directly, you will lose connectivity when the filter is applied. We recommend that you have console access when configuring this example. If needed you can use the R1 device as a jump host to launch an SSH session to R2 after the filter is applied. Alternatively, consider modifying the sample filter to also permit the IP subnet assigned to the machine you use to access the R2 device.
Perform the following tasks to configure this example:
- CLI Quick Configuration
- Configure the R1 Device
- Verify and Commit the Configuration at the R1 Device
- Configure the R2 Device
- Verify and Commit the Configuration at Device R2
CLI Quick Configuration
Quick Configuration for the R1 Device
To quickly configure the R1
device,
edit the following commands as needed and paste them into the CLI at the
[edit] hierarchy level. Be sure to issue a
commitin
configuration mode to activate the changes.
set system host-name R1 set system services ssh root-login allow set interfaces ge-0/0/0 description "Link from R1 to R2" set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/30 set interfaces lo0 unit 0 family inet address 192.168.255.1/32 set routing-options static route 192.168.255.2/32 next-hop 192.168.1.2
Quick Configuration for the R2 Device
To quickly configure the R2
device,
edit the following commands as needed and paste them into the CLI at the
[edit] hierarchy level. Be sure to issue a
commit
in
configuration mode to activate the changes.
Consider using commit-confirmed when making changes that
might
affect
remote access to your
device.
Activating a Junos OS Configuration but Requiring
Confirmation
set system host-name R2 set system services ssh root-login allow set system services telnet set interfaces ge-0/0/0 description "Link from R2 to R1" set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/30 set interfaces lo0 unit 0 family inet filter input local_acl set interfaces lo0 unit 0 family inet address 192.168.255.2/32 set firewall family inet filter local_acl term terminal_access from source-address 192.168.1.0/30 set firewall family inet filter local_acl term terminal_access from protocol tcp set firewall family inet filter local_acl term terminal_access from port ssh set firewall family inet filter local_acl term terminal_access from port telnet set firewall family inet filter local_acl term terminal_access then accept set firewall family inet filter local_acl term terminal_access_denied from protocol tcp set firewall family inet filter local_acl term tcp-estab from protocol tcp set firewall family inet filter local_acl term tcp-estab from tcp-established set firewall family inet filter local_acl term tcp-estab then accept set firewall family inet filter local_acl term terminal_access_denied from port ssh set firewall family inet filter local_acl term terminal_access_denied from port telnet set firewall family inet filter local_acl term terminal_access_denied then log set firewall family inet filter local_acl term terminal_access_denied then reject set firewall family inet filter local_acl term default-term then accept set routing-options static route 192.168.255.1/32 next-hop 192.168.1.1
Configure the R1 Device
Step-by-Step Procedure
Follow these steps to configure the R1 device:
-
Configure the interfaces:
[edit] user@R1# set interfaces ge-0/0/0 description "Link from R1 to R2" user@R1# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/30 user@R1# set interfaces lo0 unit 0 family inet address 192.168.255.1/32
-
Configure the host name and static route to the R2 device’s loopback address. You also configure Telnet and SSH access:
[edit] user@R1# set system host-name R1 user@R1# set system services ssh root-login allow user@R1# set system services telnet user@R1# set routing-options static route 192.168.255.2/32 next-hop 192.168.1.2
Verify and Commit the Configuration at the R1 Device
Step-by-Step Procedure
Complete the following steps to verify and commit your candidate configuration at the R1 device:
-
Confirm interface configuration with the
show interfacesconfiguration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.[edit] user@R1# show interfaces ge-0/0/0 { description "Link from R1 to R2"; unit 0 { family inet { address 192.168.1.1/30; } } } lo0 { unit 0 { family inet { address 192.168.255.1/32; } } } -
Verify the static route used to reach the R2 device’s loopback address and that SSH and Telnet access are enabled. Use the
show routing-optionsandshow system servicesconfiguration mode commands. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.[edit] user@R1# show routing-options static { route 192.168.255.2/32 next-hop 192.168.1.2; } user@R1# show system services ssh { root-login allow; } telnet; -
When satisfied with the configuration on the R1 device, commit your candidate configuration.
[edit] user@R1# commit
Configure the R2 Device
Step-by-Step Procedure
Complete the following steps to configure the R2 device. You begin by defining the stateless firewall filter that selectively blocks Telnet and SSH access:
-
Position yourself at the
edit firewall family inet filterlocal_acl hierarchy:[edit] user@R2# edit firewall family inet filter local_acl
-
Define the filter term terminal_access. This term permits Telnet and SSH from the specified source prefix(s):
[edit firewall family inet filter local_acl] user@R2# set term terminal_access from source-address 192.168.1.0/30 user@R2# set term terminal_access from protocol tcp user@R2# set term terminal_access from port ssh user@R2# set term terminal_access from port telnet user@R2# set term terminal_access then accept
-
Define the filter term terminal_access_denied. This term rejects SSH and Telnet from all other source addresses. This term is configured to log matches to the term and to generate an explicit Internet Control Message Protocol (ICMP) destination unreachable response back to the packet’s source. See Firewall Filter Logging Actions for details on filter logging options.
Tip:You can use the
discardaction to suppress generation of ICMP error messages back to the source. See Firewall Filter Terminating Actions for details.[edit firewall family inet filter local_acl] user@R2# set term terminal_access_denied from protocol tcp user@R2# set term terminal_access_denied from port ssh user@R2# set term terminal_access_denied from port telnet user@R2# set term terminal_access_denied then log user@R2# set term terminal_access_denied then reject user@R2# set term default-term then accept
- Optional.
Define the filter term tcp-estab. This term permits outbound access to the Internet to support connections to the Juniper Mist cloud (tcp-established is a bit-field match condition, tcp-flags "(ack | rst)", which indicates an established TCP session, but not the first packet of a TCP connection):
[edit firewall family inet filter local_acl] user@R2# set term tcp-estab from protocol tcp user@R2# set term tcp-estab from tcp-established user@R2# set term tcp-estab then accept
-
Define the filter term default-term. This term accepts all other traffic. Recall that Junos OS stateless filters have an implicit deny term at their end. The default-term overrides this behavior by terminating the filter with an explicit accept action. The termination of the filter results in all other traffic being accepted by the filer.
Note:For this example we are allowing all other traffic, but for your network you might want to secure the routing engine. See protecting the routing engine for more information.
[edit firewall family inet filter local_acl] user@R2# set term default-term then accept
-
Configure the loopback interface, and apply the filter in the input direction:
[edit] user@R2# set interfaces lo0 unit 0 family inet filter input local_acl user@R2# set interfaces lo0 unit 0 family inet address 192.168.255.2/32
-
Configure the host name, the ge-0/0/0 interface, the static route to the R1 device’s loopback address, and enable remote access through SSH and Telnet:
[edit] user@R2# set system host-name R2 user@R2# set system services ssh root-login allow user@R2# set system services telnet user@R2# set interfaces ge-0/0/0 description "Link from R2 to R1" user@R2# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/30 user@R2# set routing-options static route 192.168.255.1/32 next-hop 192.168.1.1
Verify and Commit the Configuration at Device R2
Step-by-Step Procedure
Complete the following steps to verify and commit your candidate configuration at the R2 device:
-
Confirm the configuration of the stateless firewall filter with the
show firewallconfiguration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.[edit] user@R2# show firewall family inet { filter local_acl { term terminal_access { from { source-address { 192.168.1.0/30; } protocol tcp; port [ssh telnet]; } then accept; } term terminal_access_denied { from { protocol tcp; port [ssh telnet]; } then { log; reject; } } term default-term { then accept; } } } -
Confirm interface configuration and filter application with the
show interfacesconfiguration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.[edit] user@R2# show interfaces ge-0/0/0 { description "Link from R2 to R1"; unit 0 { family inet { address 192.168.1.2/30; } } } lo0 { unit 0 { family inet { filter { input local_acl; } address 192.168.255.2/32; } } } -
Verify the static route used to reach the loopback address of the R1 device, and verify that Telnet and SSH access are enabled. Use the
show routing-optionsandshow system servicesconfiguration mode commands. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.[edit] user@R2# show routing-options static { route 192.168.255.1/32 next-hop 192.168.1.1; } user@R2# show system services ssh { root-login allow; } telnet; -
When satisfied with the configuration on the R2 device, commit your candidate configuration.
Tip:Consider using
commit-confirmedwhen making changes that might affect remote access to your device.[edit] user@R2# commit
Verify the Stateless Firewall Filter
Confirm that the firewall filter to limit Telnet and SSH access is working properly.
Verify Accepted Packets
Purpose
Verify that the firewall filter correctly allows SSH and Telnet when the traffic is sourced from the 192.168.1.0/30 subnet.
Action
-
Clear the firewall log on your router or switch.
user@R2> clear firewall log
-
From a host at an IP address within the 192.168.1.0/30 subnet, use a
ssh 192.168.255.2command to verify that you can log in to the device using SSH from an allowed source address. This packet should be accepted, but the packet header information for this packet should not be logged in the firewall filter log buffer in the Packet Forwarding Engine. You will be prompted to save the SSH host key if this is the first SSH login as user between these devices.Note:By default the R1 device will source the SSH traffic from the egress interface used to reach the destination. As a result this traffic is sourced from the 192.168.1.1 address assigned to the R1 device’s ge-0/0/0 interface.
user@R1>ssh 192.168.255.2 Password: Last login: Wed Aug 19 09:23:58 2020 from 192.168.1.1 --- JUNOS 20.2R1.10 Kernel 64-bit JNPR-11.0-20200608.0016468_buil user@R2>
-
Log out of the CLI at the R2 device to close the SSH session.
user@R2> exit logout Connection to 192.168.255.2 closed. user@R1>
-
From a host at an IP address within the 192.168.1.0/30 subnet, use the
telnet 192.168.255.2command to verify that you can log in to your router or switch using Telnet from an allowed source address. This packet should be accepted, but the packet header information for this packet should not be logged in the firewall filter log buffer in the Packet Forwarding Engine.user@host-A> telnet 192.168.255.2 Trying 192.168.255.2... Connected to 192.168.255.2. Escape character is '^]'. login: user Password: --- JUNOS 20.2R1.10 Kernel 64-bit JNPR-11.0-20200608.0016468_buil user@R2>
-
Log out of the CLI to close the Telnet session to the R2 device.
user@R2:~ # exit Connection closed by foreign host. root@R1>
-
Use the
show firewall logcommand to verify that the firewall log buffer on the R2 device’s Packet Forwarding Engine (PFE) does not contain any entries with a source address in the 192.168.1.0/30 subnet.user@R2> show firewall log
Verify Logged and Rejected Packets
Purpose
Verify that the firewall filter correctly rejects SSH and Telnet traffic that does not originate from the 192.168.1.0/30 subnet.
Action
-
Clear the firewall log on your router or switch.
user@R2> clear firewall log
-
Generate SSH traffic sourced from the loopback address of the R1 device. The source address of this traffic is outside of the allowed 192.168.1.0/30 subnet. Use the
ssh 192.168.255.2 source 192.168.255.1command to verify that you cannot log in to the device using SSH from this source address. This packet should be rejected, and the packet header information should be logged in the firewall filter log buffer.user@R1 ssh 192.168.255.2 source 192.168.255.1 ssh: connect to host 192.168.255.2 port 22: Connection refused root@R1>
The output shows that the SSH connection is rejected. This output confirms that the filter is generating an ICMP error message and that it correctly blocks SSH traffic when sent from a disallowed source address.
-
Generate Telnet traffic sourced from the loopback address of the R1 device. The source address of this traffic is outside of the allowed 192.168.1.0/30 subnet. Use the
telnet 192.168.255.2 source 192.168.255.1command to verify that you cannot log in to the device using Telnet from this source address. This packet should be rejected, and the packet header information for this packet should be logged in the firewall filter log buffer in the PFE.user@R1> telnet 192.168.255.2 source 192.168.255.1 Trying 192.168.255.2... telnet: connect to address 192.168.255.2: Connection refused telnet: Unable to connect to remote host
The output shows that the Telnet connection is rejected. This output confirms that the filter is generating an ICMP error message and that it correctly blocks Telnet traffic when sent from a disallowed source address.
-
Use the
show firewall logcommand to verify that the firewall log buffer on the R2 device contains entries showing that packets with a source address of 192.168.255.1 were rejected.user@R2> show firewall log Log : Time Filter Action Interface Protocol Src Addr Dest Addr 15:17:11 pfe R ge-0/0/0.0 TCP 192.168.255.1 192.168.255.2 15:12:04 pfe R ge-0/0/0.0 TCP 192.168.255.1 192.168.255.2
The output confirms that traffic from the 192.168.255.1 source address matched the filter’s terminal_access_denied term. The
Actioncolumn displays anRto indicate that these packets were rejected. The interface, transport protocol, and source and destination addresses are also listed. These results confirm that the firewall filter is working properly for this example.