Firewall

Introduction

This document will describe firewall functionalities, their specifications and, in particular, how to use dynamic filtering and intrusion detection functionalities.

Dynamic Filtering

Summary

Conventional filters are said to be "static" because they always operate the same according to settings you define. In static filters, doors for controlling communications are either always open or always closed. Fundamentally, whether a door is open or closed is determined in the settings, and it does not open and close during operations.

On the other hand, in a dynamic filter, the door closes and opens in response to the communications state. Fundamentally, whether a door is open or closed is determined in the settings, and it does not open and close during operations. Specifically, when communications start, the door opens and when communications end the door closes.

Permissions to open a door are limited to specified hosts. For instance, if it's set so that only hosts on the internal network can open the door, it is possible to decrease opportunities for undergoing attacks from external networks. This mechanism is similar to a door without a knob that can only be pushed.

With a dynamic filter, the first packet of the connection has the opportunity to open the door. Once the door is opened, forwarded packets and returned packets pertaining to that connection will be able to pass through. With a static filter you need to set the filter for each direction, forward and return, but in a dynamic filter, merely by writing the direction of the forwarding filter returning packets also will be automatically routed to pass through.

Dynamic filters have operational priority over static filters. That is, after the door for handling a particular connection is open, you will not be able to control the connection with a static filter. Conversely, only the first packet of the connection can be controlled with a static filter. For details, refer to the figure in Static Filter and Dynamic Filter Relationships.

In the following description, a static filter is simply called a static filter. likewise, a dynamic filter is called a dynamic filter. Note that dynamic filters only handle TCP and UDP and not protocols such as ICMP and OSPF.

Terminology

When we simply mention the word connection we mean TCP and UDP connections. Since the terminal will assign a port number for each connection, connections will be identified by the IP address and port number of two terminals (see following figure).

 +-------------+ Port number                     Port number +-------------+
 | Terminal A  | 60000 <-------------------------------> 23  | Terminal B  |
 +-------------+                 connection                  +-------------+
 IP address:  192.168.0.1                          IP address:  192.168.0.2 

Inside an IP packet there is a part that indicates the IP address and port number. Looking at this part, you can find out find out to which connection the individual IP packets pertain. IP addresses are stored in IP headers, and port numbers are stored in TCP or UDP headers behind IP headers.

Depending on the application, a means exists to realize communications with a number of connections. For example, FTP connections are divided between connections for control and for data. In this document, these multiple connections are collectively called a session. Of course, as with SMTP and TELNET, in many sessions there is only one connection.

Observing an FTP session, first a connection is made for control, then a connection for data transfer will be made if necessary. Generally, it often appears that in sessions with multiple connections the first connection is made for control, and this connection is used to administer the rest of the connection uses. We will call the first connection made for control a trigger and treat it specially. In sessions that have only one connection, the connection itself will be the trigger.

(1) Initially, a trigger is created
 +-------------+ Port number                     Port number +-------------+
 | Terminal A  | 60000 <----------  Trigger  ----------> 21  | Terminal B  |
 +-------------+                                             +-------------+
(2) Connection is created as necessary
 +-------------+ Port number                     Port number +-------------+
 | Terminal A  | 60000 <----------  Trigger  ----------> 21  | Terminal B  |
 +-------------+ 60001 <-------------------------------> 20  +-------------+
                 60002 <-------------------------------> 20
                 60003 <-------------------------------> 20

An important concept is the direction of the connection. The direction of a connection is the same as the direction of the request for a connection. For example, when A sends a connection request to B, the orientation of the connection is in the direction of A to B. In a dynamic filter you can apply different access restrictions in response to the direction of the connection.

How is this used?

We will explain here the basic uses as well as learn the operational basics of dynamic filters.

Dynamic Filter Definition

First we will define "dynamic filter." A dynamic filter is simply defined as a "connection that should be passed." The simplest definition, which only mentions communications protocols, is configured by commands such as the following.

# ip filter dynamic 1 * * ftp 

This command defines a dynamic filter for passing a FTP connection. "1" in the command is an identifier of a dynamic filter, and you can set such integers freely. There is no particular need for awareness about connections used for FTP transfer, as data is automatically passed.

When you want to distinguish a communications terminal, you can designate the IP address and network instead of an asterisk "*". For instance, if the terminal that initiates FTP is limited to within 192.168.0.0/24, it can be written as follows.

# ip filter dynamic 1 192.168.0.0/24 * ftp 

Additionally, if the server that connects to the FTP destination is limited to 172.16.0.1, it can be written as follows.

# ip filter dynamic 1 * 172.16.0.1 ftp 

You can also designate other protocols than FTP in the "ftp" space. For example, you can set something like the following. For details, refer to the Command.

  • tftp (TFTP)
  • domain (DNS)
  • pop3 (POP3)
  • smtp (SMTP)
  • telnet (TELNET)

Actually, there are not very many applications that can be set in this way. For instance, ident and SSH cannot be defined in this way. So, we will now explain how to pass other applications.

First, we will note a specific example. One setting consists of two rows as follows.

# ip filter 100 pass * * tcp 10000 20000
# ip filter dynamic 1 192.168.0.1 172.16.0.1 filter 100 

The intent here is to define a TCP connection to port 20000 on 172.16.0.1 from port 10000 on 192.168.0.1.

 +-------------+ Port number                    Port number +-------------+
 | Terminal A  | 10000 -----------------------------> 20000 | Terminal B  |
 +-------------+                                            +-------------+
    IP address:  192.168.0.1                           IP address:  172.16.0.1 

Use the "ip filter" command to separate TCP / UDP and state port numbers. Additionally, use the "ip filter dynamic" command to set the terminal's IP address.

You can use an asterisk to abbreviate ( "*"), just as per the above, For example, the following settings would mean an ident connection between any terminals.

# ip filter 100 pass * * tcp * ident
# ip filter dynamic 1 * * filter 100 

Dynamic Filter Applications

We defined dynamic filters in the previous section and will show you how to actually operate these. To operate a dynamic filter, use the "ip INTERFACE secure filter" command to designate a number for the dynamic filter defined above. For example, to operate a dynamic filter for FTP on the "LAN1" interface, set as follows.

# ip filter dynamic 1 * * ftp
# ip lan1 secure filter out dynamic 1 

The "out" argument here means that the door opens toward the outside of the interface. On the other hand, to open the door to the inside of the interface, designate "in" instead of "out".

To begin with, the "ip INTERFACE secure filter" command has existed from the past, and up to now has been used to apply a static filter. In the new firmware, it becomes possible to apply both static and dynamic filters using this command.

For example, to apply a static filter from No. 1 to 3 and a dynamic filter from 6 to 8, set as follows. The static filter and dynamic filter numbers are separated by the "dynamic" keyword.

ip INTERFACE secure filter in 1 2 3 dynamic 6 7 8 

Additionally, when you only set a dynamic filter, a static filter will not work and only the dynamic filter will operate. That is, note that this means packets will not be discarded at all.

Static Filter and Dynamic Filter Relationships

As a rule, dynamic filters do not function to discard packets but to pass them. In other words, you cannot reject packets with dynamic filters alone. In other words, in normal operations you need to combine dynamic filters with static filters.

Fundamentally, dynamic filters have priority in application over static filters. Thus, packets to which a dynamic filter applies will pass, regardless of the static filter settings. On the other hand, whether packets that do not apply to a static filter will be passed or discarded will be determined by the settings of the static filter.

A dynamic filter does not exist from the start but that is dynamically created when a trigger connection appears. Thus a static filter, rather than a dynamic filter, will be applied only to the first packet of the trigger. Once a dynamic filter is created, thereafter continuing packets will be passed by the dynamic filter.

(1) Initial state (no dynamic filter)
                                              +---------------+ Reject
                                   ---------->| Static filter |--------> Discard      
                                              +---------------+
                                                       |        Receive
                                                       +-------------------> Pass
(2) First packet passes trigger
                                     -->■--> +---------------+ Reject
                                   ---------->| Static filter |--------> Discard      
                                              +---------------+
                                                       |        -->■-->
                                                       +-------------------> Pass
(3) Dynamic filter is added
          +----------------+ Reject           +---------------+ Reject
      --->| Dynamic filter |----------------->| Static filter |--------> Discard
          +----------------+                  +---------------+
                   | Receive                          |        Receive
                   |                                  +-------------------> Pass
                   |
                   +------------------> Pass
(4) Ongoing packets pass
 -->■ ■ +----------------+ Reject           +---------------+ Reject
      --->| Dynamic filter |----------------->| Static filter |--------> Discard      
          +----------------+                  +---------------+
                   |■ Receive                         |        Receive
                   |■                                 +-------------------> Pass
                   |■ ■ ■ ■ ■ ■ ■ -->
                   +-------------------------> Pass

This behavior can be used for all dynamic filter connections. Again, the first packet that triggers the connection needs to pass through the static filter.

We will explain the combination of static and dynamic filters using a specific example. The following network is used as an example here. We assume extremely simple access controls.

                   Provider
                      ⋀
                      |
                      | PP1
               +--------------+
               |    Router    |
               +--------------+
                      | LAN1
                      |
         --------------------------------------------- 172.16.1.0/28
              |             |              |
              |             |              |
           +--------+   +--------+    +------------+
           |  Host  |   |  Host  |    | FTP server | 172.16.1.2
           +--------+   +--------+    +------------+

The LAN has an FTP server, and other than opening this to the public, it does not accept access from outside. Additionally, it passes HTTP as access from the LAN to the outside.

First, set a static filter. For now, let's forget about FTP server, and discard all packets from outside.

# ip filter 100 reject * * * * *
# pp select 1
# ip pp secure filter in 100 

As access from inside, only HTTP is passed. As just explained, only the first packet that triggers the connection needs to pass through the static filter. Then, set up a static filter as follows.

# ip filter 90 pass 172.16.1.0/28 * tcpflag=0x0002/0x0017 * www
# pp select 1
# ip pp secure filter out 90 

The tcpflag part indicates packets that contain only the SYN flag out of the TCP packets. Due to this filter, only the first packet of the connection can pass.

* Due to the revision, there are things that cannot be set with a tcpflag. In that case, you can get a similar effect by dividing into two rows in the following manner.

# ip filter 90 reject 172.16.1.0/28 * established * www
# ip filter 91 pass 172.16.1.0/28 * tcp * www
# pp select 1
# ip pp secure filter out 90 91 

* For UDP, because it is not possible to make judgment with a flag like SYN, it is simply "udp" in the protocol field.

# ip filter 92 pass 172.16.1.0/28 * udp * domain 

Next, add a dynamic filter to allow HTTP to pass. Together with the setting. so far, it will be as follows.

# ip filter 90 pass 172.16.1.0/28 * tcpflag=0x0002/0x0017 * www
# ip filter 100 reject * * * * *
# ip filter dynamic 1 172.16.1.0/28 * www
# pp select 1
# ip pp secure filter in 100
# ip pp secure filter out 90 dynamic 1 

Next, add a filter to open the FTP server to the public. First, add the following static filter to pass the initial packet of the trigger connection.

# ip filter 80 pass * 172.16.1.0/28 tcpflag=0x0002/0x0017 * 21
# pp select 1
# ip pp secure filter in 80 100 

Finally, add a dynamic filter to allow FTP to pass. An overall summary is as follows.

# ip filter 80 pass * 172.16.1.0/28 tcpflag=0x0002/0x0017 * 21
# ip filter 90 pass 172.16.1.0/28 * tcpflag=0x0002/0x0017 * www
# ip filter 100 reject * * * * *
# ip filter dynamic 1 172.16.1.0/28 * www
# ip filter dynamic 2 * 172.16.1.0/28 ftp
# pp select 1
# ip pp secure filter in 80 100 dynamic 2
# ip pp secure filter out 90 dynamic 1 

If you can trust the hosts inside, for tcpflag of the No. 90 filter you can just simply use "tcp".

More Advanced Settings

Definitions of Extended Dynamic Filters

In "Dynamic Filter Definition", we explained that specific applications such as FTP and TELNET can be set in one line and other applications are set separated into two lines. Of these, we will explain about the latter, since there are somewhat extended uses.

As explained before, in general one session will have multiple connections. For instance, with FTP, after a control connection is made a data transfer connection is made. Thus, in order to properly handle this type of session, a trigger setting alone is insufficient and we need to describe and define a connection other than a trigger.

Additionally, because connections in general have directionality, you need to handle connections depending on differences of direction. Thus, to fully represent a session, you will see that the following three items are needed.

  • Trigger (connection that activates session)
  • Connection other than trigger (forward direction)
  • Connection other than trigger (reverse direction)
 +-------------+ Port number                     Port number +-------------+
 | Terminal A  | 60000 <----------  Trigger  ----------> 21  | Terminal B  |
 +-------------+ 60001 <------ forward direction ------> 20  +-------------+
                 60002 <------ reverse direction ------> 20
[Note]

To repeat, for FTP, with respect to data transfer connections, there is no need for user awareness. The router keeps track of which port number FTP is using, and passes the relevant connection.

All connections that belong to one session are considered to be connected between the same terminals. In other words, there should be no difference between the IP address of the trigger and other connections.

We will continue the explanation using specific examples.

  • Trigger is any TCP addressed to port no. 6000 on 172.16.0.1
  • Forward direction connections are any UPD addressed to port no. 7000.
  • Reverse direction connections are any UPD addressed to port no. 8000.

Settings corresponding to these rules are as follows.

# ip filter 10 pass * * tcp * 6000
# ip filter 11 pass * * udp * 7000
# ip filter 12 pass * * udp * 8000
# ip filter dynamic 1 * 172.16.0.1 filter 10 in 12 out 11 

As settings keywords, "in" is for connections in the reverse direction from the trigger and "out " is for connections in the same direction. With the three types of filter numbers, multiple respective filter numbers can be listed.

Registered Application Operations

In "Dynamic Filter Definition", we explained two ways of configuring a dynamic filter. One way is to designate the application name directly and the other is to use the "ip filter" command for setting in two rows. We will explain the former case in this section, in other words, about operation when the application name is designated.

* As of this writing 7 applications can be set: FTP, TFTP, HTTP, DNS, SMTP, POP3 and TELNET.

Most of these applications handle multiple connections and changing port numbers, and need application-specific processing. Thus, by writing the application name in the "ip filter dynamic" command, you explicitly set the specific handling.

* As of now, there is no special handling for HTTP, POP3, and TELNET.

In addition, with the "ip filter dynamic" command you can specify udp and tcp instead of the application name. This is for handling overall UDP and TCP connections and not operations specific to applications.

FTP

Since the connection port number for FTP data transfer is dynamically determined, the PORT and PASV commands are examined and corresponding port number is automatically opened and closed. Connections for data transfer are passed by a dynamic filter, and there is no need for static filters to pass these connections. The only static filter needed by FTP is a filter that passes the initial packets in the connection for control use.

[Example]
# ip filter 10 pass * 192.168.0.0/24 tcpflag=0x0002/0x0017 * 21
# ip filter 100 reject * * * * *
# ip filter dynamic 1 * 192.168.0.0/24 ftp
# pp select 1
# ip pp secure filter in 100
# ip pp secure filter out 10 100 dynamic 1 

TFTP

In TFTP, in some cases the server will respond by choosing an ephemeral port. Thus, we have a mechanism for detecting change of port number for the first packet sent by the server. In addition, with TFTF, because there is the characteristic that only the final data transfer packet is short, the end of the session is determined by seeing this.

Client                     Server

          Session start 

           COMMAND
4000 --------------------------> 69

           ACK
4000 <-------------------------- 7000

           DATA (len = 512)
4000 --------------------------> 7000

           ACK
4000 <-------------------------- 7000
               ·
               ·
               ·
           DATA (len < 512)
4000 --------------------------> 7000

           ACK
4000 <-------------------------- 7000 

           Session end 

DNS

Because DNS uses a set of query and response, end of session is determined by viewing responses. The port number for DNS is 53.

SMTP

Although there is no direct relationship with dynamic filter, this will detect specific attacks on SMTP. For details, refer to Intrusion Detection. The port number for SMTP is 25.

Status Display

Use the "show ip connection" command to see state of the dynamic filter. First, when no connection at all is observed, the following will display.

pp1# show ip connection
PP[01][out]
  inspecting no sessions 

Next, when the session has only one connection the following will display.

pp1# show ip connection
PP[01][out]
  ID       FILTER   T P INITIATOR             D RESPONDER             S
  60001    1          T 192.168.1.2:1073      > 192.168.2.2:21        E 

The meanings of banner parts such as ID and FILTER are as follows.

ID Session ID number
FILTER Applicable dynamic filter number
T Connection type (stated later)
P Protocol (TCP or UDP)
INITIATOR IP address of node that started session.
D Session direction
RESPONDER IP address of node that received session.
S Connection status

Like with FTP, when one session consists of multiple connections, the following will display. The primary difference is display of ID and T (type). ID is displayed in the format of the session ID linked to the connection ID. In addition, in the T (type), the connection that becomes a catalyst to open the door is shown as "T" , and other connections are represented by a "D".

pp1# show ip connection
PP[01][out]
  ID       FILTER   T P INITIATOR             D RESPONDER             S
  60001-1  1        T T 192.168.1.2:1073      > 192.168.2.2:21        E
  60001-2  1        D T 192.168.1.2:1077      < 192.168.2.2:20        E 

TCP connection status is shown in the "S" field. Nothing is shown regarding UDP connections. The meanings of shown symbols are as follows.

  • S ... State until connection is established from sending of connection request.
  • R ... State until connection is established from receiving of connection request.
  • E ... State of connection being established.
  • F ... State of connection being terminated.

In transient states not included in the above states no symbols are shown.

Syslog Output

When a connection is ended, a summary of the connection will be output as syslog at the notice level.

2001/01/31 18:21:00: [INSPECT] PP[01][out][1] TCP 192.168.1.2:1077 < 192.168.2.2:20 (2001/01/31 18:20:48)
2001/01/31 18:21:05: [INSPECT] PP[01][out][1] TCP 192.168.1.2:1073 > 192.168.2.2:21 (2001/01/31 18:20:14) 

In the final brackets the time and date when connection began are expressed.

Additionally, with the "ip filter dynamic" command, when you set the "syslog" option to off, such a summary will no longer be displayed.

Linking with NAT

Using a dynamic filter, you can dynamically pass connections that start from outside. However, when using IP masquerading it is not possible to dynamically pass a connection that starts from outside, so the significance of dynamic filters diminishes.

So, when using a dynamic filter in combination with IP masquerading, we have prepared a mechanism for dynamically changing the static IP masquerade table and passing connections from the outside.

The table created at such time is a dynamic table and only exists during the interval between the start and end of the connection. Thus, like when a server is opened to the public, it there is a need to open and keep open the same port all the time, just as in the past, it is necessary to set up a static IP masquerade.

The following could serve as an example. This is a setting where the trigger is a TCP connection to No. 6000 and if a trigger is detected in a UDP connection to No. 7000, in the same direction as the trigger, and a UDP connection to No. 8000, in the reverse direction of the trigger, will pass.

nat descriptor type 1 masquerade
ip filter 10 pass * * tcp * 6000
ip filter 11 pass * * udp * 7000
ip filter 12 pass * * udp * 8000
ip filter dynamic 1 * 192.168.0.128 filter 10 in 12 out 11
ip pp nat descriptor 1
ip pp secure filter in dynamic 1 

At this time, for the trigger, because it's always necessary to wait while opening a port, you need to set up a static masquerade as follows.

nat descriptor masquerade static 1 1 192.168.0.128 tcp 6000 

As UDP connections addressed to port no. 7000 are connections that connect from the inside to the outside, through normal IP masquerade processing a table is automatically added. In short, there is no need for be aware of this connection, limited just with respect to dynamic filters.

For connections addressed to port no. 8000, there is no need to pass constantly, and there is no need to set up a static IP masquerade. As for this connection, rather than the user, the router changes the table automatically.

Let's summarize as follows.

  • As for trigger connections, set up a static IP masquerade and pass.
  • Other than triggers, for NAT connections from inside to outside, tables are added through NAT processing.
  • Other than triggers, for NAT connections from inside to outside, tables are added through dynamic filter processing.

In short, the user need note just one point, that to pass triggers, set up static IP masquerading.

Other Functionalities

A functionality is provided for manually disconnecting connections. To use this connection, execute the "disconnect ip connection" command.

For instance, to disconnect a session on port 60000, enter the following.

# disconnect ip connection 60000 

To discontinue a specified connection associated with a session, designate the session number and the connection number.

# disconnect ip connection 60001 1 

Other Points to be Noted

As for static filters, where multiple filters are applicable to a packet the handling is that only the filter that the packet matches is applicable, and as for dynamic filters as well, only the filter that the packet matches first is handled as applicable.

For one interface, the maximum number of sessions that can be administered is as follows. Depending on the model and firmware the maximum number is fixed, and the maximum number cannot be changed in settings, etc.

Model Maximum number
RTX5000 65534
RTX810 10000

Intrusion Detection

Summary

This functionality is to detect and notify the user when packets are received that have the goal of intrusion or attack. However, it is difficult to determine whether an intrusion is applicable or not, and one should note that perfect detection is impossible.

Intrusion and attacks are detected by comparing patterns of illegal packets (signatures). Basically, the process compares patterns at the packet level and other than this there are checks implemented based on connection status and attacks with such status as port scan.

How is this used?

This functionality operates using information administered by dynamic filters as explained in "Dynamic Filtering". For this purpose, the maximum effect is displayed through combination use of dynamic filters. For instance, if a dynamic filter is set for SMTP, based on that information, unauthorized access involving SMTP will be detected. Conversely, if no dynamic filter is set, unauthorized access to SMTP is not detected.

On the other hand, like with IP headers and ICMP, packets not handled by dynamic filters operate with no relation to the existence of dynamic filter settings. Additionally, TCP and UDP as well will fundamentally function even if no dynamic filters are defined. A later section will explain this in detail.

So, setting of dynamic filters to detect unauthorized access is meaningless. In the first place, for unauthorized access, it shouldn't be necessary to detect intrusion, so the first priority should be placed on configuration of dynamic filters. Therefore you must avoid setting dynamic filters to detect unauthorized access.

If you still want to detect unauthorized access, you can set up a dynamic filter to permit the applicable access and then reject unauthorized access based on the result of intrusion detection. However, there is the problem that, due to false detection of unauthorized access the problem arises of attacks being able to pass and packets that are not attacks being discarded.

To detect unauthorized access, set the "ip INTERFACE intrusion detection" command. For example, when detecting traffic in the direction entering the LAN1 interface, set as follows.

ip lan1 intrusion detection in on 

In addition, you can designate the "reject" option for setting whether to discard invalid packets. The default "reject" option is "off". Note that the "reject" option is not necessarily effective against all attacks.

[Example]
ip lan1 intrusion detection in on reject=on

Decision Criteria

Decision criteria are summarized in the following table. In the table a black star mark "★" indicates that it will not operate without a dynamic filter being set. For example, when there is a black star "★" in the type category for SMTP, as per the below, these will be detected when a dynamic filter has been set to pass to SMTP.

ip filter dynamic 1 * SNMP_SERVER smtp
ip lan1 secure filter in dynamic 1
ip lan1 intrusion detection in on 

A white star mark "☆" indicates those that can be detected without enabling the intrusion detection, as long as a dynamic filter is configured. When an attack has been detected, discarding will occur without fail, regardless of the setting.

In addition, a black triangle "▲" indicates an attack with high risk level and with a low probability of being falsely detected, and where the effects of discarding are minimal. For this attack, discarding will occur without fail, regardless of the setting. On the other hand, a white triangle indicates things that will not be discarded, regardless of the setting.

A white circle "○" indicates something that is not specially handled as it is also detected under the earlier revision. When these attacks are detected, they will be discarded without fail.

Models Names Judgment criteria
IP header Unknown IP protocol When protocol field is 143 and above
Land attack When source IP address and destination IP address are the same
Short IP header When IP header length is shorter than the length of the "length" field
Malformed IP packet When the length field and actual packet length are different
IP options header Malformed IP opt When options header is malformed
Security IP opt When security and handling restriction header is received
Loose routing IP opt When loose source routing header is received
Record route IP opt When record route header is received
Stream ID IP opt When stream identifier header is received
Strict routing IP opt When strict source routing header is received
Timestamp IP opt When Internet timestamp header is received
Fragments Fragment storm When a large volume of fragments is received
Large fragment offset When fragment offset field is large
Too many fragment When there are too many fragment parts
Teardrop When undergoing an attack by a device such as a teardrop ☆▲
Same fragment offset When fragment offset field value is duplicated
Invalid fragment When other fragments with that cannot be reassembled are received ☆▲
ICMP ICMP source quench When source quench is received
ICMP timestamp req When timestamp request is received
ICMP timestamp reply When timestamp reply is received
ICMP info request When information request is received
ICMP info reply When information reply is received
ICMP mask request When address mask request is received
ICMP mask reply When address mask reply is received
ICMP too large When ICMP larger than 1025 bytes is received
UDP UDP short header Length field of UDP packet is less than 8.
UDP bomb When value of UDP header length field is too large
UDP port scan When a port scan is detected
TCP TCP queue overflow When TCP packet cue has become long
TCP no bits set When nothing is set in flag
TCP SYN and FIN When SYN and FIN are set to simultaneous
TCP FIN and no ACK When FIN is received without ACK
TCP port scan When a port scan is detected
TCP SYN flooding When large volume of SYN is received at a certain time
FTP FTP improper port When port No. designated with PORT and PASV commands are not within the range of 1024~65535
SMTP SMTP pipe attack When "|" pipe is included in header such as From:
SMTP decode alias When ": decode@" is included in header
SMTP DEBUG command When DEBUG command is received
SMTP EXPN command When EXPN command is received
SMTP VRFY command When VRFY command is received
SMTP WIZ command When WIZ command is received
Winny Winny version 2 When Winny ver. 2 connection had been discovered (*1)
Share Share version 1 When Share ver.1 connection has been discovered (*2)

*1 Only models that support Winny detection and rejection (Winny Filter) functionality.

*2 Only models that support the Share filter functionality.
Related documents: Share Filter

Handling Ongoing Attacks

When same attack continues on an ongoing basis, detected information is limited in history. First, if the same type of attack is repeated against the same target, a record will be left in syslog every 60 seconds. In addition, even though types of attack may differ, attacks on the same target will be limited to once per second.

Display of Attack History

Use the "show ip intrusion detection" command to see a history of attacks undergone. A maximum of 50 attacks can be displayed for each direction for each interface. Portions in excess of this are deleted in order of oldest first.

Attack Notification

When attack is undergone it will output to syslog at notice level.

Other Points to be Noted

Note that the intrusion detection function is to complement but not replace static filters. Some attacks can be effectively defended with static filters.

Additionally, it is important to combine dynamic filters, static filters and intrusion detection. For example, the following settings are in effect when an SMTP server is open to the public,.

ip filter 11 reject * SMTP_SERVER established * smtp
ip filter 12 pass * SMTP_SERVER tcp * smtp
ip filter dynamic 1 * SMTP_SERVER smtp
pp select 1
ip pp secure filter in 11 12 dynamic 1
ip pp intrusion detection in on reject=on 

Command

Define a Dynamic Filter

[Syntax]
ip filter dynamic DYN_FILTER_NUM SRCADDR DSTADDR PROTOCOL [OPTION ...]
ip filter dynamic DYN_FILTER_NUM SRCADDR DSTADDR filter FILTER_LIST [in FILTER_LIST] [out FILTER_LIST] [OPTION ...] 
[Setting Value]
  • DYN_FILTER_NUM ... Dynamic filter number (1..21474836)
  • SRCADDR ... Source IP address
  • DSTADDR ... Destination IP address
  • MASK ... Bit mask for IP address (can be specified only when SRC_ADDR and DEST_ADDR are network addresses)
  • PROTOCOL ... Protocol mnemonic
    • echo/discard/daytime/chargen/ftp/ssh/telnet/smtp/time/whois/dns/domain/dhcps/
    • dhcpc/tftp/gopher/finger/http/www/pop3/sunrpc/ident/nntp/ntp/ms-rpc/
    • netbios_ns/netbios_dgm/netbios_ssn/imap/snmp/snmptrap/bgp/imap3/ldap/
    • https/ms-ds/ike/rlogin/rwho/rsh/syslog/printer/rip/ripng/
    • dhcpv6c/dhcpv6s/ms-sql/netmeeting/radius/l2tp/pptp/nfs/msblast/ipsec-nat-t/sip/
    • ping/ping6/tcp/udp
  • FILTER_LIST ... List of filter numbers registered by the "ip filter" command
  • OPTION
    • syslog=SWITCH
      • on ... Keep the communication log of the connection in SYSLOG
      • off ... Not keep the communication log of the connection in SYSLOG
    • timeout=TIME
      • time ... Number of seconds until the connection information is released after the data stops flowing
[Initial Value]
  • syslog=on
[Description]

Defines a dynamic filter. In the first syntax, an application name registered in the router in advance is specified.
In the second syntax, the user specifies the access control rules. Following the keywords filter, in, and out, set a filter number defined by the "ip filter" command.
If a connection (trigger) that corresponds to the filter specified after the filter keyword is detected, subsequent connections that correspond to the filter specified after the in keyword and out keyword are passed. The in keyword controls accesses in the reverse direction to the trigger direction, and the out keyword controls accesses in the same direction as the dynamic filter. The IP address in the "ip filter" command is ignored. The pass/reject parameter is also ignored.
If tcp or udp is specified for the protocol, filtering specific to an application is not carried out. If a certain application must be handled, specify the application name.

[Example]
# ip filter 10 pass * * udp * snmp
# ip filter dynamic 1 * * filter 10
[Applicable Models]
RTX5000 RTX810 FWX120

Set the Security by Filtering

[Syntax]
ip INTERFACE secure filter DIRECTION [FILTER_LIST...] [dynamic FILTER_LIST...]
no ip INTERFACE secure filter DIRECTION [FILTER_LIST]
[Setting Value]
  • INTERFACE ... LAN interface name, WAN interface name, loopback interface name, null interface name, or Bridge interface name
  • DIRECTION
    • in ... Filtering of received packets
    • out ... Filtering of packets to be transmitted
  • FILTER_LIST ... Ordering of white-space separated file numbers (The total number of static and active filters is up to 300 for RTX5000. It is up to 128 for all other models.)
  • dynamic ... Specify the dynamic filter number immediately after the keyword
[Description]

Limits the type of packets that pass the interface by combining packet filters specified by the "ip filter" command.

In the syntax that specifies a direction, the filter sequence applied to each direction is specified by filter numbers. The specified filters are applied in order, and when a filter that matches the packet is found, that filter determines whether the packet is passed or discarded. Subsequent filters are not applied. Packets that do not meet any of the filters are discarded.

[Note]

The filter list is scanned. When a match is found, the relevant filter determines whether the packet is passed or discarded.

# ip filter 1 pass 192.168.0.0/24 *
# ip filter 2 reject 192.168.0.1
# ip lan1 secure filter in 1 2

In this setting, packets whose source IP address is 192.168.0.1 are not checked by filter 2, because filter 1 determines that the packet is to be passed. Therefore, filter 2 carries no meaning.
Packets that do not match any of the filters in the filter list are discarded.

If RADIUS authentication is used in PP anonymous and the Access-Response sent from the RADIUS server contains the 'Filter-Id' attribute, the filter set specified by the value is applied, and the settings of the "ip pp secure filter" command are ignored.
If the 'Filter-Id' attribute does not exist, the settings of the "ip pp secure filter" command are used as the filter.
Dynamic filtering cannot be used with a loopback or null interface.
You cannot set DIRECTION to 'in' for a null interface.

RTX810 supports bridge interface for INTERFACE parameter in Rev.11.01.23 or later.
RTX5000 does not support WAN interface for INTERFACE parameter.

[Applicable Models]
RTX5000 RTX810 FWX120

Set the Dynamic Filter Timeout

[Syntax]
ip filter dynamic timer OPTION=TIMEOUT [OPTION=TIMEOUT...]
no ip filter dynamic timer
[Setting Value]
  • OPTION ... Option name
    • tcp-syn-timeout
      ... Drop the session if a connection is not established within the specified time after receiving SYN
    • tcp-fin-timeout
      ... Release the connection if the specified time elapses after receiving FIN
    • tcp-idle-time
      ... Drop the connection if no TCP connection data flows within the specified time
    • udp-idle-time
      ... Drop the connection if no UDP connection data flows within the specified time
    • dns-timeout
      ... Drop the connection if no response is received within the specified time after receiving a DNS request
  • TIMEOUT ... Wait time (seconds)
[Initial Value]
  • tcp-syn-timeout=30
  • tcp-fin-timeout=5
  • tcp-idle-time=3600
  • udp-idle-time=30
  • dns-timeout=5
[Description]

Sets the dynamic filter timeout.

[Note]

This setting is used in common in all checks.

[Applicable Models]
RTX5000 RTX810 FWX120

Show the Connections Managed by Dynamic Filters

[Syntax]
show ip connection [INTERFACE [DIRECTION] [IP_ADDRESS]] 
[Setting Value]
  • INTERFACE ... LAN or WAN interface name
  • DIRECTION
    • in ... Input direction
    • out ... Output direction
  • IP_ADDRESS ... IP address xxx.xxx.xxx.xxx (where xxx is a decimal number)
[Description]

The connections managed by dynamic filters will be displayed with specified interface. In case of without interface option, all information of every interface is displayed.

On RTX5000, in case of without detail option, the managed connections which is aggregated by each source IP address are displayed. In case of without interface option, all information of every interface is displayed.
If detail is not specified, the connections managed by dynamic filters will be displayed as a summary of each originating IP address. However, if IP_ADDRESS has been specified, the source address from the information specified in detail will be displayed as the results of IP_ADDRESS.

[Note]

"show ip connection" detail command is available on the RTX5000 models.
"show ip connection" command as a summary of each originating IP address is available on the RTX5000 models.
RTX5000 does not support WAN interface for INTERFACE parameter.
IP_ADDRESS can be specified on the RTX5000 models.

[Applicable Models]
RTX5000 RTX810 FWX120

Delete the Connection Management Information of the Dynamic IPv4 Filter

[Syntax]
disconnect ip connection SESSION_ID [CHANNEL_ID]
[Setting Value]
  • SESSION_ID ... Session ID
  • CHANNEL_ID ... Channel ID
[Description]

Deletes a specified channel belonging to the specified session. If the channel is not specified, all channels belonging to the session are deleted.

[Applicable Models]
RTX5000 RTX810 FWX120

Set the Operation of the Intrusion Detection Function

[Syntax]
ip INTERFACE intrusion detection DIRECTION [TYPE] SWITCH [OPTION]
no ip INTERFACE intrusion detection  DIRECTION [TYPE] SWITCH [OPTION]
[Setting Value]
  • INTERFACE ... LAN or WAN interface name
  • DIRECTION ... Packet connection direction to be monitored
    • in ... Into the interface
    • out ... Out of the interface
  • TYPE ... Packet connection type to be monitored
    • ip ... IP header
    • ip-option ... IP option header
    • fragment ... Fragment
    • icmp ... ICMP
    • udp ... UDP
    • tcp ... TCP
    • ftp ... FTP
    • winny ... Winny
    • share ... Share
    • default ... All unspecified types
  • SWITCH
    • on ... Enable
    • off ... Disable
  • OPTION
    • reject=on ... Discards invalid packets
    • reject=off ... Not discard invalid packets
[Initial Value]
  • SWITCH
    • When TYPE is not specified=off
    • When TYPE is specified=on
  • OPTION
    • off
[Description]

Detects intrusion in packets of the specified direction on the specified interface.
When the "type" option is omitted, the settings apply to all types of intrusion detection.

[Note]

For high-risk attacks, the router always discards the packet regardless of the reject option setting.

Concerning Winny, the version 2 can be detected, but no other previous versions are covered.

Concerning Share, the version 1.0 EX2 (Share TCP version) can be detected, but no other previous versions are covered.
RTX5000 does not support WAN interface for INTERFACE parameter.

[Applicable Models]
RTX5000 RTX810 FWX120

Show the History of Intrusion Information

[Syntax]
show ip intrusion detection
show ip intrusion detection INTERFACE [DIRECTION]
show ip intrusion detection pp [PEER_NUM [DIRECTION]]
show ip intrusion detection tunnel [TUNNEL_NUM [DIRECTION]]
[Setting Value]
  • INTERFACE ... LAN or WAN interface name
  • PEER_NUM ... Peer number
  • TUNNEL_NUM ... Tunnel interface number
  • DIRECTION
    • in ... Input direction
    • out ... Output direction
[Description]

Shows the recent intrusion information. Intrusion information is shown for each direction of each interface. The maximum number of incidents that are shown is the value specified by following commands.

  • ip INTERFACE intrusion detection report
  • ip pp intrusion detection report
  • ip tunnel intrusion detection report
[Note]

RTX5000 does not support WAN interface for INTERFACE parameter.

[Applicable Models]
RTX5000 RTX810 FWX120

Set the Frequency of Intrusion Detection Notifications in a Second

[Syntax]
ip INTERFACE intrusion detection notice-interval FREQUENCY
no ip INTERFACE intrusion detection notice-interval 
[Setting Value]
  • INTERFACE ... LAN or WAN interface name
  • FREQUENCY ... Frequency (1...1000)
[Initial Value]
  • FREQUENCY
    • 1
[Description]

Sets the frequency of intrusion detection notifications in a second.

[Note]

RTX5000 does not support WAN interface for INTERFACE parameter.

[Applicable Models]
RTX5000 RTX810 FWX120

Control the Repeated Intrusion Detection Notifications

[Syntax]
ip INTERFACE intrusion detection repeat-control TIME
no ip INTERFACE intrusion detection repeat-control 
[Setting Value]
  • INTERFACE ... LAN or WAN interface name
  • TIME ... Number of seconds (1..1000)
[Initial Value]
  • TIME
    • 60
[Description]

Controls the notifications so that the same type of intrusions against a host is notified only once per the number of seconds specified by "time".

[Note]

RTX5000 does not support WAN interface for INTERFACE parameter.

[Applicable Models]
RTX5000 RTX810 FWX120

Set the Number of Maximum Displayed Notifications of the Intrusion Detection

[Syntax]
ip INTERFACE intrusion detection report NUM
no ip INTERFACE intrusion detection report 
[Setting Value]
  • INTERFACE ... LAN or WAN interface name
  • NUM ... Number of notifications (1..1000)
[Initial Value]
  • NUM
    • 50
[Description]

Sets the number of intrusion detection notifications that are displayed by the "show ip intrusion detection" command.

[Note]

RTX5000 does not support WAN interface for INTERFACE parameter.

[Applicable Models]
RTX5000 RTX810 FWX120

Set the Intrusion Detection Threshold Value

[Syntax]
ip INTERFACE intrusion detection threshold TYPE COUNT
no ip INTERFACE intrusion detection threshold TYPE 
[Setting Value]
  • INTERFACE ... LAN or WAN interface name
  • TYPE ... Intrusion type for setting the threshold value
    • port-scan. ... Port scan
    • syn-flood ... SYN flood
  • COUNT ... Threshold value (1..65535)
[Initial Value]
  • TYPE
    • port-scan=64
    • syn-flood=100
[Description]

Sets the threshold value used by the intrusion detection. The meaning of the intrusion type and the specified threshold value are as follows:

  • port-scan ... If the COUNT types of different ports are accessed within a second on the same host, the router determines that it is a port scan.
  • syn-flood ... If the number of detected SYN packets within a second is greater than or equal to COUNT against the same host, the router determines that it is a SYN flood.
[Note]

RTX5000 does not support WAN interface for INTERFACE parameter.

[Applicable Models]
RTX5000 RTX810 FWX120

Return to Top