Security World: firewall-wizards digest, Vol 1 #1634

Send firewall-wizards mailing list submissions to
firewall-wizards@honor.icsalabs.com

To subscribe or unsubscribe via the World Wide Web, visit
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@honor.icsalabs.com

You can reach the person managing the list at
firewall-wizards-admin@honor.icsalabs.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: The Death Of A Firewall (Josh Welch)
2. Re: The Death Of A Firewall (Kevin)
3. RE: The Death Of A Firewall (bill.price@cox.net)
4. Re: RE: SSH brute force attack (Mark Ness)
5. VOIP versus PBX (Yehuda Goldenberg)
6. RE: Checkpoint VPN (David West)
7. Re: Checkpoint VPN (QTR)
8. Re: Opinion: Worst interface ever. (sin)

--__--__--

Message: 1
Date: Tue, 19 Jul 2005 09:07:30 -0500
From: Josh Welch <jwelch@buffalowildwings.com>
To: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] The Death Of A Firewall

James Paterson wrote:
> http://www.securitypipeline.com/165700439
>
> Be interesting to get the communities take on this article.
>

"We can do that now, thanks to layer-3 data center switches that allow
for the low-cost creation of subnets. By defining simple ACLs, we
further isolate our backend servers."

Hmm, seperating machines into security specific zones and regulating the
traffic between them....nope, no firewall here.

"The servers and their respective applications sit in their own DMZ,
protected by an Application-layer firewall. We organize servers into
three tiers: The first tier consists of presentation servers such as Web
and e-mail servers--these are the only servers accessible to end users.
The second tier, made up of application and middleware servers, is in
turn only accessible to the presentation servers. Finally, the third
tier, consisting of the database servers, is only accessible to the
application and middleware servers."

Yep, the've done an excellent job at removing the old scourge to
productivity, the firewall.

"The price tag of such a hardware-intensive architecture may seem high,
but virtualization software allows us to deploy all three tiers within
the same server."

Ahh, they've virtualized it so the firewalls don't really exist.

I read this earlier and my impression then as now is that the title of
the article is horribly misleading. While they do appear to be trying to
get away from the crunchy outside chewy inside model, they are doing it
by increasing the use of security strategies that seem an awful lot like
firewalls to me. This is probably a good thing overall, but the way the
article is presented certain PHB types could get the wrong impression.

Josh

--__--__--

Message: 2
Date: Tue, 19 Jul 2005 10:28:17 -0500
From: Kevin <kkadow@gmail.com>
Reply-To: Kevin <kkadow@gmail.com>
To: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] The Death Of A Firewall
Cc: James Paterson <jpaterson@datamirror.com>

On 7/9/05, James Paterson <jpaterson@datamirror.com> wrote:
> http://www.securitypipeline.com/165700439
>=20
> Be interesting to get the communities take on this article.

This is the Jericho project, http://www.opengroup.org/jericho/

Either this is the worst thing to ever come out of the Opengroup,
or a massive practical joke, or some combination of the two.

I've certainly got better things to do with my time than build and
monitor and maintain firewalls, but trying to keep tens of thousands
of workstations *perfectly* immune to attack isn't my idea of an
improvement over the status quo.

Kevin Kadow

--__--__--

Message: 3
From: <bill.price@cox.net>
To: <firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] The Death Of A Firewall
Date: Tue, 19 Jul 2005 12:45:40 -0400

For reference, here's the article link again:
http://www.securitypipeline.com/165700439

1) Life is a lot better with layer 3 switching. If you don't have that, however, it is not clear how one reaps the benefits being advocated by this article...even with the AV, tiered servers, application-layer firewalls, and PKI benefits listed. The original mind-set wasn't flawed; new technology allowed the same problems to be approached in a different fashion.
2) Not seeing anymore about the company where the author worked his magic, I can only assume that his application development staff has some of the same problems that I've witnessed the last 20 years or so. That is a) they are somewhat dense regarding how to develop secure networked applications, so b) the network folks have to build security into other areas so unsafe apps play well with others.
3) It isn't clear if the new network has multiple application layer firewalls or not. If it does, I don't see how the new network has improved much beyond network-layer firewalls. A significant protective burden (not to mention administrative burden to manage multiple systems) is still borne by firewalls. If it has only one, how true an application-layer firewall has been deployed? Email isn't ftp isn't ...
4) Clients in the clear? I can only assume the CM is better at his place of work than mine. Unless there is a complete prohibition on downloading/installing the tool de jour, I don't see how the security environment is improved. I'd also like to know a bit more about the PKI implementation: is this a single sign on environment? How do you protect the integrity of the certificate on corporate laptops? What level of effort was required to integrate PKI (if any) into the services his network supports?
5) It looks to me that the author works for a company that forced a default allow security policy on him to support AD...he made the best of a tough situation. I bet his monitoring capability employs a bunch of new people now.
:-)

My $0.02.

--__--__--

Message: 4
Date: Tue, 19 Jul 2005 11:38:50 -0700
From: Mark Ness <noneinc@gte.net>
Subject: Re: [fw-wiz] RE: SSH brute force attack
To: Brian Loe <knobdy@stjoelive.com>
Cc: firewall-wizards@honor.icsalabs.com

I have seen lots of views on this subject, and if your security is good,
the chances of any of these
attacks getting in are minimal, but the possibility is there, and, since
these are not customers viewing
our home pages, but deliberate attempts at a login through ssh where
they have no business trying to l
login in the first place (many of them attempts at root) they are only
interested in breaking in for
whatever purpose, who knows. Maybe just for the challenge? Maybe to
hijack your box? Maybe ID theft?
Brian Loe wrote:

>Kind of risk losing customer access taking this route, don't you? For that
>matter, shouldn't some security group focus on chasing down the criminals?
>Curious on the group's take.
>
>
>
>>-----Original Message-----
>>From: firewall-wizards-admin@honor.icsalabs.com
>>[mailto:firewall-wizards-admin@honor.icsalabs.com] On Behalf
>>Of Mark Ness
>>Sent: Saturday, July 09, 2005 11:51 PM
>>To: firewall-wizards@honor.icsalabs.com
>>Subject: [fw-wiz] RE: SSH brute force attack
>>
>>Mathew Want wrote:
>>
>>
>>>I would like to hear any suggestions or thoughts anyone may
>>>
>>>
>>have on this....
>>There is a script to blacklist Illegal attacks at
>>http://www.bwongar.com/articles/105
>>
>>
>
>
>
>
>

--__--__--

Message: 5
Date: Fri, 15 Jul 2005 09:40:52 -0400
From: "Yehuda Goldenberg" <Yehuda@nj.essutton.com>
To: <firewall-wizards@honor.icsalabs.com>
Subject: [fw-wiz] VOIP versus PBX

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58942.D197A3F0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Our company is looking to replace an antiquated phone system.

I was leaning towards using a traditional PBX, because I figured that it
would be more reliable and it wouldn't be subject to the problems of IP
networks.

One vendor is trying to get me to change my mind about that. He claims
that we can keep the voice and data networks completely separate by
running vlans. The IP phones have vlan switches on them and one wire can
be run to each desk and the pc and the phone can be on separate vlans.

I was concerned that problems on the data network such as viruses would
still bring down the whole thing, and in addition to the pcs not
working, the phones wouldn't work either and it would be total mayhem.
He says that QOS would make sure that the phone calls always go through
even if the data network is completely dead.

I was also concerned that the VOIP system would mean every call - even
desk-to-desk would go through the internet and if the T1 to the internet
goes down, the phones don't work. His answer to that was redundant T1
links, and since they are the ISP and the VOIP provider, they will give
us a reliable network that won't go down. Also all the VOIP equipment on
their end is redundant.

=20

What else do I have to worry about with VOIP? Is VOIP ready to replace
PBX yet, or is it too new?

=20

Any help would be appreciated.

=20

------_=_NextPart_001_01C58942.D197A3F0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

</head>

Our company is looking to replace an antiquated phone
system.<o:p></o:p>

I was leaning towards using a traditional PBX, =
because I
figured that it would be more reliable and it wouldn’t be subject =
to the
problems of IP networks.<o:p></o:p>

One vendor is trying to get me to change my mind =
about that.
He claims that we can keep the voice and data networks completely =
separate by
running vlans. The IP phones have vlan switches on them and one wire can =
be run
to each desk and the pc and the phone can be on separate =
vlans.<o:p></o:p>

I was concerned that problems on the data network =
such as
viruses would still bring down the whole thing, and in addition to the =
pcs not
working, the phones wouldn’t work either and it would be total =
mayhem. He
says that QOS would make sure that the phone calls always go through =
even if
the data network is completely dead.<o:p></o:p>

I was also concerned that the VOIP system would mean =
every
call – even desk-to-desk would go through the internet and if the =
T1 to
the internet goes down, the phones don’t work. His answer to that =
was
redundant T1 links, and since they are the ISP and the VOIP provider, =
they will
give us a reliable network that won’t go down. Also all the VOIP
equipment on their end is redundant.<o:p></o:p>

<o:p> </o:p>

What else do I have to worry about with VOIP? Is VOIP =
ready to
replace PBX yet, or is it too new?<o:p></o:p>

<o:p> </o:p>

Any help would be =
appreciated.<o:p></o:p>

<o:p> </o:p>

</div>

</body>

</html>

------_=_NextPart_001_01C58942.D197A3F0--

--__--__--

Message: 6
Date: Wed, 20 Jul 2005 15:39:17 +1000
From: David West <davidawest@gmail.com>
Reply-To: David West <davidawest@gmail.com>
To: tmwhitm@gmail.com
Subject: RE: [fw-wiz] Checkpoint VPN
Cc: firewall-wizards@honor.icsalabs.com

Sounds like your ike/udp is fragmenting somewhere between the client
and your firewall. This almost always occurs with x.509 certificate
authentication as the cert is too big for a standard Ethernet frame
and dropeed by many cable/dsl routers. Try using ike/tcp. On your
gateway(s) enable support IKE over TCP in global properties and by
enable the following on in SecureClient for your sites profile:

+ Connectivity enhancements
+ Use NAT traversal tunneling
- IKE over TCP
- Force UDP encapsulation

David

-----Original Message-----
From: QTR [mailto:tmwhitm@gmail.com]
Sent: Wednesday, 13 July 2005 12:09 AM
To: firewall-wizards@honor.icsalabs.com
Subject: [fw-wiz] Checkpoint VPN

Hello, I was wondering if someone could point me in the right
direction. I have come off a long run of managing Cyberguard
firewalls and am now in the Checkpoint realm, so forgive my ignorance.
I am having an issue with secure client. I have several SoHo users
whose default routers place them on a 172.16.0.0 network. These users
cannot connect to the gateway. Dumps on the checkpoint fw gateway
show no incoming packets and a dump on the client show udp 500 leaving
the client, which leads me to the router/firewall @ the SoHo. Router
makes vary, anywhere from 2wire to netgear, the result is the same. I
initially thought it had something to do with the routing topology
since our topology pushes a static route for a 172 network, but I had
the SoHo router changed to a 10 network that is statically routed in
the topology and that worked fine. At this point I am at a loss. Any
suggestions would be appreciated.

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

--__--__--

Message: 7
Date: Wed, 20 Jul 2005 11:38:48 -0400
From: QTR <tmwhitm@gmail.com>
Reply-To: QTR <tmwhitm@gmail.com>
To: David West <davidawest@gmail.com>
Subject: Re: [fw-wiz] Checkpoint VPN
Cc: firewall-wizards@honor.icsalabs.com

Thank you everyone for your input. In working with an engineer, it
appears that since I have an interface on the FW configured as a
172.16.0.0 network, this is causing the issue. Please see the
knowledge base blurb below. The resolution we used was to,"Stop VPN-1
SecureClient", open on the client, "C:\Program
files\CheckPoint\SecuRemote\database\userc", search for the
line,"resolve_interface_ranges (True)" and change the "True" to
"False" and save the file. Start SecureClient and try to connect.=20
This worked. The modification below is a change on the firewall and
am not sure at this point if that can be overwritten when changes are
made to the firewall. So for now, we are making the change to the
client, since there are only a few until we confirm that this
attribute won't be changed automatically by the fw.

Thanks again,

This is taken from the Checkpoint secureknowledge DB, sk15830,=20

2) Symptom:"Communication with site fails"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
There can be a few reasons:

a. Key exchanges performed with the wrong interface IP address of the
VPN-1/FireWall-1 Module.

Explanation: By default, the parameter "resolve_interface_ranges" is
"true" in the VPN-1/FireWall-1 Module's objects_5_0.C file. This
parameter enables the module to send its topology data to the Client
during topology download. In a situation with private IP networks,
SecuRemote/SecureClient may attempt and exchange keys with the wrong
interface IP address (private instead of public).

Workaround: Set the parameter "resolve_interface_ranges" to "false" in
objects_5_0.C file.

On 7/20/05, David West <davidawest@gmail.com> wrote:
> Sounds like your ike/udp is fragmenting somewhere between the client
> and your firewall. This almost always occurs with x.509 certificate
> authentication as the cert is too big for a standard Ethernet frame
> and dropeed by many cable/dsl routers. Try using ike/tcp. On your
> gateway(s) enable support IKE over TCP in global properties and by
> enable the following on in SecureClient for your sites profile:
>=20
> + Connectivity enhancements
> + Use NAT traversal tunneling
> - IKE over TCP
> - Force UDP encapsulation
>=20
> David
>=20
>=20
> -----Original Message-----
> From: QTR [mailto:tmwhitm@gmail.com]
> Sent: Wednesday, 13 July 2005 12:09 AM
> To: firewall-wizards@honor.icsalabs.com
> Subject: [fw-wiz] Checkpoint VPN
>=20
>=20
> Hello, I was wondering if someone could point me in the right
> direction. I have come off a long run of managing Cyberguard
> firewalls and am now in the Checkpoint realm, so forgive my ignorance.
> I am having an issue with secure client. I have several SoHo users
> whose default routers place them on a 172.16.0.0 network. These users
> cannot connect to the gateway. Dumps on the checkpoint fw gateway
> show no incoming packets and a dump on the client show udp 500 leaving
> the client, which leads me to the router/firewall @ the SoHo. Router
> makes vary, anywhere from 2wire to netgear, the result is the same. I
> initially thought it had something to do with the routing topology
> since our topology pushes a static route for a 172 network, but I had
> the SoHo router changed to a 10 network that is statically routed in
> the topology and that worked fine. At this point I am at a loss. Any
> suggestions would be appreciated.
>=20
> Thank you,
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
>

--__--__--

Message: 8
Date: Wed, 20 Jul 2005 23:44:26 +0300
From: sin <sin@pvs.ro>
To: dave@corecom.com
Cc: firewall-wizards-admin@honor.icsalabs.com,
StefanDorn@bankcib.com, firewall-wizards@icsalabs.com
Subject: Re: [fw-wiz] Opinion: Worst interface ever.

This is a cryptographically signed message in MIME format.

--------------ms010904070009040100030804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dave Piscitello wrote:
> I'm not certain why this thread has persisted
>
> I've been largely and politely silent because (a) I consult to
> WatchGuard and (b) thought this kind of discussion was off limits.
> I've used every WGRD model since the FB II and frankly, lots of the
> comments posted here are difficult for me to accept given my
> considerably more positive experience.

Nobody has to like the firewalls made by Watchguard, and if someone
disliked that product for some reason is his right to tell the world to
stay away from it. It's the same as saying to everyone that Mountain Dew
sucks because you don'y like it. Some will belive you, some won't. So I
don't see your problem ? (Except maybe that WG will not sale one or more
appliances, but that's just collateral damage)

You know you are biased on this thread, no ?

>
> Is it now open season? Can I begin a per vendor thread on all the
> awful experiences I've had with other vendor firewalls, including
> several that have been mentioned already in this thread?

It's a free world, no ? (or at least in some parts of the globe)

>
> Or can we declare the horse is dead and move on?
>

I think dead it's a good state... until the next time :)

--------------ms010904070009040100030804
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIzTCC
AsEwggIqoAMCAQICAw5x+jANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNDEwMDIxNTUyWhcNMDYwNDEwMDIxNTUy
WjA8MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRkwFwYJKoZIhvcNAQkBFgpz
aW5AcHZzLnJvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyHSxKPHU+wX1crYR
Q7KGvI+O/HB0EZTXrXtcSIDPJz7SFRSfTPUFTtoJGEjROzr/HcfCQcf3/A9JQVfp8AiOPXDA
OmeRXFCZPTjpVKQDi12Dmou2dzOnkZ6Q1UtsTF9R1gEIzlAOcq6961D1FKJpYpxDpgoJeGdm
oOzMfdd0e1UJR6bhf1FJdtLHtXZOq3lhpYwjI5joYWRB+win2RwGRbn+BjPsypKkEaSdIXtX
kgZqDSLz1dX3KGv15DrNgllvmKry3pne1gMnrGNeAiBZ8VVI327pC+uMI+BCZ0e1QkEoi/C6
zGgGVi/Kf3qS6ULICXBi4/cKguL7ycokg9C3SQIDAQABoycwJTAVBgNVHREEDjAMgQpzaW5A
cHZzLnJvMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAtW2NxtaXjMKvOITMgUNm
YL/J12Pj+DFpRkaluOuX4nEGgwPuVRv29bOoC4v9LwqaV9HT65XuF1N/ailu8BO+e34CA2Uf
ruXwUYcUX9qT1e0BQXb+A6TOi69IAvHBn0J+fxXeehkLNFIODFEc0u1Q1+EefkXNUaDBhfIK
ytmNP2IwggLBMIICKqADAgECAgMOcfowDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDQxMDAyMTU1MloXDTA2MDQx
MDAyMTU1MlowPDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEZMBcGCSqGSIb3
DQEJARYKc2luQHB2cy5ybzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMh0sSjx
1PsF9XK2EUOyhryPjvxwdBGU1617XEiAzyc+0hUUn0z1BU7aCRhI0Ts6/x3HwkHH9/wPSUFX
6fAIjj1wwDpnkVxQmT046VSkA4tdg5qLtnczp5GekNVLbExfUdYBCM5QDnKuvetQ9RSiaWKc
Q6YKCXhnZqDszH3XdHtVCUem4X9RSXbSx7V2Tqt5YaWMIyOY6GFkQfsIp9kcBkW5/gYz7MqS
pBGknSF7V5IGag0i89XV9yhr9eQ6zYJZb5iq8t6Z3tYDJ6xjXgIgWfFVSN9u6QvrjCPgQmdH
tUJBKIvwusxoBlYvyn96kulCyAlwYuP3CoLi+8nKJIPQt0kCAwEAAaMnMCUwFQYDVR0RBA4w
DIEKc2luQHB2cy5ybzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALVtjcbWl4zC
rziEzIFDZmC/yddj4/gxaUZGpbjrl+JxBoMD7lUb9vWzqAuL/S8KmlfR0+uV7hdTf2opbvAT
vnt+AgNlH67l8FGHFF/ak9XtAUF2/gOkzouvSALxwZ9Cfn8V3noZCzRSDgxRHNLtUNfhHn5F
zVGgwYXyCsrZjT9iMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UE
BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD
VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl
cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ
KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw
MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ
c3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1
BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwL
B+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ
cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYy
aHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD
VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN
BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82
L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr3
94fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEBMGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOcfowCQYFKw4D
AhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUw
NzIwMjA0NDI2WjAjBgkqhkiG9w0BCQQxFgQU0NKbjFlHvhcaKdXYlKZ3D1B+r38wUgYJKoZI
hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw5x+jB6BgsqhkiG9w0BCRACCzFr
oGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOcfow
DQYJKoZIhvcNAQEBBQAEggEAGeaemaC+06H8+Xdv0KDKUeg2UFaAbC49MuoK7xij0GwKczeK
MgqpVCNHWQKrd7StYBAFhVznkSGcXxwKe+3pii9Hp/sEAFcvEHuc+wqIFbBmOtp8hhpzD7i2
xDzkRkdA+GAAJu+qsfre8FJ1piMpbKqFDPvsqniE40g1crTxvb8SW0fPk3FOjaLX6uIUu16L
5NWEqZxw/LcgM9bHb7TAuUlHTg+w3e1YnCmWoTdyEONrLrzGItZZN1EpEg9qJC2BWJrbacu7
Qx4ehHuqWwNR7ggFn9JblqOmszkbk3w1NEZa5lkM/sIwrIVGer9E+efPl+c+WT3WMWCOARtP
+U+iNAAAAAAAAA==
--------------ms010904070009040100030804--

--__--__--

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

End of firewall-wizards Digest

Security World

Search This Blog

Thursday, July 21, 2005

firewall-wizards digest, Vol 1 #1634 - 8 msgs

No comments: