Dan O'Reilly
2008-05-21 18:46:26 UTC
As we're progressing towards beta for MultiNet V5.3 (no, there's no
specific date yet), we're looking for prospective beta testers that will be
able to do more extensive, specific, testing on the new packet filtering
features for MN 5.3, in addition to being a general MN 5.3 beta tester.
First of all, some 5.3 filtering background. There are two ways to set
filters: the traditional method of creating a text file of filter
definitions (IPV6 is now supported as well as IPV4) that get loaded into
the MN kernel via MULTINET SET/INTERFACE/FILTER, and a new automated method
of setting filters based on events reported by various components (e.g.,
SSH and ftp), very much like a firewall. We'll focus specifically on the
automated filtering.
Automated filtering is made up of several components:
- FILTER_SERVER.EXE - this accepts events reported by various components,
munching on the data per parameters supplied by each component when it
registers with the server. It maintains rulesets and lists of events, and
when limits are reached, creates and sets filters in the MN kernel to
filter that traffic. All of these operating parameters such as the
definition of a rule, the number of events/unit time to trigger a filter,
the duration of a filter, etc are all defined in a configuration file
constructed for the component. The configuration files provide the system
manager with a method to set up the filtering parameters that are
appropriate for his system. The filter server is started when MultiNet starts.
Events are recorded per address per rule per component. Events "age"; in
other words, after a time period, old events are discarded from the list of
events so that infrequent event occurrences (e.g., fat-fingering a
password) won't inadvertently cause a filter to be logged.
Multiple triggers for a filter can happen for a component. The purpose of
this is to make a filter progressively longer. For example, the first
filter for a rule might be 5 minutes long, the next, 10 minutes long, the
next, 15 minutes long, etc, up to 5 filter times. The list of filters must
be terminated by a -1, which says "leave this filter in place permanently
until the filter is deleted or the system is rebooted".
When a filter is set on an interface, it may be set such that it blocks all
traffic for the specified protocol family and source address (e.g., all UDP
traffic from a specific source address) or so that it blocks only traffic
for a specific destination port (e.g., blocking only traffic from a
specific source address to the local IMAP port). This behavior is
controlled by configuration parameters.
Controlling the execution of the filter server is done via the new MultiNet
commands MU SET/FILTER and MU SHOW/FILTER. This interface allows the
system manager to start/stop/restart the filter server, and it can tell the
filter server to report its current state to a text file. The information
can be used by a system manager to determine what events are being reported
and if the correct filters are being set.
- FILTER_SERVER_API.OLB - This contains the routines used by a component
that allow it to register with the filter server and to send events to
it. Note that this interface is documented and will be available for
customer-written applications as well as for Process Software-supplied
MultiNet components.
- The addition to MULTINET SHOW/INTERFACE of the /EXTRACT_FILTER=<filename>
qualifier, as in:
MU SHOW/INTERFACE SE0/EXTRACT_FILTERS=X.TXT
This extracts the filters in the kernel in the same "human" format they
would be if the system manager created them by hand, then loaded them using
MU SET/INTERFACE/FILTER. The reason for doing this is if an incorrect
filter was added, the system manager can retrieve all the active filters,
fix the one in question, then reload all the filters back into the kernel
without losing any.
Now for instrumenting a component. The first thing to be done is to
determine 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. Next, for each rule, you need to
determine, among other things:
- the number of events/unit time that will trigger a filter
- the duration of a filter
- how more strict each filter is.
All of this information goes into a configuration file that's specific to
the component (this is covered in the filtering documentation).
Now that we've gone through the background stuff, what we're looking for is
for people who can test this and provide feedback on the correct
configuration for the filters (reporting times, counts, etc) up to and
including having the correct rulesets defined. We anticipate having SSH,
FTP, POP3, IMAP and SNMP set up for the initial beta release, and possibly
more components as we go along and can identify a need. If a beta tester
wants to use the API to instrument their own application, we will work with
them as needed (although the beta documentation will have the new
filtering, including the API, completely documented).
Please let us know if you have interest in testing this feature.
------
+-------------------------------+----------------------------------------+
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
+-------------------------------+----------------------------------------+
specific date yet), we're looking for prospective beta testers that will be
able to do more extensive, specific, testing on the new packet filtering
features for MN 5.3, in addition to being a general MN 5.3 beta tester.
First of all, some 5.3 filtering background. There are two ways to set
filters: the traditional method of creating a text file of filter
definitions (IPV6 is now supported as well as IPV4) that get loaded into
the MN kernel via MULTINET SET/INTERFACE/FILTER, and a new automated method
of setting filters based on events reported by various components (e.g.,
SSH and ftp), very much like a firewall. We'll focus specifically on the
automated filtering.
Automated filtering is made up of several components:
- FILTER_SERVER.EXE - this accepts events reported by various components,
munching on the data per parameters supplied by each component when it
registers with the server. It maintains rulesets and lists of events, and
when limits are reached, creates and sets filters in the MN kernel to
filter that traffic. All of these operating parameters such as the
definition of a rule, the number of events/unit time to trigger a filter,
the duration of a filter, etc are all defined in a configuration file
constructed for the component. The configuration files provide the system
manager with a method to set up the filtering parameters that are
appropriate for his system. The filter server is started when MultiNet starts.
Events are recorded per address per rule per component. Events "age"; in
other words, after a time period, old events are discarded from the list of
events so that infrequent event occurrences (e.g., fat-fingering a
password) won't inadvertently cause a filter to be logged.
Multiple triggers for a filter can happen for a component. The purpose of
this is to make a filter progressively longer. For example, the first
filter for a rule might be 5 minutes long, the next, 10 minutes long, the
next, 15 minutes long, etc, up to 5 filter times. The list of filters must
be terminated by a -1, which says "leave this filter in place permanently
until the filter is deleted or the system is rebooted".
When a filter is set on an interface, it may be set such that it blocks all
traffic for the specified protocol family and source address (e.g., all UDP
traffic from a specific source address) or so that it blocks only traffic
for a specific destination port (e.g., blocking only traffic from a
specific source address to the local IMAP port). This behavior is
controlled by configuration parameters.
Controlling the execution of the filter server is done via the new MultiNet
commands MU SET/FILTER and MU SHOW/FILTER. This interface allows the
system manager to start/stop/restart the filter server, and it can tell the
filter server to report its current state to a text file. The information
can be used by a system manager to determine what events are being reported
and if the correct filters are being set.
- FILTER_SERVER_API.OLB - This contains the routines used by a component
that allow it to register with the filter server and to send events to
it. Note that this interface is documented and will be available for
customer-written applications as well as for Process Software-supplied
MultiNet components.
- The addition to MULTINET SHOW/INTERFACE of the /EXTRACT_FILTER=<filename>
qualifier, as in:
MU SHOW/INTERFACE SE0/EXTRACT_FILTERS=X.TXT
This extracts the filters in the kernel in the same "human" format they
would be if the system manager created them by hand, then loaded them using
MU SET/INTERFACE/FILTER. The reason for doing this is if an incorrect
filter was added, the system manager can retrieve all the active filters,
fix the one in question, then reload all the filters back into the kernel
without losing any.
Now for instrumenting a component. The first thing to be done is to
determine 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. Next, for each rule, you need to
determine, among other things:
- the number of events/unit time that will trigger a filter
- the duration of a filter
- how more strict each filter is.
All of this information goes into a configuration file that's specific to
the component (this is covered in the filtering documentation).
Now that we've gone through the background stuff, what we're looking for is
for people who can test this and provide feedback on the correct
configuration for the filters (reporting times, counts, etc) up to and
including having the correct rulesets defined. We anticipate having SSH,
FTP, POP3, IMAP and SNMP set up for the initial beta release, and possibly
more components as we go along and can identify a need. If a beta tester
wants to use the API to instrument their own application, we will work with
them as needed (although the beta documentation will have the new
filtering, including the API, completely documented).
Please let us know if you have interest in testing this feature.
------
+-------------------------------+----------------------------------------+
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
+-------------------------------+----------------------------------------+