New TCPware Packet Filtering - VMS

This is a discussion on New TCPware Packet Filtering - VMS ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: New TCPware Packet Filtering

  1. New TCPware Packet Filtering

    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
    dano@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 | |
    +-------------------------------+----------------------------------------+


  2. RE: New TCPware Packet Filtering

    Please see my responses below, in red.

    BTW,
    Keep up the great work! Between our dedicated firewall and TCPware's
    access list and packet filtering, we have never been touched/infected.

    Darwin Peebles
    Senior Systems Analyst
    ERC Inc.
    NASA, JSC, White Sands Test Facility (WSTF)
    New Phone: 575-524-5619
    New email: Darwin.B.Peebles@nasa.gov

    The views, opinions, and/or statements expressed are my own and do not
    necessarily reflect NASA's or ERC's views, opinions, statements, and/or
    policies.

    Total Recall is wonderful, if you don't get a blank.

    -----Original Message-----
    From: Dan O'Reilly [mailto:dano@process.com]
    Sent: Wednesday, February 06, 2008 12:39 PM
    To: info-tcpware@process.com
    Subject: New TCPware Packet Filtering

    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.
    All components/services/ports that are feasible.

    - 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?
    Destination port level and 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.
    As configurable as feasible.

    - What types of attacks are most common for each component we're looking
    at?
    DOS, browsing/trolling, spoofing.

    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 dano@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 |
    |
    +-------------------------------+---------------------------------------
    -+



+ Reply to Thread