firewall-wizards digest, Vol 1 #1677 - 7 msgs

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 home user problem returns (Mason Schmitt)
2. RE: Different Authentication For vpngroups On PIX (Paul Melson)
3. Re: Different Authentication For vpngroups On PIX (Mike Bydalek)
4. PIX assessment (vulnerable)
5. Re: The home user problem returns (Devdas Bhagat)
6. RE: The home user problem returns (Brian Loe)
7. Re: The home user problem returns (Dave Piscitello)

--__--__--

Message: 1
Date: Tue, 20 Sep 2005 11:17:30 -0700
From: Mason Schmitt <mason@schmitt.ca>
To: Elizabeth Zwicky <zwicky@greatcircle.com>
Cc: Tina Bird <tbird@precision-guesswork.com>,
"'R. DuFresne'" <dufresne@sysinfo.com>,
"'Marcus J. Ranum'" <mjr@ranum.com>,
firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] The home user problem returns

> On the one hand, I agree with Tina -- people change their OWN
> behavior based on their OWN pain. On the other hand, this insight
> leads people to some terrible attempts at training, because people
> (dogs, cats, octopus, anything with a brain of reasonable size)
> do not respond effectively to imposed pain. Positive training
> methods always work better on long-term measures.

I'm in full agreement there. IMHO, the most common attempts at
"education", by the security community, involve scaring people, telling
them what not to do, telling people they are bad for what they have done
or beating them about the head with a clue-by-four and calling them
stupid. These are all negative approaches to the problem that, as you
say, are not likely to gain long term traction. In my experience,
people will attempt to shut out messages that make them feel guilty or
stupid. People want to feel good and unencumbered.

> Why is this relevant in security? Because the principal problem
> is NOT that people don't feel pain when they screw it up -- it's
> that there's absolutely no reward for doing it right (in fact,
> it often causes pain itself).

Very good point. In fact, the security community makes this very clear
when they say that security is inversely proportional to ease of use...
I still think that statement is symptom of the current state of
computing rather than an immutable security truism. There are ways of
improving security for the end user without an equivalent decrease in
ease of use. One reasonable example is Apple's use of sudo. The user
does not run as a full root user, but when they need to elevate
privileges for installing software, they are prompted for their
password. This is obviously not a great solution, but it is quick and
easy for the vendor and does mean that the user is not running as root.

There are pieces of low hanging fruit that can be had by vendors.
However, to really make progress, vendors are going to have to start
taking security much more seriously. Which brings me back to your
point. If users are experiencing pain and they complain to their
vendors, then the vendors will experience pain, if the vendors
experience pain that has the potential to decrease their bottom line,
then they now have Tina's carrot in front of them. The vendor now has
an incentive for providing easy to use security which in turn improves
the situation for the user. There are obvious pitfalls to this
scenario, but it is an ecosystem in which the bar can be raised. So, as
crappy as all of the "hacking is cool" and "enumerating badness" may be,
it may also serve to get vendors moving in the right direction.

The above examples and arguments are narrow in scope in somewhat flawed.
I recognize that just picking on vendors will not solve the problem and
really picking on vendors is just more of same negative approach that
we're trying to avoid, but the above scenario does at least place one
carrot in the mix. We should be striving to create environments that
are more amenable to change by introducing more carrots into the mix.

> If more secure solutions were
> faster, nicer, more fun OR cheaper in practical terms, we
> wouldn't have the problems we do.

Yup.

> Asking people to choose
> long-term lack of pain over immediate reward is like asking
> water to flow uphill. It can be done, but it's an awful
> lot of work...

This is also a symptom of a selfish, instant gratification, consumer
society, but that's another issue altogether that we're not going to
solve by looking at the limited scope of computer security. For those
working on that problem, the benefits of incremental successes will
transfer to all aspects of human society.

> As long as you're working on increasing the pain for bad
> security and making it happen faster, you're still
> working on doing things the hard, ineffective way. If
> you can get a reward for good security, then you're
> working with the flow.

If we do both, then the gains should progress faster than the sum of
their parts. We do need to look at changing our perspectives though. I
don't have a road map for that change, but it really comes down to
choices in the moment - do I wield the clue-by-four or do I take a more
patient approach, do I force people to see the security measures I am
implementing because I think they should be more aware or do I try to
find ways of making security happen transparently so that the users I
service can continue with their work without having to get bogged down
in technical details. Each time we are faced with a decision regarding
security, we need to look at working carrots in.

This is a potentially difficult change in mindset, because security
folks tend to be very "default deny" in their thinking - centralize
control, mistrust, restrict access, block this block that, etc. (I'm
really guilty of this). The same thing can be expressed by saying -
increase manageability, auditability, and accountability; trust those
you have reason to trust; permit known good; allow access to what is
needed; etc. I'm not saying that the industry doesn't have its moments
where it thinks this way, but as Marcus points out the industry spends
most of it's time enumerating badness and selling based upon the fear
that enumerating badness brings.

I'd like to sum up by pointing out that while some of what I say appears
to be contradictory, I do think all the forces at work, negative and
positive, are creating an environment for change. Pain due to negative
behaviours pushes people to change, and positive messages and carrots
encourage people to change. We clearly need more of the latter.
Finally, when people have endured enough pain, they need to have
something to move to. We need to have solutions ready for people that
are still easy to use, but are more secure and reasonably trustworthy.
These solutions should include training in positive behaviours and
technical solutions that are as transparent and easy to use as possible.

--
Mason

--__--__--

Message: 2
From: "Paul Melson" <pmelson@gmail.com>
To: "'Mike Bydalek'" <mbydalek@contentconnections.com>,
<firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Different Authentication For vpngroups On PIX
Date: Thu, 22 Sep 2005 13:02:48 -0400

-----Original Message-----
Subject: [fw-wiz] Different Authentication For vpngroups On PIX

> Currently we have a PIX 515E with a vpngroup setup to use AAA via.
> radius. What I'm trying to do is create a second vpngroup that doesn't
use AAA (yes, I > know what I'm doing and have valid reasons ;) ). What's
happening is that when I take > out my line crypto map line of:
>
> crypto map outside_map client authentication freeradius
>
> and add the following lines to my vpngroup I want to authenticate:
>
> vpngroup myauthgroup authentication-server freeradius
> vpngroup myauthgroup user-authentication
>
> people in myauthgroup are able to authenticate with no client
authentication. The
> Cisco VPN client just let's them connect as long as their group password
is correct.

Nope, vpngroup user-authentication is only for forcing individual per-IP
authentication for clients behind a another PIX or VPN3K configured in
client mode.

I'm not sure you can even do what you propose. I think it's 1 crypto map
per interface, 1 client auth method per crypto map until you get to PIX OS
7.x on the ASA class firewalls (where you set this up like a VPN3K).

Either way, your crypto map must specify what type of client XAUTH it will
use. If it doesn't specify, then no XAUTH is used and it only checks
vpngroup/password to allow access. That's what's happening to you now.

What might (but probably won't) work:

aaa-server freeradius protocol radius
aaa-server freeradius (inside) host 10.1.2.3
aaa-server localauth protocol local
crypto map outside_map client authentication freeradius
crypto map outside_map client authentication localauth

Then set up your vpngroup as you normally would and use 'username' to add
local user/pass pairs. But again, this probably won't work.

PaulM

--__--__--

Message: 3
Date: Thu, 22 Sep 2005 10:20:53 -0700
From: Mike Bydalek <mbydalek@contentconnections.com>
To: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] Different Authentication For vpngroups On PIX

Paul Melson wrote:

>-----Original Message-----
>Subject: [fw-wiz] Different Authentication For vpngroups On PIX
>
>
>
>>Currently we have a PIX 515E with a vpngroup setup to use AAA via.
>>radius. What I'm trying to do is create a second vpngroup that doesn't
>>
>>
>>...
>>
>Nope, vpngroup user-authentication is only for forcing individual per-IP
>authentication for clients behind a another PIX or VPN3K configured in
>client mode.
>
>
Ah, thank you for clearing this up as I wasn't aware of that.

>I'm not sure you can even do what you propose. I think it's 1 crypto map
>per interface, 1 client auth method per crypto map until you get to PIX OS
>7.x on the ASA class firewalls (where you set this up like a VPN3K).
>
>Either way, your crypto map must specify what type of client XAUTH it will
>use. If it doesn't specify, then no XAUTH is used and it only checks
>vpngroup/password to allow access. That's what's happening to you now.
>
>

This makes sense.

Let me then take this and change my question a little. What I am trying
to do is have a server automatically VPN in, backup some files, and then
disconnect. In order to do this, one of the options is storing the
user/pass on the server (not the best idea in the world, but if I have
to, I have to). So, what would then be the best way to setup for this
scenario?

Thank you,
Mike Bydalek

--__--__--

Message: 4
Date: Mon, 26 Sep 2005 06:43:56 -0700
From: vulnerable <vulnerable@gmail.com>
Reply-To: vulnerable <vulnerable@gmail.com>
To: firewall-wizards@honor.icsalabs.com
Subject: [fw-wiz] PIX assessment

hello all.

I'm doing an assessment on the config of a pix running 6.3. Me not
being much of a pix expert have a few questions.

From reading documentation it is my understanding that if you have
traffic flowing from inside (higher security level) to dmz (lower
security level) interface then you will not require either an ACL or a
static statement permitting this. However, this particular config is
declaring transparent static's that the documentation I've read says
is unnecessary. Any reasons why they may be doing this? I'm going
through a rather long config (3000+ lines), and running some perl mojo
I find that there are over 300 statics defined for addresses behind
the inside interface. Useless? Something that perhaps the PDM does?

Oh, I've also been trying to track down the latest rev of pixOS 6.3.=20
Can't find it anywhere on cisco's public site.

Also, I've been using the enterastream documentation (1) as a
reference, is there anything else out there that is worth looking at?

1) http://www.enterastream.com/whitepapers/cisco/pix/pix-practical-guide.ht=
ml

--__--__--

Message: 5
Date: Tue, 27 Sep 2005 21:45:19 +0530
From: Devdas Bhagat <devdas@dvb.homelinux.org>
To: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] The home user problem returns
Reply-To: Devdas Bhagat <devdas@dvb.homelinux.org>

On 19/09/05 19:36 -0700, tbird@precision-guesswork.com wrote:

[Warning: long, meandering response]

> Quoting Elizabeth Zwicky <zwicky@greatcircle.com>:
>
> >
> >On Sep 13, 2005, at 12:23 PM, Tina Bird wrote:
> >>i disagree. i don't know *anyone* who willingly makes a fundamental,
> >>significant change in their behavior without pain as a motivator.
> >
> >On the one hand, I agree with Tina -- people change their OWN
> >behavior based on their OWN pain. On the other hand, this insight
> >leads people to some terrible attempts at training, because people
> >(dogs, cats, octopus, anything with a brain of reasonable size)
> >do not respond effectively to imposed pain. Positive training
> >methods always work better on long-term measures.
>
> correct, as we expect from elizabeth :-) most of the time when i'm
> presenting the use of endpoint enforcement techniques to system
> administrators (the folks who will be managing the systems) and their
> end users, i start by describing it as a reward system for proper

From my PoV, the problem is that the pain and the rewards are for the IT
department. The end user suffers from much less pain. However, the
problem is caused by end users (and management which thinks itself to be
above the rules).

Corporate end users have an IT staff to manage their work systems. Home
systems today are networked, and have the same complex issues that corporate
systems do (or even more complexity). However, there is no _trained_ IT
staff to manage those systems. Positive training works when there is a
real reward.

What is the reward for a home user to participate in security, when the
only visible cost is of formatting and reinstalling the PC every few months?
The price is a significant investment in time, and the tradeoff is not always
in favour of security.

> configuration, rather than a punishment system against incorrect or
> compromised configurations. it's the same as the artificial ignorance
> approach to log management, or good ol' deny all firewall
> rules. the list of "things that absolutely ought to be configured this way"
> is shorter than the list of all possible things that should be prohibited.
>
> so of *course* most folks won't want to do that.
>
Or it is just too complicated to do things the right way [1]. People use
applications (and design protocols) without considering security. Some
designs work when targetted for a small, trustworthy crowd. But they
don't work when there are non trustworthy users.

Unfortunately, there is also a growing culture of avoiding
critical thinking. I have no idea why this is so, but the majority of
people I know don't stop and think through the consequences of their
actions.

> unfortunately, i am consistently told by marketing folks and journalists
> that rewarding the right behavior isn't sexy enough to be newsworthy.
> apparently selling "a kick ass system for maintaining proper system config,
> and simplifying enterprise desktop management" doesn't work - but "scan and
> block" or "worm preventers" or "quarantine solutions" will. i think it's

People tend to be optimists. They don't expect things to go wrong. If
people were to apply the same rules to driving cars as they should apply
to running networked computers, then they would all be driving tanks [2].

> absurd, that stupid reactive approach to life. it was much easier to get
> the UNIX sys admins to adopt security mechanisms by pointing out how much
> easier they make system management, but apparently that's not always a
> good sell for the desk top folks. i don't get it.
>
I have a suspicion it has a lot to do with the way people learnt to
manage their systems securely. From what I have read of computing history,
Unix was insecure until the Morris worm. At that point of time, there
were few systems on the Internet, and most of them had competent
administrators. The next generation of administrators learnt from the
people who were bitten and was generally competent as well. This drove a
culture of security into Unix administrators.

Also, Unix offers some excellent automation tools. This generally makes
the sysadmins more tolerant to scripting and automating tasks.

There is a pretty large number of users who are growing up with Linux,
and have no clue about security either. At this point, the only saving
grace is that they are still discouraged from running regularly as root.

Microsoft made its systems easy to manage for the single desktop scenario,
by people who did not have sufficient skills or experience. This went
over into the corporate world, where single user desktops remained
common until a few years ago. Microsoft did not encourage a scripting
and automation culture either. This meant that a very large part of the
Windows administrator population is simply not familiar with the power
of scripting, and has been taught that the command line is arcane and
difficult.

They have learnt that bad things always happen, and reacting to them is
the only way to make sure things work again.

I have also seen an unfortunate tendency in home users to shrug off the
responsibility of managing their systems to the ISP or anyone else. "Not
my responsibility" is a popular refrain.

Perhaps a bit of media thrust is needed for this to be fixed?

Devdas Bhagat

[1] Default allow is easier to get new things working with than default
deny, which requires actual research into what is being done.
[2] Ignoring those SUV driving Americans.

--__--__--

Message: 6
From: "Brian Loe" <knobdy@stjoelive.com>
To: <tbird@precision-guesswork.com>,
"'Elizabeth Zwicky'" <zwicky@greatcircle.com>
Cc: "'R. DuFresne'" <dufresne@sysinfo.com>,
"'Mason Schmitt'" <mason@schmitt.ca>,
"'Marcus J. Ranum'" <mjr@ranum.com>,
<firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] The home user problem returns
Date: Tue, 27 Sep 2005 08:38:32 -0500

Maybe I can help explain: You know all of those "tech" schools you're
constantly seeing adds for on TV? Well, those schools attract and churn out
"techs" who eventually want some kind of return on their investment. They
either become IT managers or desktop support guys. Once they become managers
they immediately determine - as every good manager does - that they need to
increase head count in order to fully support the company's desktops; they
hire their fellow graduates by the droves.

So, if you offer them a system that eliminates their need to have a tech for
every 5 users you're REALLY raining on their parade!

I did this at the company before the last one, simply using tools provided
with XP Pro and AD and a little common sense - eliminating 90% of the
tickets the "helpdesk" was getting (company of 300 does NOT need a
helpdesk). At the last company I TRIED to do it, but you know, that
"Director of IT" and his "IT Manager" (his only direct report) didn't
believe me. They insisted on the desktop guys keeping their jobs AND playing
server admins when they're not doing desktop, with lots of "Cross-Training"!
They even hired me as a network guy...which they obviously needed since they
were upgrading to a 6500 - giving them 12 managed switches (that the "IT
Manager" had setup when he first came to the company)!!

That's why going into the IT field is stupid, in my view, unless your really
love this kind of work. In that case, AVOID AT ALL COSTS "tech" schools!!!
;) Hope this helps.

> unfortunately, i am consistently told by marketing folks and
> journalists that rewarding the right behavior isn't sexy
> enough to be newsworthy. apparently selling "a kick ass
> system for maintaining proper system config, and simplifying
> enterprise desktop management" doesn't work - but "scan and block"
> or "worm preventers" or "quarantine solutions" will. i think
> it's absurd, that stupid reactive approach to life. it was
> much easier to get the UNIX sys admins to adopt security
> mechanisms by pointing out how much easier they make system
> management, but apparently that's not always a good sell for
> the desk top folks. i don't get it.
>
> tbird

--__--__--

Message: 7
Date: Wed, 28 Sep 2005 13:05:02 -0400
From: Dave Piscitello <dave@corecom.com>
Reply-To: dave@corecom.com
Organization: Core Competence
To: tbird@precision-guesswork.com
Cc: Elizabeth Zwicky <zwicky@greatcircle.com>,
"'R. DuFresne'" <dufresne@sysinfo.com>,
'Mason Schmitt' <mason@schmitt.ca>,
"'Marcus J. Ranum'" <mjr@ranum.com>,
firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] The home user problem returns

This is a cryptographically signed message in MIME format.

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

Tina, if I didn't know better, I'd conclude that security is driven by
marketing and editorial calendars.

I have an entirely different take on pain versus reward than this thread
has considered.
I actually offered it up for comment yesterday during a talk I gave at a
NWW Security Tour.

If organizations offered tangible (monetary) rewards to incent users to
comply with security policy, I suspect you'd see improvements. The model
I proposed is similar to performance objectives - set goals, and reward
employees with $ at the end of a performance period based on the results
of a security audit. I call this the "reverse Cadbury chocolate"
premise. Simply put, if people will sell their passwords for a $3 candy
bar, will employees

1) protect their corporate identities
2) comply with USB access controls - all devices must be registered, and
all information recorded on removeable devices is encrypted and signed
3) participate in security education (e.g., an online tutorial that
explains phishing and ways to detect and avoid entrapment)

for $50-100 additional income every performance period?

Sorry, I can't share this with the list. Paul's somehow botched my
subscription - I can received but can't post:-)

tbird@precision-guesswork.com wrote:

> Quoting Elizabeth Zwicky <zwicky@greatcircle.com>:
>
>>
>> On Sep 13, 2005, at 12:23 PM, Tina Bird wrote:
>>
>>> i disagree. i don't know *anyone* who willingly makes a fundamental,
>>> significant change in their behavior without pain as a motivator.
>>
>>
>> On the one hand, I agree with Tina -- people change their OWN
>> behavior based on their OWN pain. On the other hand, this insight
>> leads people to some terrible attempts at training, because people
>> (dogs, cats, octopus, anything with a brain of reasonable size)
>> do not respond effectively to imposed pain. Positive training
>> methods always work better on long-term measures.
>
>
> correct, as we expect from elizabeth :-) most of the time when i'm
> presenting
> the use of endpoint enforcement techniques to system administrators
> (the folks
> who will be managing the systems) and their end users, i start by
> describing it
> as a reward system for proper configuration, rather than a punishment
> system
> against incorrect or compromised configurations. it's the same as the
> artificial ignorance approach to log management, or good ol' deny all
> firewall
> rules. the list of "things that absolutely ought to be configured this
> way" is
> shorter than the list of all possible things that should be prohibited.
>
> so of *course* most folks won't want to do that.
>
> unfortunately, i am consistently told by marketing folks and
> journalists that
> rewarding the right behavior isn't sexy enough to be newsworthy.
> apparently
> selling "a kick ass system for maintaining proper system config, and
> simplifying enterprise desktop management" doesn't work - but "scan
> and block"
> or "worm preventers" or "quarantine solutions" will. i think it's
> absurd, that
> stupid reactive approach to life. it was much easier to get the UNIX
> sys admins
> to adopt security mechanisms by pointing out how much easier they make
> system
> management, but apparently that's not always a good sell for the desk top
> folks. i don't get it.
>
> tbird
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
>

--------------ms050505090501010001080902
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII5TCC
As0wggI2oAMCAQICAw9BgzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwODA1MTMyMjAzWhcNMDYwODA1MTMyMjAz
WjBCMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBk
YXZlQGNvcmVjb20uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5B/n1wwf
w4nKx98qYyljEhe8lfyOcbMEABfJ6Mv4L0zHtGHNYcsG+LG/XfBkfSIyIz9c7fuQuF9g5INQ
UBuqUgU/pgNbxD0f1S/fr0vVSsy5lu3sGm9cKxCtt4X2Gk2tH7cxhyX7jSS3nYBWWfLBO7KE
JYtudy9VvpHJ7o9swnryxG59jfigpRz5J4iBV91RU7hfR02i9CwknEqTg5f6RpL/qc+N98yV
FXKMYCNgsj7cukwdWyVtKhZyVSGzweNSmD0g+hOKzDQTsQNO8OBTxBGdzBtaWKFnRhP17OL0
MHD65pXVOxkHIY7P2juN33rA6S1MrOjpVWwscwMFAvu7ZwIDAQABoy0wKzAbBgNVHREEFDAS
gRBkYXZlQGNvcmVjb20uY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAbuvH
odtInEaxBKW0wVlxYuPuuiFtUCpXlqhJFe+DwFiKLJtG9TjQhX1aUgFmcGzkhObb3WZGGpkM
waxXT4jKNyPkPgmjR2Cll6faFFoRnc6G5/cgnB0ZdMTXA1l2Yi6vWzJju7KUACVGxf/6Gjsl
Ys+ahFis4QK6JdPaNUyVzd0wggLNMIICNqADAgECAgMPQYMwDQYJKoZIhvcNAQEEBQAwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDgwNTEz
MjIwM1oXDTA2MDgwNTEzMjIwM1owQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJl
cjEfMB0GCSqGSIb3DQEJARYQZGF2ZUBjb3JlY29tLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAOQf59cMH8OJysffKmMpYxIXvJX8jnGzBAAXyejL+C9Mx7RhzWHLBvix
v13wZH0iMiM/XO37kLhfYOSDUFAbqlIFP6YDW8Q9H9Uv369L1UrMuZbt7BpvXCsQrbeF9hpN
rR+3MYcl+40kt52AVlnywTuyhCWLbncvVb6Rye6PbMJ68sRufY34oKUc+SeIgVfdUVO4X0dN
ovQsJJxKk4OX+kaS/6nPjffMlRVyjGAjYLI+3LpMHVslbSoWclUhs8HjUpg9IPoTisw0E7ED
TvDgU8QRncwbWlihZ0YT9ezi9DBw+uaV1TsZByGOz9o7jd96wOktTKzo6VVsLHMDBQL7u2cC
AwEAAaMtMCswGwYDVR0RBBQwEoEQZGF2ZUBjb3JlY29tLmNvbTAMBgNVHRMBAf8EAjAAMA0G
CSqGSIb3DQEBBAUAA4GBAG7rx6HbSJxGsQSltMFZcWLj7rohbVAqV5aoSRXvg8BYiiybRvU4
0IV9WlIBZnBs5ITm291mRhqZDMGsV0+Iyjcj5D4Jo0dgpZen2hRaEZ3Ohuf3IJwdGXTE1wNZ
dmIur1syY7uylAAlRsX/+ho7JWLPmoRYrOECuiXT2jVMlc3dMIIDPzCCAqigAwIBAgIBDTAN
BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0
aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK
MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX
p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB
Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl
cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD
VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as
Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe
JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT
HUb/XV9lTzGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD
b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBJc3N1aW5nIENBAgMPQYMwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwOTI4MTcwNTAyWjAjBgkqhkiG9w0BCQQxFgQUxdG2
UNDwkfWWVuECECD84/9cTV4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG
9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYB
BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECAw9BgzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBAgMPQYMwDQYJKoZIhvcNAQEBBQAEggEAS+UI4SiDeoi/YcKi
xPM8BDlCWDJHLXocjjdBXDWkz1HbZjWXWp/jnNkL1gf2xyEG0LMFP6NQ5bp05LS6CvqjGZx2
H3TNoEvPeQJ2K9hWVRC/OwJScQi+UCoKYt+jccm9kCvrLAY6E2pa8yIgdka7UdGM9P5+iPC5
bAVqsMIb+dxG85neBpJsSqelwUjKnGlVRZOdjGikmQLX62MaTGphbHKSr41pTJZHETuXSdE8
Co8kI6hYIDIkJr47bQD4je5dLG1+dlcgbxlaJNB5BAdaFKjwlcUrECTvRvPqctjipT1xTO2F
I3UEZM/i+cyEpTVgvaP6r4SzmWMPwWPOc1vATwAAAAAAAA==
--------------ms050505090501010001080902--

--__--__--

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

End of firewall-wizards Digest