This chapter describes the MultiNet Intrusion Prevention System (IPS). IPS is implemented by instrumenting components (e.g, MultiNet SSH or FTP, or even user-supplied components) with a Process Software supplied API that allows them to report events, such as invalid login attempts, to the FILTER_SERVER process. The filter server, started when MultiNet starts, maintains the component rulesets and lists of events, based on the originating address for the offending connection, and when defined limits are reached, creates and sets timed filters in the MultiNet kernel to filter that traffic.
All of the operating parameters such as the definition of rule, the number of events/unit time to trigger a filter, the duration of a filter, etc. are all defined by component configuration files.
Events are recorded per source address, per rule, per destination address, per component. This provides the ability to have differing filtering criteria for different interfaces (for example, an internal network vs. an external network). Addresses or networks may be excluded from consideration when an event is logged. This feature allows, for example, different settings to be used for internal vs. external networks.
Events "age"; after a time period, old events are discarded from the list of events so that infrequent event occurrences (e.g., mistyping a password) have less chance of inadvertently causing a filter to be set. Note that when a filter is triggered for an address and rule, the list of known events for that rule and address are deleted.
Multiple filters may be set in sequence for a component/rule/source address/destination address as events are logged. The purpose of this is to make a filter progressively longer. For example, the first filter set for an address and rule might be 5 minutes long; the next, 10 minutes long; the next, 15 minutes long; etc., up to 5 filter times.
The filter server is configured using a main configuration file and per-component configuration files. The main configuration file is used to set overall configuration options for filter server operation, while the per-component configuration files contain configuration information for each instrumented component such as the ruleset to use, the prototype filter to be set, etc. Per-component configuration files are referenced by the main configuration file by using the "INCLUDE" keyword.
Sample configuration files are supplied in the MultiNet distribution and must be copied and modified as necessary to conform to the particular site’s security profile and interface configuration. These files are copied to the MULTINET directory when MultiNet is installed. Once these have been copied and modified, the filter server configuration may be reloaded via the MULTINET SET/IPS/RELOAD command. The template files supplied are:
FILTER_SERVER_CONFIG.TEMPLATE
SSH_FILTER_CONFIG.TEMPLATE
IMAP_FILTER_CONFIG.TEMPLATE
POP3_FILTER_CONFIG.TEMPLATE
SNMP_FILTER_CONFIG.TEMPLATE
SMTP_FILTER_CONFIG.TEMPLATE
TELNET_FILTER_CONFIG.TEMPLATE
REXEC_FILTER_CONFIG.TEMPLATE
RSHELL_FILTER_CONFIG.TEMPLATE
RLOGIN_FILTER_CONFIG.TEMPLATE
The following table lists the main configuration file keywords. These are found in the file MULTINET:FILTER_SERVER_CONFIG.TXT:
Table 31-3 Main configuration Keywords
The per-component configuration files are loaded using the INCLUDE keyword in the main filter server configuration file. Each of these configuration files have the following format. The definition must begin with a COMPONENT keyword. Comments lines begin with a "#" character.
COMPONENT component-name
DESTINATION_ADDRESS
EXCLUDE_ADDRESS
DESTINATION_PORT
PROTO_FILTER
RULE rulename
DESTINATION_ADDRESS
DESTINATION_PORT
MAX_COUNT
DELTA_TIME
FILTER_DURATIONS
RULE rulename
MAX_COUNT
DELTA_TIME
FILTER_DURATIONS
Each component may have as many rules defined for it as are appropriate for the component. However, the more rules defined for a component, the more complex it may be to instrument the component to actually report those rules. All entries in configuration files are not case-sensitive.
The following table shows the keywords for a per-component configuration file:
Table 31-4 Per-Component Configuration Keywords
#=========================================================================
#
# FILTER_SERVER_CONFIG.TEMPLATE
#
#=========================================================================
#
# The following parameter determines the level of debug information
# written to the debug log file. This should normally be set to a
# value of 2 or less, and shouldn't be set above 4 without the
# recommendation of Process Software, as higher debug levels will
# negatively impact the filter server (and possibly, system)
# performance. The debug messages will be found in the file
# MULTINET:FILTER_SERVER.OUT.
#
debug 4
#
# The following parameters define the logging locations. Note
# that debug messages are not written to the logging locations.
#
# The first two parameters are used when logging to a log file.
#
logfile multinet:filter_logfile.log
log_to_logfile yes
#
# The next parameter is used when logging to OPCOM.
#
log_to_opcom yes
opcom_target NETWORK,SECURITY,OPER3
#
# The next parameters are used when logging via SNMP. Details
# on the values for enterprise_string, generic_trap_id and
# specific_trap_id can be found in chapter 23 of the MultiNet
# Administrators Guide.
#
log_to_snmp no
# enterprise_string
# generic_trap_id
# specific_trap_id
#
# The following parameter determines how filters are created. If
# set to YES, then the destination port field is added to the filter
# (e.g., "192.168.0.11/32 eq 22"). If set to NO, then no source
# port field is added, which will cause the filter to block all
# traffic of the specified protocol from the source address. If
# not set, default is NO.
#
# block_at_destination_port yes
#
#=========================================================================
#
# The following lines defihe the individual configuration files
# for each configured component that uses the filter server
#
#=========================================================================
#
include multinet:ftp_filter_config.txt
include multinet:imap_filter_config.txt
include multinet:pop3_filter_config.txt
include multinet:smtp_filter_config.txt
include multinet:snmp_filter_config.txt
include multinet:ssh_filter_config.txt
#
For this configuration:
• Debug will be reported at level 4 (this produces fairly detailed information, normally useful only by Process Software when debugging a problem).
• Log messages will be logged to MULTINET:FILTER_LOGFILE.LOG and OPCOM.
• When filters are logged, the destination port specified in the per-configuration files will be used.
• Per-component configuration files for the MultiNet FTP, IMAP, POP3, SMTP, SNMP and SSH servers will be loaded.
The following is a configuration file for the SSH component:
component ssh
proto_filter "deny tcp 192.168.0.100/32 192.168.0.11/24 log"
destination_address 192.168.0.16/24
exclude_address 192.168.0/24
destination_port 22
rule ssh_bogus_id
max_count 10
delta_time 90
filter_durations 300,600,1800,3600,-1
rule ssh_authfailed
max_count 10
delta_time 90
filter_durations 300,600,1800,3600,-1
rule ssh_authfailed
destination_address 192.168.10.2/16
max_count 10
delta_time 90
filter_durations 300,600,1800,3600,-1
rule ssh_userauth
max_count 10
delta_time 90
filter_durations 300,600,1800,3600,-1
rule ssh_invaliduser
max_count 10
delta_time 90
filter_durations 300,600,1800,3600,-1
For component SSH, a "deny tcp" filter will be used. The source address/mask and destination address/mask parts of the prototype filter are ignored and are overwritten by the actual data specified by the source information gathered from the event that triggered the filter, and by the destination address/mask/port information specified by the corresponding keywords in this file. Events from the 192.168.0 network are all excluded from being counted.
To examine the first three rules specified above:
The rule is "ssh_bogus_id". Since no address or mask is specified for this rule, it will use the default destination address of 192.168.0.16 and mask of 255.255.255.255 specified at the beginning of the component configuration. The rule states that if 10 events from the same source address are seen over 90 seconds, a filter is created using the proto_filter specified above. The first filter is 5 minutes long, the second, 10 minutes, and so on, until at the 5th time, a permanent filter is put in place for the address and interface that is causing the problem.
The second rule is "ssh_authfailed", and applies to events received as a result of connections on the interface with the default address of 192.168.0.16 and mask of 255.255.255.0, respectively.
The third rule is also "ssh_authfailed", but applies to events received a result of connections on the interface with the address 192.168.10.2, using a mask of 255.255.0.0. The max_count and delta_time parameters are different for this interface than for the previous ssh_authfailed rule in the system.
The remaining rules for this component will use the default address 192.168.0.16 and mask of 255.255.255.0.
Note! If a rule specifies a destination address for an interface which does not currently exist, events for that interface will be dropped until the interface becomes available.
If your system has multiple interfaces (for example, SE0, SE1 and PD0), you must specify all interfaces in the same per-component configuration file. For each rule in the config file, you must supply a separate section for each destination address (i.e., interface). The component keyword may occur exactly once in the configuration file. The following example shows a config file for component ftp for 4 interfaces (SE0, PD0, PD1, PD2):
=======================================================================
#
# FTP_FILTER_CONFIG.TXT
#
# Filter server configuration file for the FTP component.
#
#=======================================================================
component ftp
proto_filter "deny tcp 192.168.0.100/32 192.168.0.1/24 log"
destination_port 21
#
# For SE0:
#
rule ftp_invaliduser
max_count 10
delta_time 300
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.29/32
rule ftp_userauth
max_count 21
delta_time 180
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.29/32
rule ftp_authfailed
max_count 21
delta_time 90
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.29/32
rule ftp_timeout
max_count 21
delta_time 90
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.29/32
#
# For PD0:
#
rule ftp_invaliduser
max_count 10
delta_time 300
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.28/32
destination_port 1521
rule ftp_userauth
max_count 21
delta_time 180
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.28/32
destination_port 1521
rule ftp_authfailed
max_count 21
delta_time 90
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.28/32
destination_port 1521
rule ftp_timeout
max_count 21
delta_time 90
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.28/32
destination_port 1521
#
# For PD1:
#
rule ftp_invaliduser
max_count 10
delta_time 300
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.27/32
exclude_address 192.168.0.0/24
rule ftp_userauth
max_count 21
delta_time 180
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.27/32
exclude_address 192.168.0.0/24
rule ftp_authfailed
max_count 21
delta_time 90
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.27/32
exclude_address 192.168.0.0/24
rule ftp_timeout
max_count 21
delta_time 90
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.27/32
exclude_address 192.168.0.0/24
#
# For PD2:
#
rule ftp_invaliduser
max_count 10
delta_time 300
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.21/32
rule ftp_userauth
max_count 21
delta_time 180
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.21/32
rule ftp_authfailed
max_count 21
delta_time 90
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.21/32
rule ftp_timeout
max_count 21
delta_time 90
filter_durations 300,600,1800,3600,-1
destination_address 192.168.0.21/32
The above example shows some configuration options for the system with 4 interfaces. Specifically:
• A default port of 21 was been specified for all interfaces. However, interface PD0 has specified a port of 1521, so that port will be used for PD0 only. All other interfaces will use the default port of 21.
• Interface PD1 has an exclude_address specified for net 192.168.0.0/24. All events for PD1 that originated from that source net will be excluded from being counted by IPS. All other interfaces will count events from that network.
When a filter is set for an address/rule/destination/component, an informational message will appear either in OPCOM (if LOG_TO_OPCOM is set) or in the logfile (if LOG_TO_LOGFILE is set). The following message illustrates an OPCOM message, but the message to a logfile will have the same format.
TWEET_$
%%%%%%%%%%% OPCOM 16-MAY-2008 10:33:19.74 %%%%%%%%%%%
Message from user SYSTEM on TWEET
FILTER_SERVER: Filter queued on se0 (192.168.0.16) at 16-MAY-2008 10:33:19.74
Component: ssh, Rule: ssh_bogus_id
deny tcp 192.168.0.11/32
192.168.0.0/24 eq 22
FLTSVR,LOG
START: 16-MAY-2008 10:33:19 END: 16-MAY-2008 10:38:19
TWEET_$
This message is in essentially the same format as that when a MULTINET SHOW/INTERFACE/FILTER command is performed:
TWEET_$ mu show/interface se0/filter
Device se0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,D2>
VMS Device = EWA0
IP Address = 192.168.0.16
No common links defined
MultiNet Packet Filter List for se0:
Logging is disabled
Source Address / Port
Action Proto Hits Destination Address / Port
------ ----- ----- ------------------------------------------
deny tcp 0 192.168.0.11/32
192.168.0.0/24 eq 22
FLTSVR,LOG
START: 16-MAY-2008 10:33:19 END: 16-MAY-2008 10:38:19
permit ip 13484 0.0.0.0/0
0.0.0.0/0
FLTSVR
Average 0 bytes out, 0 bytes in per second
Average 0 packets out, 0 packets in per second
TWEET_$
Note the second filter (the "permit ip" filter) that is shown. If there are currently no filters set for an interface when the filter server determines it needs to set a filter, it will add an explicit "permit ip" filter. This is done because the existence of any filter in a list of filters causes MultiNet to act as if a "deny everything" filter terminates the list. The "permit ip" filter will essentially prevent that problem from happening.
When logging a filter via SNMP, the configuration keywords ENTERPRISE_STRING, GENERIC_TRAP_ID, and SPECIFIC_TRAP_ID must be specified (as well as the keyword LOG_TO_SNMP). In addition, the SNMP configuration file must be properly set up on the MultiNet system as specified in chapter 23 of the MultiNet Installation and Administrator’s Guide.
When a filter is logged, the following fields will be reported:
FILTER_SERVER: Filter queued on <interface> (<address>) at <time>
COMPONENT=component-name
RULE=rulename
ACTION=actionname (e.g., "deny")
PROTOCOL=protocol (e.g., "TCP")
SOURCE=source address in CIDR format
SOURCE_PORT= operator port (e.g., "EQ 22")
DESTINATION=destination address in CIDR format
DEST_PORT=operator port (e.g., "EQ 22")
START=VMS absolute time
END=VMS absolute time
If a filter is inadvertently created by the filter server, the system manager should first correct the configuration problem (if one exists) that allowed the filter to be incorrectly set. Then, the system manager may retrieve the current list of filters in "manual filter form" that can be edited then reloaded onto the interface. The list is retrieved via the MU SHOW/INTERFACE/EXTRACT_FILTER command. For example:
TWEET_$ mu show/int se0/filt
Device se0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,D2>
VMS Device = EWA0
IP Address = 192.168.0.16
No common links defined
MultiNet Packet Filter List for se0:
Logging is disabled
Source Address / Port
Action Proto Hits Destination Address / Port
------ ----- ----- ------------------------------------------
deny tcp 0 192.168.0.11/32
192.168.0.0/24 eq 22
FLTSVR,LOG
START: 16-MAY-2008 10:33:19 END: 16-MAY-2008 10:38:19
deny tcp 15 192.168.0.38/32
192.168.011/24 eq 22
permit ip 13484 0.0.0.0/0
0.0.0.0/0
FLTSVR
Average 0 bytes out, 0 bytes in per second
Average 0 packets out, 0 packets in per second
TWEET_$ mu show/interface se0/extract_filter=filter.txt
TWEET_$ type filter.txt
#
# FILTER.TXT
#
# Generated 16-MAY-2008 10:51:31
#
#=======================================================================
deny tcp 192.168.0.100/32 192.168.0.11/24 eq 22 start "16-MAY-2008 10:33:19" end "16-MAY-2008 10:38:19"LOG
deny tcp 192.168.0/32.192.168.0.11/24
permit ip 0.0.0.0/32 0.0.0.0/32
TWEET_$ <edit to remove the first (filter) line>
TWEET_$ mu set/interface se0/filter=filter.dat
TWEET_$ mu show/interface se0/filt
Device se0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,D2>
VMS Device = EWA0
IP Address = 192.168.0.16
No common links defined
MultiNet Packet Filter List for se0:
Logging is disabled
Source Address / Port
Action Proto Hits Destination Address / Port
------ ----- ----- ------------------------------------------
deny tcp 15 192.168.0.38/32
192.168.011/24 eq 22
permit ip 13484 0.0.0.0/0
0.0.0.0/0
Average 0 bytes out, 0 bytes in per second
Average 0 packets out, 0 packets in per second
TWEET_$
The IMAP, POP3 and SMTP servers referred to in the configuration template files above refer to the MultiNet servers only. Beginning with PMDF V6.4, PMDF has been instrumented to use IPS. The following PMDF template files are available in the PMDF_TABLE directory:
FILTER_SERVER_PMDF_IMAP.TEMPLATE
FILTER_SERVER_PMDF_POP3.TEMPLATE
FILTER_SERVER_PMDF_SMTP.TEMPLATE
These files should be copied to MULTINET:*.TXT and modifed as appropriate for your installation. Edit MULTINET:FILTER_SERVER_CONFIG.TXT to add INCLUDE lines for these component files, and comment out the INCLUDE lines for the standard MultiNet IMAP, POP and SMTP files.
Next, make sure the appropriate PMDF images are installed. The legacy IMAP and POP servers (PMDF_EXE:IMAPD.EXE and PMDF_EXE:POP3D.EXE) are already installed. The msgstore IMAP and POP servers (PMDF_EXE:IMAP_SERVER.EXE, PMDF_EXE:POP_SERVER.EXE), as well as the SMTP server (PMDF_EXE:TCP_SMTP_SERVER.EXE) are not installed, so they will need to be added to your PMDF_COM:PMDF_SITE_STARTUP.COM file if your PMDF installation uses them. These must all be installed using the /OPEN qualifier.
At this point, define the logical name PMDF_DO_FILTER_SERVER to 1, using the /SYSTEM qualfier (this can be put in PMDF_COM:PMDF_SITE_STARTUP.COM as well).
Finally, restart IPS via the MULTINET SET/IPS/RESTART command.
Note! Note: the PMDF_TABLE:FILTER_SERVER_PMDF_POP3.TEMPLATE file as distributed in PMDF V6.4 has the incorrect port number of 143 specified. Make sure port 110 is specified in this file.
The filter server is started at system startup time. However, it can be controlled using the MULTINET SET/IPS command. The valid commands and their uses are:
Table 31-5 Filter Server Control Commands
|
Command |
Description |
|
/DEBUG_LEVEL=level |
Change the debug level for the server. See the description for the debug main configuration keyword. |
|
/RELOAD |
Re-read and parse the configuration files. Note that this will not wipe out existing event and rule information; it will simply update it so no potential filter information will be lost. |
|
/RESTART |
Stop and restart the filter server. All existing event and rule information will be lost and reloaded from the configuration files. |
|
/START |
Start the filter server if it’s not already running. |
|
/STOP |
Stop the filter server from running. All existing event and rule information will be lost. |
The current configuration of the filter server may also be displayed using the MULTINET SHOW/IPS /CONFIG=<filename> command. For example:
$ multinet show/ips/config=server_stats.out
$ type server_stats.out
Filter server snapshot
Debug level 6
Block at destination port or system: PORT
Log to: OPCOM SNMP trap
Component ssh
Rule ssh_bogus_id
dest address: 192.168.0.16/32
interface: se0
max event count: 10
delta time: 0 00:01:30.00
filter durations: 300 600 1800 3600 -1
Address 192.168.0.11/32
number of still-queued events: 1
number of filters created: 0
Address entry to be deleted: N/A
Event
event time: 29-APR-2008 10:00:12.41
expires: 29-APR-2008 10:01:42.41
Rule ssh_authfailed
dest address: 192.168.0.16/32
interface: se0
max event count: 10
delta time: 0 00:01:30.00
filter durations: 300 600 1800 3600 -1
Rule ssh_userauth
dest address: 192.168.0.16
interface: se0
max event count: 10
delta time: 0 00:01:30.00
filter durations: 300 600 1800 3600 -1
Rule ssh_invaliduser
dest address: 192.168.0.16/32
interface: se0
max event count: 10
delta time: 0 00:01:30.00
filter durations: 300 600 1800 3600 -1
Rule ssh_invalid_id_msg
dest address: 192.168.0.16/32
interface: se0
max event count: 5
delta time: 0 00:02:00.00
filter durations: 300 600 1800 3600 -1
The following files are associated with the filter server:
MULTINET:FILTER_SERVER_HOURLY_LOG.yyyymmdd
This file is an hourly activity log for the filter server. The file extension changes daily at midnight to reflect the current day. What follows is a sample log segment for one hour:
Filter server hourly snapshot for hour 2 of 05/18/2008
Component ssh
Rule ssh_bogus_id
number of hits 0
Rule ssh_authfailed
number of hits 0
Rule ssh_userauth
number of hits 0
Rule ssh_invaliduser
number of hits 2
Address 192.168.0.10/32
number of still-queued events: 0
number of all events: 0
number of filters created: 1
Address entry to be deleted: 18-MAY-2008 05:55:45.35
Address 192.168.0.204
number of still-queued events: 0
number of all events: 2
number of filters created: 0
Address entry to be deleted: 18-MAY-2008 06:22:03.97
This log is showing that during the hour 01:00-02:00, 2 different source addresses were being tracked by the filter server.:
The first address (192.168.0.10) had a filter created sometime in the last 4 hours (the time it takes an address to have no activity before its records are deleted by the filter server). The log indicates the address entry is to be deleted in 3 hours if there is no more activity; therefore, the filter was actually set in the previous hour (looking at the previous hour’s entry in the log file will confirm this).
The second address (192.168.0.204) had 2 events during the hour that never triggered a filter and were deleted after they aged. This address entry is scheduled to be deleted in 4 hours if there’s no more activity for it.
MULTINET:FILTER_SERVER_CONFIG.TXT
This is the main filter server configuration file. Optionally, the server will use the logical name FILTER_SERVER_CONFIG to determine the name of the main configuration file.
MULTINET:FILTER_SERVER.OUT
This file contains any output resulting from starting the filter server (e.g., the output from any DCL commands executed to start it) and all debug messages.
When instrumenting an application (aka, a component), there are several steps to be followed:
• The user determines the component-specific parameters. These include:
• The prototype filter to be used when a filter is created. This is the same format as that used when using a filter file. All filter features are supported, with the exception of the ESTABLISHED and REPEATING keywords. Note that the source address/mask/port and destination address/mask/port fields of the filter will be overwritten during creation of the filter, according to the other parameters set in the configuration file.
• Whether the filters created will block at the destination port or simply block all traffic from the source system (the BLOCK_AT_DESTINATION_PORT keyword).
• The logging to be used.
• The user determines the ruleset:
• The user determines what rules are to be supported. There's no limit on the number of rules the filter server can maintain; the limit is really on how complex you want to make the component.
• For each rule, you need to determine:
• The name of the rule. This string (maximum length 35 characters) will be used by the filter server and by the call to the filter server API call send_filter_event.
• The number of events/unit time that will trigger a filter (the MAX_COUNT and DELTA_TIME fields).
• The duration(s) of a filter. Up to 5 may be chosen, and the list must end with -1.
• The user creates the component-specific configuration file, then adds a reference to it via the INCLUDE keyword in the main filter server configuration file. At this point, the filter server can be made aware of this new (or updated) configuration by using the MULTINET SET /IPS/RELOAD command.
Note! The filter server configuration may be reloaded multiple times without causing problems for the filter server.
There are two calls available in the filter server API. The function prototypes are defined in MULTINET_COMMON_ROOT:[MULTINET.INCLUDE]FILTER_SERVER_API.H. The first call is used to register with the filter server:
int filter_server_register(char *component, 0, 0)
where
component is the name of the component
The remaining two arguments are there for future expansion, and are ignored, but must be specified.
The return values from this function are 1 (success) or 0 (an error occurred; most likely, this is because the filter server isn’t running). Normally this function is called once when the first event is logged. However, if an error is returned, it may be called again when additional events are logged.
Note! The application that's registering MUST be an installed image, using /OPEN or /SHARED. It doesn't need to be installed with privileges. This is an attempt to help cut down on bogus applications registering with the server; it takes a conscious effort by the system manager to do this and therefore, to control this.
The next function is used to format and send events to the filter server:
int send_filter_event(char *rule,
char *source_address,
u_short source_port,
char *dest_address)
where
rule is the name of the rule to be enforced. This must correspond to a rule keyword specified in the per-component configuration file for the component. If a match cannot be made, the event will be ignored by the filter server.
source_address is the address of the system that caused the event to be logged (e.g, "192.168.0.1"). This may be in ipv4 or ipv6 format, but must be of the same address family as that of the destination_address specified for the component in the per-component configuration file. Note that this is an address only. Do not specify address mask bits (e.g., "192.168.0.1/24") with it.
source_port is the source port on the originating system.
dest_address is the destination address of the socket used to communicate to source_address. This information may be obtained by performing a getsockname function on the socket. Note that this is an address only. Do not specify address mask bits (e.g., "192.168.0.11/24") with it.
To include these routines in your application, link using the library MULTINET_COMMON_ROOT:[MULTINET.LIBRARY]FILTER_SERVER_API.OLB.
The following is an example of code used to send events to the filter server:
void ssh_send_filter_event(int code, char *addr, int port, char *dest_addr)
{
char *rule;
static int filter_server = -1;
if (filter_server == -1)
filter_server = filter_server_register("SSH", 0, 0);
if (!filter_server)
return;
switch(code)
{
case LGI$_NOSUCHUSER:
case LGI$_NOTVALID:
rule = "SSH_INVALIDUSER";
break;
case LGI$_USERAUTH:
rule = "SSH_USERAUTH";
break;
case LGI$_DISUSER:
case LGI$_ACNTEXPIR:
case LGI$_RESTRICT:
case LGI$_INVPWD:
case LGI$_PWDEXPIR:
rule = "SSH_AUTHFAILED";
break;
default:
printf("Unrecognized status code %d", code));
return;
}
send_filter_event(rule, addr, (unsigned short)port, dest_addr);
}
