[fw-wiz] Cyberguard and filtering of FTP on non-standard ports.

From: LE CORVIC Y InfoEdpEtcDep (Yoann.Le-Corvic@socgen.com)
Date: 03/10/03

  • Next message: Bill Royds: "Re: [fw-wiz] An article from Peter Tippett/TruSecure..."
    From: LE CORVIC Y InfoEdpEtcDep <Yoann.Le-Corvic@socgen.com>
    To: "'firewall-wizards" <firewall-wizards@honor.icsalabs.com>
    Date: Mon, 10 Mar 2003 13:50:01 +0100
    

    Hi all,

    I have a question concerning filtering FTP on non standard ports.

    I want to allow access to an FTP server behind a Cyberguard, but this server
    is listening on high ports (for exemple 2021, 2020).
    I wanted to know if it is possible to configure this firewall to handle
    "intelligent filtering" of FTP communication (PORT command monitoring or
    PASV command pmonitoring), on ports other that 20 and 21. Any ideas would be
    appreciated.

    Thanks

    -----Message d'origine-----
    De : Paul D. Robertson [mailto:proberts@patriot.net]
    Envoyé : lundi 10 mars 2003 04:22
    À : Chuck Swiger
    Cc : 'firewall-wizards
    Objet : Re: [fw-wiz] An article from Peter Tippett/TruSecure...

    On Sun, 9 Mar 2003, Chuck Swiger wrote:

    > Date: Sun, 09 Mar 2003 13:49:08 -0500
    > From: Chuck Swiger <chuck@codefab.com>
    > To: 'firewall-wizards <firewall-wizards@honor.icsalabs.com>
    > Subject: [fw-wiz] An article from Peter Tippett/TruSecure...

    [Disclaimer: I work for TruSecure, Dr. Tippett is both our CTO and the
    person I report directly to. Since you didn't comment on the article,
    I'll take a swipe at the tradtional dogma as we tend to see it...]

    >
    >
    http://www.globe.com/dailyglobe2/068/business/A_patch_for_IT_security_strate
    gy+.shtml
    >
    > A brief excerpt:
    >
    > "For years, the focus of most security efforts has been centered on
    > identifying and then fixing vulnerabilities in technology. The
    > prevailing belief is that if a hole is found in the IT armor of an
    > organization, it should be fixed immediately before it can be exploited
    > by some cyber-deviant. While this approach sounds logical and
    > effective, it is actually the beginning of a vicious cycle that occupies
    > vast amounts of time and wastes several millions of corporate,
    > government, and consumer dollars every year."

    The point that Peter's making is that chasing vulnerabilities just because
    they exist isn't efficient, nor really achievable. There were ~2200-2400
    new vulnerabilites announced last year, and as near as I can tell,
    between 1 and 2% of those new vulnerabilities got exploited at real
    companies.

    That means that if you spent time patching say an applicable 70% of those
    vulnerabilities, then 68% of that time was wasted.

    It's purely a risk funciton- and if you have good data on which small
    percentage of new vulnerabilities are going to be exploited and which ones
    have historically been exploited, then you can reduce your risk by
    about the same ammount by patching let's say 5% of those vulnerabilities
    instead of every one.

    That saves you 65% of the maintenance, fixes, "patch breaks things" and all
    the associated change control stuff. If you pay folks overtime, or
    give comp. time for staying late to patch, those can go down significantly
    too- *especially* if you have protections in place that limit damage from a
    particular vector for long enough between vulnerability disclosure,
    exploit coding and a normal maintenance cycle.

    Proactive security beats reactive security every time. Patch upon
    vulnerability release is reactive. Things like firewalls and conservative
    machine configuration can reduce patching levels for attacks from likely
    vectors without negatively changing an organization's risk profile.
    Indeed, there's an argument that if people spend more time on the likely
    vulnerabilities, they'll be able to better-protect an organization than if
    they spend time patching every possible vulnerability.

    I've got excellent data for widespread worms like SQL/Slammer and NIMDA,
    and a good feel for the results of target of choice attacks. That risks
    putting this too far into the "sounds like a commercial" mode though, so
    I'll just leave it at "smart risk-based patching beats blanket patching
    for effieciency with little measurable change in risk."

    Paul
    ----------------------------------------------------------------------------
    -
    Paul D. Robertson "My statements in this message are personal opinions
    proberts@patriot.net which may have no basis whatsoever in fact."
    probertson@trusecure.com Director of Risk Assessment TruSecure Corporation

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
    *************************************************************************

    Ce message et toutes les pièces jointes (ci-après le "message") sont
    confidentiels et établis à l'intention exclusive de ses destinataires.
    Toute utilisation ou diffusion non autorisée est interdite.
    Tout message électronique est susceptible d'altération.
    La SOCIETE GENERALE et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.

                                    ********

    This message and any attachments (the "message") are confidential and
    intended solely for the addressees.
    Any unauthorised use or dissemination is prohibited.
    E-mails are susceptible to alteration.
    Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

    *************************************************************************
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


  • Next message: Bill Royds: "Re: [fw-wiz] An article from Peter Tippett/TruSecure..."

    Relevant Pages

    • Re: [fw-wiz] An article from Peter Tippett/TruSecure...
      ... The point that Peter's making is that chasing vulnerabilities just because ... That means that if you spent time patching say an applicable 70% of those ... It's purely a risk funciton- and if you have good data on which small ... That saves you 65% of the maintenance, fixes, "patch breaks things" and all ...
      (Firewall-Wizards)
    • Re: [fw-wiz] An article from Peter Tippett/TruSecure...
      ... vulnerabilities, threats, and costs to give an expected cost of each threat. ... To properly evaluate risks of what you pass through your firewall, ... That means that if you spent time patching say an applicable 70% of those ... It's purely a risk funciton- and if you have good data on which small ...
      (Firewall-Wizards)
    • Re: [fw-wiz] An article from Peter Tippett/TruSecure...
      ... > The point that Peter's making is that chasing vulnerabilities just because ... > That means that if you spent time patching say an applicable 70% of those ... > vulnerabilities, then 68% of that time was wasted. ... > It's purely a risk funciton- and if you have good data on which small ...
      (Firewall-Wizards)
    • FW: [Full-Disclosure] FreeBSD Security Notice FreeBSD-SN-03:01
      ... Subject: FreeBSD Security Notice FreeBSD-SN-03:01 ... Several ports in the FreeBSD Ports Collection are affected by security ... The listed vulnerabilities are not specific to FreeBSD unless ...
      (Full-Disclosure)
    • Re: Vulnerability Assessment
      ... IMHO, therefore, I prefer to list ALL the vulnerabilities but prioritize fixes based on my perception of the risk of that vulnerability being exploited in that environment. ... In terms of analysis, where you need to trust employees or not, I think you ...
      (Pen-Test)