Dan O'Reilly
2008-02-06 19:38:53 UTC
At Process, we're putting more work and effort into enhancing security of
our products by enhancing packet filtering capabilities that already exist
in TCPware and MultiNet. It should be noted that what we're NOT attempting
to do is to create a comprehensive firewall; rather, we intend to enhance
our products to make them more resistant to some types of Denial-of-Service
attacks and breakin attacks such as "dictionary attacks". In recent
releases, we've done a fair amount of background work on this, and now we
need to look at specifics to be implemented.
As we move onto the next phase, for a set of components, we're looking at
detecting an attack then telling the MultiNet or TCPware kernel to add a
packet filter with a limited lifetime to stem and/or completely halt the
attack. The final phase will be to incorporate kernel-level attack
detection (for example, responding to SYN flood DOS attacks). This will be
in a release sometime in the future.
When dealing with components, for example: SSH determines a
dictionary-style attack is underway, because it's identified a large number
of invalid username attempts from the same system. SSH tells the kernel to
put up a filter for, say, 3 minutes, then 10 minutes if the attacks
continue, then 2 hours if they still continue (the times are all arbitrary
to this discussion).
Why a packet filter in the kernel? It's because this is by far the most
efficient place to drop this traffic; the alternative would be to allow the
connection to SSHD_MASTER to be made, then an SSHD server is spawned, then
it finally determines the user is fake. Dropping a single (or multiple)
packets at the kernel level is MUCH more efficient.
Some of the questions we're looking at right now:
- What components? At this point, we've identified several components:
SSH, telnet, ftp, IMAP and POP.
- At what granularity do we want to set a filter? At the originating
system level (where all traffic from the offending system would be blocked)
or the destination port level (where all traffic destined, for example, the
SSH port would be blocked but all other traffic from that system would be
allowed)? Would you want this to be configurable?
- How configurable would you want a ruleset to be? For example, would you
want to be able to set a rule on a dictionary attack to be triggered
(events over a time period) differently on different systems, or even
differently on different components on a given system? Note that we don't
want to get overly complex here. At this point, I don't think we'll have
user-defined rulesets available in terms of being able to define rules
outside the standard set we will provide.
- What types of attacks are most common for each component we're looking at?
What we're looking for is your input. Please DO NOT respond with specific
security issues, that may contain company-specific or proprietary details
in them, to this general forum; rather, respond to me privately at
***@process.com.
------
+-------------------------------+----------------------------------------+
| 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 | |
+-------------------------------+----------------------------------------+
our products by enhancing packet filtering capabilities that already exist
in TCPware and MultiNet. It should be noted that what we're NOT attempting
to do is to create a comprehensive firewall; rather, we intend to enhance
our products to make them more resistant to some types of Denial-of-Service
attacks and breakin attacks such as "dictionary attacks". In recent
releases, we've done a fair amount of background work on this, and now we
need to look at specifics to be implemented.
As we move onto the next phase, for a set of components, we're looking at
detecting an attack then telling the MultiNet or TCPware kernel to add a
packet filter with a limited lifetime to stem and/or completely halt the
attack. The final phase will be to incorporate kernel-level attack
detection (for example, responding to SYN flood DOS attacks). This will be
in a release sometime in the future.
When dealing with components, for example: SSH determines a
dictionary-style attack is underway, because it's identified a large number
of invalid username attempts from the same system. SSH tells the kernel to
put up a filter for, say, 3 minutes, then 10 minutes if the attacks
continue, then 2 hours if they still continue (the times are all arbitrary
to this discussion).
Why a packet filter in the kernel? It's because this is by far the most
efficient place to drop this traffic; the alternative would be to allow the
connection to SSHD_MASTER to be made, then an SSHD server is spawned, then
it finally determines the user is fake. Dropping a single (or multiple)
packets at the kernel level is MUCH more efficient.
Some of the questions we're looking at right now:
- What components? At this point, we've identified several components:
SSH, telnet, ftp, IMAP and POP.
- At what granularity do we want to set a filter? At the originating
system level (where all traffic from the offending system would be blocked)
or the destination port level (where all traffic destined, for example, the
SSH port would be blocked but all other traffic from that system would be
allowed)? Would you want this to be configurable?
- How configurable would you want a ruleset to be? For example, would you
want to be able to set a rule on a dictionary attack to be triggered
(events over a time period) differently on different systems, or even
differently on different components on a given system? Note that we don't
want to get overly complex here. At this point, I don't think we'll have
user-defined rulesets available in terms of being able to define rules
outside the standard set we will provide.
- What types of attacks are most common for each component we're looking at?
What we're looking for is your input. Please DO NOT respond with specific
security issues, that may contain company-specific or proprietary details
in them, to this general forum; rather, respond to me privately at
***@process.com.
------
+-------------------------------+----------------------------------------+
| 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 | |
+-------------------------------+----------------------------------------+