Re: firewall-wizards digest, Vol 1 #325 - 10 msgs

["Boni Bruno" <bbruno () dsw net>]

I read an interesting white paper from captus networks DoS protection system that
is based on controlling bandwidth by packet reframing....where legitimate traffic
can be controlled through packet reframing and spoofed packets are dropped due
to the lack of being able to reframe the packets.

There are no attack signatures to reference, just bandwidth rules.  I do not know
what the throughput of their device is or what is in the appliance..

Do any of you have any comments on captus networks and wether this reframing
concept would work well for DoS/IDS???

Curious.

Boni Bruno, CISSP
Data Systems Worldwide, Inc.

firewall-wizards-request () nfr com wrote:

> Send firewall-wizards mailing list submissions to
>         firewall-wizards () nfr com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://list.nfr.com/mailman/listinfo/firewall-wizards
> or, via email, send a message with subject or body 'help' to
>         firewall-wizards-request () nfr com
>
> You can reach the person managing the list at
>         firewall-wizards-admin () nfr com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of firewall-wizards digest..."
>
> Today's Topics:
>
>    1. RE: Re: Code Red: What security specialist don't  mention in warnings(Frank Knobbe) (Tony)
>    2. RE: VPN Problems - Good traceroute tools. (Peter Lukas)
>    3. X White Paper Released (Ofir Arkin)
>    4. DNS tunnel (was Re: Code Red: What security specialist don't  men
>        tion in warnings) (Frank Knobbe)
>    5. RE: VPN Problems (Ben Nagy)
>    6. Re: Help!!! Trying to get firewall running but I don't know what I'm
>        doing wrong! (rob.roberson () verizon com)
>    7. RE: VPN Problems (Walters, Thomas B)
>    8. Re: Re: Code Red: What security specialist don't mention in   warnings(Frank Knobbe) (Antonomasia)
>
> --__--__--
>
> Message: 1
> From: "Tony" <fwWiz-post-9831a () tony3 com>
> To: "B. Scott Harroff" <Scott.Harroff () att net>
> Cc: <firewall-wizards () nfr com>
> Subject: RE: [fw-wiz] Re: Code Red: What security specialist don't  mention in warnings(Frank Knobbe)
> Date: Mon, 13 Aug 2001 21:35:12 -0500
>
> Hi Scott,
>
>   I think that you misunderstood daN.  Suppose an attacker has taken over
> one of your internal servers.  All lookups below are done by the
> compromised machine:
>
> ----
> Lookup "i-own-192-168-2-2.int-nat-gw-12-4-2-1.attacker.org"
> Response "19.2.33.1"
> ----
>
> Now, the attacker knows that they have control of 192.168.2.2 with NAT
> gateway 12.4.2.1.  Suppose that the remote access trojan is programmed to
> do a reverse lookup for the returned address.
>
> ----
> Lookup PTR for 19.2.33.1
> Response "attack-192-168-2-1.attacker.org"
> ----
>
> The trojan has received the command to attack 192.168.2.1.  The only
> limitation to this type of communication is that its initiation is half
> duplex.  The attacker cannot send a command to the trojaned machine until
> the trojaned machine initiates a DNS query.  Lack of a reverse channel
> simply requires the trojan to poll the attacker for new commands
> automatically.
>
> These requests and responses are completely valid and will be forwarded
> by any intermediary DNS servers that you place in the resolution path.
> How do you prevent against this type of tunneling?  You can't without
> affecting functionality of the underlying service.
>
>  - Tony
>
> -----Original Message-----
> From: firewall-wizards-admin () nfr com
> [mailto:firewall-wizards-admin () nfr com]On Behalf Of B. Scott Harroff
> Sent: Monday, August 13, 2001 9:16 AM
> To: Joseph Steinberg; Bob Washburne; firewall-wizards () nfr com; daN.
> Subject: Re: [fw-wiz] Re: Code Red: What security specialist don't
> mention in warnings(Frank Knobbe)
>
> Regarding not being able to block malicious DNS, I disagree.  Suppose:
>
> For Internet DNS (client) resolution:  Configure your internal users to
> use
> a DNS server(s) in a DMZ setting.  Configure your DNS server(s) as
> forwarder/slave(s) to the IP address(s) of your ISP's DNS servers (or
> your
> favorite trusted Internet DNS server).   Permit only inbound DNS queries
> w/SYN set (and the stateful response) from your internal networks to your
> DMZ DNS server.   Permit only outbound queries w/SYN set (and the
> stateful
> responce) from your DNS server to the trusted IP addresses of the outside
> DNS servers you selected.  Permit only the necessary ICMP
> requests/responces
> from these servers.
>
> For DNS hosting, allow your ISP to be secondary, and your server to be
> primary (so you can change/manage your DNS). Again, impliment your DNS
> server(s) in a DMZ and allow only inbound/outbound DNS w/SYN set (and the
> stateful responce) from the trusted IP address(s) of your ISP (secondary)
> DNS server(s) to your DNS server(s) (primary). Permit only the necessary
> ICMP requests/responces from these servers.
>
> ----- Original Message -----
> From: "daN." <dan () evilhippo com>
> To: "Joseph Steinberg" <Joseph () whale-com com>; "Bob Washburne"
> <rcwash () concentric net>; <firewall-wizards () nfr com>
> Sent: Friday, August 10, 2001 2:37 AM
> Subject: Re: [fw-wiz] Re: Code Red: What security specialist don't
> mention
> in warnings(Frank Knobbe)
>
> > Sigh...Even an application proxy cannot stop a cleverly designed trojan
> > from tunneling out..what if it uses valid DNS queries as the tunnel?
> You
> > can, block them and the relay them along, and then relay back an
> encoded
> > DNS reply..there is absolutely no way of stopping this, and you can do
> > similar over any valid services, application proxies can only take
> things
> > so far..and there are many many many servers which crash upon receiving
> > messages completely legal by the protocol.
> >
> > daN.
> >
> > At 11:49 AM 8/6/01 -0400, Joseph Steinberg wrote:
> >
> > > I agree wholeheartedly that we do need to come up with a better way of
> > > addressing these issues than patching every specific vulnerability.
> Our
> > > e-Gap systems do this with positive logic -- i.e., enforcing that
> > > web-servers/applications only receive requests in formats that the
> > > web-servers/apps expect. So, worm attacks, hacker attacks, etc. (which
> are
> > > generally based on unexpected submissions) fail -- regardless of
> whether
> the
> > > particular hack is known to our product or not. I am curious how
> others
> deal
> > > with this.
> > >
> > > Tunneling -> There are ways to mitigate against tunneling threats. I
> know
> > > that our products address tunneling by eliminating TCP/IP connectivity
> and
> > > TCP/IP headers, there may be other that do so as well. We also
> distinguish
> > > between types of attacks, and I am certain others do as well.
> > >
> > > BTW: Even a firewall with a strong application proxy will likely not
> solve
> > > this unless it uses positive logic. There will always be new
> vulnerabilities
> > > to keep up with.
> > >
> > > Joseph
> > >
> > > > Security is not a binary value, yes or no, but a spectrum.  The more
> > > > secure you make the system the fewer worms and script kiddies get
> > > > through.  In this case, Code Red would have been contained (and
> probably
> > > > was on many well maintained systems).  Are there still holes?  Sure.
> > >
> > > > There is no protection at this moment from tunneling.
> > >
> > > > Also, a well formed DDOS attack is indestinguishable from the
> "Slashdot
> > > > Effect."  So there is no defence from that one.
> > >
> > > > But that doesn't mean that we just give up, go home and play with
> our
> > > > Commodore 64's.
> > >
> > > > So I must agree that patching is not the only issue here.  I cannot
> > > > clean up the web, but I appreciate the helpfull ideas to help
> protect
> my
> > > > site.
> > > _______________________________________________
> > > firewall-wizards mailing list
> > > firewall-wizards () nfr com
> > > http://list.nfr.com/mailman/listinfo/firewall-wizards
> >
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards () nfr com
> > http://list.nfr.com/mailman/listinfo/firewall-wizards
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://list.nfr.com/mailman/listinfo/firewall-wizards
>
> --__--__--
>
> Message: 2
> Date: Mon, 13 Aug 2001 21:45:34 -0500 (CDT)
> From: Peter Lukas <plukas () oss uswest net>
> To: Lucas Thompson <Lucas.Thompson () watchguard com>
> Cc: "'Ryan Russell'" <ryan () securityfocus com>,
>         Jason Wu <jwu () keyspanenergy com>, <firewall-wizards () nfr com>
> Subject: RE: [fw-wiz] VPN Problems - Good traceroute tools.
>
> Try Lcrzo:
> http://www.laurentconstantin.com/us/lcrzo/lcrzo/
>
> Peter Lukas
>
> On Mon, 13 Aug 2001, Lucas Thompson wrote:
>
> > This is very often a problem where ISPs filter IP 50 or 51.  A really good
> > way to test it is to use the traceroute that comes with OpenBSD.
> > Openbsd's traceroute allows you to use arbitrary IP protocol numbers instead
> > of just UDP or ICMP like most of them.  Then sniff at your site(s) to see if
> > it gets through.
> >
> > I just wish I had a Linux port of it  :)
> >
> > lucas
> >
> > -----Original Message-----
> > From: Ryan Russell [mailto:ryan () securityfocus com]
> > Sent: Friday, August 10, 2001 4:53 PM
> > To: Jason Wu
> > Cc: firewall-wizards () nfr com
> > Subject: Re: [fw-wiz] VPN Problems
> >
> >
> >
> > On Thu, 9 Aug 2001, Jason Wu wrote:
> >
> > > Hi, has anyone on this list had any problems with their VPNs that can be
> > > traced to something the ISP is doing?
> >
> > Sure.  I've had ISPs not pass the packet types I needed them to, despite
> > their claims that they do no filtering.  Do a traceroute some time and see
> > how many ISPs you cross.
> >
> > > I want to get an idea of how
> > > prevalent it is for ISPs to filter VPN traffic or to perform NAT causing
> > > AH to break etc.
> >
> > Yes, any of that will break AH.  Or GRE.  Or IPinIP, etc...
> >
> > > Also, how have you worked around these limitations?
> >
> > Change ISPs or VPN software.
> >
> > But at least I'm not bitter or cynical about it. :)
> >
> > Note that it is explicitly against the policies of some ISPs to use a VPN.
> >
> >                                       Ryan
> >
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards () nfr com
> > http://list.nfr.com/mailman/listinfo/firewall-wizards
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards () nfr com
> > http://list.nfr.com/mailman/listinfo/firewall-wizards
>
> --__--__--
>
> Message: 3
> From: "Ofir Arkin" <ofir () sys-security com>
> To: <firewall-wizards () nfr com>
> Date: Tue, 14 Aug 2001 06:09:44 +0200
> Subject: [fw-wiz] X White Paper Released
>
> Hello all,
>
> We are happy to announce the availability of X white paper.
>
> This follows our release of Xprobe the tool (now version 0.0.1p1). The
> White paper explains the reasons, design, techniques used and logic
> behind the tool, as well as future directions and thoughts.
>
> "X is a logic which combines various remote active operating system
> fingerprinting methods using the ICMP protocol, which were discovered
> during the "ICMP Usage in Scanning" research project, into a simple,
> fast, efficient and a powerful way to detect an underlying operating
> system a targeted host is using.
>
> Xprobe is a tool written and maintained by Fyodor Yarochkin
> (fygrave () tigerteam net) and Ofir Arkin (ofir () sys-security com) that
> automates X.
>
> Why X?
> X is a very accurate logic.
>
> Xprobe is an alternative to some tools which are heavily dependent upon
> the usage of the TCP protocol for remote active operating system
> fingerprinting. This is especially true when trying to identify some
> Microsoft based operating systems, when TCP is the protocol being used
> with the fingerprinting process. Since the TCP implementation with
> Microsoft Windows 2000 and Microsoft Windows ME, and with Microsoft
> Windows NT 4 and Microsoft Windows 98/98SE are so close, usually when
> using the TCP protocol with a remote active operating systems
> fingerprinting process we are unable to differentiate between these
> Microsoft based operating system groups.  And this is only an example.
>
> As we will demonstrate the number of datagrams we need to send and
> receive in order to remotely fingerprint a targeted machine with X is
> small. Very small. In fact we can send one datagram and receive one
> reply and this will help us identify up to eight different operating
> systems (or groups of operating systems). The maximum datagrams the tool
> will send is four. This is the same number of replies we will need. This
> makes Xprobe very fast as well..."
>
> The White paper can be downloaded from:
> http://www.sys-security.com/archive/papers/X_v1.0.pdf [~321k]
> http://www.sys-security.com/archive/papers/X_v1.0.zip [~169k]
>
> X Homepage:
> http://www.sys-security.com/html/projects/X.html
>
> Xprobe Download:
> http://www.sys-security.com/archive/tools/X/xprobe-0.0.1p1.tar.gz [~49k]
>
> Any suggestions and remarks are more than welcomed.
>
> Ofir Arkin [ofir () sys-security com]
> Founder
> The Sys-Security Group
> http://www.sys-security.com
> PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA
>
> Fyodor Yarochkin
> [fygrave () tigerteam net]
> PGP 56DD 1511 DDDA 56D7 99C7  B288 5CE5 A713 0969 A4D1
>
> --__--__--
>
> Message: 4
> From: Frank Knobbe <FKnobbe () KnobbeITS com>
> To: "'B. Scott Harroff'" <Scott.Harroff () att net>,
>         firewall-wizards () nfr com, "daN." <dan () evilhippo com>
> Date: Mon, 13 Aug 2001 21:44:15 -0500
> Subject: [fw-wiz] DNS tunnel (was Re: Code Red: What security specialist don't  men
>  tion in warnings)
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Scott,
>
> what you are saying is correct if you are thinking in terms of
> establishing DNS _connections_ to the outside. However, what Dan
> meant was that there are trojans that tunnel data in valid DNS
> queries. As long as your relaying DNS server has to resolve hosts
> from other DNS servers on the Internet, you can tunnel data.
>
> This occurs by the client asking for TXT records or as simple as the
> host name for 2344bf82883423.domain.tld (with data being encapsulated
> in the host portion of the query), and the (rogue) DNS replying with
> the return data in the TXT record, or simply by returning the host
> 98344bf82883423.domain.tld as a cname for
> 23478787323aaf9d.domain.tld. Both, the request and the answer are
> valid DNS queries that any of your internal DNS server would relay
> (since you need to resolve names somehow). For this setup to work,
> the attacker will have to have a pseudo DNS server running for a
> certain domain.
>
> This type of tunnel has been discussed several times, and as far as I
> remember, only one poster responded that some firewall (Gauntlet?)
> were able to filter this, although I'm not sure about this. I'm
> haven't seen this exploit being prevented. What it takes is a smart
> DNS _proxy_, not _relay_. But then again, how will the proxy
> distinguish between fake and real hostnames... :/
>
> Anyone else have any updates?
>
> Regards,
> Frank
>
> > -----Original Message-----
> > From: B. Scott Harroff [mailto:Scott.Harroff () att net]
> > Sent: Monday, August 13, 2001 9:16 AM
> >
> > Regarding not being able to block malicious DNS, I disagree.
> > Suppose:
> >
> > For Internet DNS (client) resolution:  Configure your
> > internal users to use
> > a DNS server(s) in a DMZ setting.  Configure your DNS server(s) as
> > forwarder/slave(s) to the IP address(s) of your ISP's DNS
> > servers (or your
> > favorite trusted Internet DNS server).   Permit only inbound
> > DNS queries
> > w/SYN set (and the stateful response) from your internal
> > networks to your
> > DMZ DNS server.   Permit only outbound queries w/SYN set (and
> > the stateful
> > responce) from your DNS server to the trusted IP addresses of
> > the outside
> > DNS servers you selected.  Permit only the necessary ICMP
> > requests/responces
> > from these servers.
> >
> > ----- Original Message -----
> > From: "daN." <dan () evilhippo com>
> > To: "Joseph Steinberg" <Joseph () whale-com com>; "Bob Washburne"
> >
> > > Sigh...Even an application proxy cannot stop a cleverly
> > designed trojan
> > > from tunneling out..what if it uses valid DNS queries as
> > the tunnel? You
> > > can, block them and the relay them along, and then relay
> > back an encoded
> > > DNS reply..there is absolutely no way of stopping this, and
> > you can do
> > > similar over any valid services, application proxies can
> > only take things
> > > so far..and there are many many many servers which crash
> > upon receiving
> > > messages completely legal by the protocol.
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Personal Privacy 6.5.8
> Comment: PGP or S/MIME encrypted email preferred.
>
> iQA/AwUBO3iQf5ytSsEygtEFEQLU+gCg3S3g2R+qm7PPYRKWDMDe9kQINfQAn3WG
> pQ3RSsQt7Lmzb6vcHUTG2oMy
> =1NyJ
> -----END PGP SIGNATURE-----
>
> --__--__--
>
> Message: 5
> From: Ben Nagy <ben.nagy () marconi com au>
> To: 'Lucas Thompson' <Lucas.Thompson () watchguard com>
> Cc: "'firewall-wizards () nfr com'" <firewall-wizards () nfr com>
> Subject: RE: [fw-wiz] VPN Problems
> Date: Tue, 14 Aug 2001 12:58:49 +1000
>
> Hping2 can be used to do this under linux - you can specify protocol and
> TTL. I've also seen an application around which has a script wrapper for
> Hping2 to kludge a protocol traceroute, but can't remember where, sorry.
>
> Link: http://sourceforge.net/projects/hping2/
>
> Cheers,
>
> --
> Ben Nagy
> Network Security Specialist
> Marconi Services Australia Pty Ltd
> Mb: +61 414 411 520  PGP Key ID: 0x1A86E304
>
> > -----Original Message-----
> > From: Lucas Thompson [mailto:Lucas.Thompson () watchguard com]
> > Sent: Tuesday, August 14, 2001 7:49 AM
> > To: 'Ryan Russell'; Jason Wu
> > Cc: firewall-wizards () nfr com
> > Subject: RE: [fw-wiz] VPN Problems
> >
> >
> > This is very often a problem where ISPs filter IP 50 or 51.
> > A really good
> > way to test it is to use the traceroute that comes with OpenBSD.
> > Openbsd's traceroute allows you to use arbitrary IP protocol
> > numbers instead
> > of just UDP or ICMP like most of them.  Then sniff at your
> > site(s) to see if
> > it gets through.
> >
> > I just wish I had a Linux port of it  :)
> >
> > lucas
> [...]
>
> --__--__--
>
> Message: 6
> From: rob.roberson () verizon com
> Subject: Re: [fw-wiz] Help!!! Trying to get firewall running but I don't know what I'm
>  doing wrong!
> To: "Afroz Nissar" <afroz000 () hotmail com>
> Cc: firewall-wizards () nfr com
> Date: Tue, 14 Aug 2001 07:50:06 -0400
>
> Afroz,
> Linux firewalls require IP forwarding to be turned on before it will pass
> packets. Try this from a command prompt:
>
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> If it starts working, add this line to your firewall script.
>
> ~Rob Roberson
> SPEC - Systems Analyst
> Verizon Data Services
>
> If you smile at me, I will understand
> 'Cause that is something everybody everywhere does
> In the same language.
>                                                   - David Crosby
>
>
>                     "Afroz Nissar"
>                     <afroz000 () hotmail co        To:     firewall-wizards () nfr com
>                     m>                          cc:
>                     Sent by:                    Subject:     [fw-wiz] Help!!! Trying to get firewall running but I 
> don't know what I'm doing wrong!
>                     firewall-wizards-adm
>                     in () nfr com
>
>
>                     08/10/2001 08:35 AM
>
>
>
> Hey everyone!!!
>      Ok.... first of all.... let me say that I am new to networking
> and everything related to it. I'm just a student and I'm not one of
> those whiz kids! So please forgive me if my question is really stupid
> or has a totally obvious answer!! I am currently working on setting up
> IP Masquerading and a firewall (on separate computers) for a network.
> At the moment, the IP Masquerading works fine and the firewall
> consists of no restrictions whatsoever. All its policies are accept,
> hence, theoretically, it should just allow everything to pass through
> it (This is just for testing purposes). On my IP masq and firewall
> machines, I have installed Redhat 7.1 and upgraded iptables to version
> 1.2.2 and the kernel to 2.4.4. Both these computers have 2 NIC's. Here
> is a diagram of the setup:
> _______________              ___
> |  Internal   |-------------| H |         ___________
> |  Network    |-------------| U |     eth1    |   MASQ    |
> |   of 5      |-------------| B |-------------     |___________|
> | computers   |-------------|   |              |eth0
> |_____________|-------------|___|              |
>                                                  _____|______
>                                                 |____HUB_____|
>                                                       |
>                                                       |eth1
>                                _____|______
>                               |     FW     |
>                               |___________ |
>                                     |eth0
>                                _____|______
>                               |  Router    |
>                                                 |____________|
>                                     |
>                                  INTERNET
>
> The computers on the internal network have 192.168.0.x addresses and
> eth1 of the Masq computer has the address 192.168.0.1. eth0 of Masq
> has a real IP address. eth0 and eth1 of the firewall also have real IP
> addresses.
> This is my problem.... I know that the masking of the internal
> computers works fine but for some reason information does not pass
> through the firewall. From the internal computers I can ping the Masq
> computer. From the firewall, I can ping the internet. But I can't ping
> the firewall from the Masq computer or vice-versa with the above
> setup. But... if I connect eth1 of the firewall to the router and eth0
> of the firewall to the hub.... then I can ping between the Masq and
> the firewall but I cannot ping from the firewall to the internet. I
> have tested both NIC's separately so I know that they work fine. I'm
> pretty sure its something really simple and basic that I am missing
> out here... but I just can't figure out what it is!!!! I guess its
> probably because of my inexperience.... So I would be really grateful
> if someone could help me out here!! Once again... I'm really really
> really sorry if its something stupid or obvious!!! I'm still in the
> very early stages of the learning process!!!
> I thank you all!!!
>
> Afroz.
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://list.nfr.com/mailman/listinfo/firewall-wizards
>
> --__--__--
>
> Message: 7
> From: "Walters, Thomas B" <TBWalter () mail bhi-erc com>
> To: firewall-wizards () nfr com
> Subject: RE: [fw-wiz] VPN Problems
> Date: Tue, 14 Aug 2001 07:36:41 -0700
>
> Check to see if your ISP blocks ICMP.  Some VPN software tries to determine
> the largest packet that the network can support.
>
> Tom
>
> -----Original Message-----
> From: Lucas Thompson [mailto:Lucas.Thompson () watchguard com]
> Sent: Monday, August 13, 2001 3:19 PM
> To: 'Ryan Russell'; Jason Wu
> Cc: firewall-wizards () nfr com
> Subject: RE: [fw-wiz] VPN Problems
>
> This is very often a problem where ISPs filter IP 50 or 51.  A really good
> way to test it is to use the traceroute that comes with OpenBSD.
> Openbsd's traceroute allows you to use arbitrary IP protocol numbers instead
> of just UDP or ICMP like most of them.  Then sniff at your site(s) to see if
> it gets through.
>
> I just wish I had a Linux port of it  :)
>
> lucas
>
> -----Original Message-----
> From: Ryan Russell [mailto:ryan () securityfocus com]
> Sent: Friday, August 10, 2001 4:53 PM
> To: Jason Wu
> Cc: firewall-wizards () nfr com
> Subject: Re: [fw-wiz] VPN Problems
>
> On Thu, 9 Aug 2001, Jason Wu wrote:
>
> > Hi, has anyone on this list had any problems with their VPNs that can be
> > traced to something the ISP is doing?
>
> Sure.  I've had ISPs not pass the packet types I needed them to, despite
> their claims that they do no filtering.  Do a traceroute some time and see
> how many ISPs you cross.
>
> > I want to get an idea of how
> > prevalent it is for ISPs to filter VPN traffic or to perform NAT causing
> > AH to break etc.
>
> Yes, any of that will break AH.  Or GRE.  Or IPinIP, etc...
>
> > Also, how have you worked around these limitations?
>
> Change ISPs or VPN software.
>
> But at least I'm not bitter or cynical about it. :)
>
> Note that it is explicitly against the policies of some ISPs to use a VPN.
>
>                                         Ryan
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://list.nfr.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://list.nfr.com/mailman/listinfo/firewall-wizards
>
> --__--__--
>
> Message: 8
> To: adam () homeport org, pzivic () yahoo com
> Subject: Re: [fw-wiz] Re: Code Red: What security specialist don't mention in   warnings(Frank Knobbe)
> Cc: firewall-wizards () nfr com
> Date: Wed, 15 Aug 2001 00:22:06 +0100 (BST)
> From: ant () notatla demon co uk (Antonomasia)
>
> From: Adam Shostack <adam () homeport org>
>
> > ITS4, RATS, flawfinder, Lopht Slint, fuzz.
>
> I have a couple of tools in Perl and pretty crude:
>
> For file race conditions (after Bishop & Dilger)
>     http://www.notatla.demon.co.uk/SOFTWARE/SCANNER/scanner-1.0b.tar.gz
>
> For format bugs
>     http://www.notatla.demon.co.uk/SOFTWARE/SCANNER/argcount.plx
>
> The format tool is outclassed by Alan DeKok's
>     http://www.striker.ottawa.on.ca/~aland/pscan/
>
>
> > The immunix suite is worth looking at, as is David Wagner's thesis (I
> > don't think the code is available, but hey, sometimes its worth
> > reading the paper, not the code.)
>
> Obviously Adam and I have been pointing our brain cells the same
> way lately.
>
> --
> ##############################################################
> # Antonomasia   ant notatla.demon.co.uk                      #
> # See http://www.notatla.demon.co.uk/                        #
> ##############################################################
>
> --__--__--
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://list.nfr.com/mailman/listinfo/firewall-wizards
>
> End of firewall-wizards Digest

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards