Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configure a Filter to Block Telnet and SSH Access

 

Requirements

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.

Note

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/24 subnet. The filter is applied to the loopback interface to ensure that only traffic destined to the local device is impacted. 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-address IPv4 match condition applied in the input direction.

  • To match packets destined for the Telnet port and SSH ports, you use the protocol tcp match condition combined with a port telnet and port ssh IPv4 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/24. Both devices have loopback addresses assigned from the 192.168.255.0/24 prefix using a /32 subnet mask. Static routes provide reachability between loopback addresses as an interior gateway protocol is not configured in this basic example.

Figure 1: Example Topology
 Example Topology

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.

Caution

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. It’s recommended 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

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 commit from configuration mode to activate the changes.

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 from configuration mode to activate the changes.

Tip

Consider using commit-confirmed when making changes that might impact remote access to your device. See Activating a Junos OS Configuration but Requiring Confirmation for details.

Configure the R1 Device

Step-by-Step Procedure

Follow these steps to configure the R1 device:

  1. Configure the interfaces:

  2. Configure the host name and static route to the R2 device’s loopback address. You also configure Telnet and SSH access:

Verify and Commit the Configuration at the R1 Device

Step-by-Step Procedure

Follow the below steps to verify and commit your candidate configuration at the R1 device:

  1. Confirm interface configuration with the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

  2. 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-options and show system services configuration mode commands. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

  3. When satisfied with the configuration on the R1 device, commit your candidate configuration.

Configure the R2 Device

Step-by-Step Procedure

Follow the below steps to configure the R2 device. You begin by defining the stateless firewall filter that selectively blocks Telnet and SSH access:

  1. Position yourself at the edit firewall family inet filter local_acl hierarchy:

  2. Define the filter term terminal_access. This term permits Telnet and SSH from the specified source prefix(s):

  3. 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 discard action to suppress generation of ICMP error messages back to the source. See Firewall Filter Terminating Actions for details.

  4. 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. This results in all other traffic being accepted by the filer.

  5. Configure the loopback interface and apply the filter in the input direction:

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

Verify and Commit the Configuration at Device R2

Step-by-Step Procedure

Follow the below steps to verify and commit your candidate configuration at the R2 device:

  1. Confirm the configuration of the stateless firewall filter with the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

  2. Confirm interface configuration and filter application with the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

  3. Verify the static route used to reach the loopback address of the R1 device and that Telnet and SSH access are enabled. Use the show routing-options and show system services configuration mode commands. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

  4. When satisfied with the configuration on the R2 device, commit your candidate configuration.

    Tip

    Consider using commit-confirmed when making changes that might impact remote access to your device. See Activating a Junos OS Configuration but Requiring Confirmation for details.

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/24 subnet.

Action

  1. Clear the firewall log on your router or switch.
    user@R2> clear firewall log
  2. From a host at an IP address within the 192.168.1.0/24 subnet, use a ssh 192.168.255.2 command to verify that you can log in to the device using SSH from an allowed source address. This packet should be accepted, and 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
  3. Logout out of the CLI at the R2 device to close the SSH session.
    user@R2> exit
  4. From a host at an IP address within the 192.168.1.0/24 subnet, use the telnet 192.168.255.2 command to verify that you can log in to your router or switch using Telnet from an allowed source address. This packet should be accepted, and 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
    login: user
  5. Logout out of the CLI to close the Telnet session to the R2 device.
    user@R2:~ # exit
  6. Use the show firewall log command 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/24 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/24 subnet.

Action

  1. Clear the firewall log on your router or switch.
    user@R2> clear firewall log
  2. 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/24 subnet. Use the ssh 192.168.255.2 source 192.168.255.1 command 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

    The output shows the SSH connection is rejected. This confirms the filter is generating an ICMP error message, and that it correctly blocks SSH traffic when sent from a disallowed source address.

  3. 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/24 subnet. Use the telnet 192.168.255.2 source 192.168.255.1 command 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

    The output shows the Telnet connection is rejected. This confirms the filter is generating an ICMP error message, and that it correctly blocks Telnet traffic when sent from a disallowed source address.

  4. Use the show firewall log command to verify that the firewall log buffer on the R2 device contains entries showing packets with a source address of 192.168.255.1 have been rejected.
    user@R2> show firewall log

    The output confirms that traffic from the 192.168.255.1 source address has matched the filter’s terminal_access_denied term. The Action column displays an R to indicate these packets were rejected. The interface, transport protocol, and the source and destination addresses are also listed. These results confirm the firewall filter is working properly for this example.