----- Original Message -----
From: "Vic Parat (NSS)" <[EMAIL PROTECTED]>
To: "Tim Greer" <[EMAIL PROTECTED]>
Sent: Wednesday, July 02, 2003 2:51 PM
Subject: Re: Ten least secure programs


> Against my better judgment I'll respond with just a few things, although
> off-list since this no longer SF relevant.

Don't worry, none of these type of arguments (though there's no reason why
it needed to be one) don't go on the list anyway.  As for SF relevant, as
for the topic at hand anyway. it wasn't once the discussion went from actual
programs to adding other variables to the circumstances.  Anyway, for
relevance, due to points made here, albeit I am perhaps coming off a little
hostile now--due to arrogance and accusations to save (your own) face), I
will post to the list, which will never make it anyway (so don't worry).
And yes, I genuinely think people should be aware of when someone at an
alleged security firm isn't qualified.  And no, this isn't about MS.

> My whole point was that this top ten list was highly subjective and that
> insecure programs were really in the hands of the beholder /*again my
> opinion*/.

In a way, that's correct.  However, in other ways it's not anything that can
be argued.  If you compare two programs and one is (a quick, lame Perl
example):

Example A:

chomp(my $helloworld = shift || '');
system("echo $helloworld");

And another is:

Example B:

chomp(my $helloworld = shift || '');
die "Forget it, pal!\n" if $helloworld !~ /^\w+$/;
system("echo $helloworld");

Then there's nothing that's left to "opinion".  Indeed, some things are, and
it depends--but that's not what was being discussed.  But don't mistake what
I'm saying to simply be me arguing because I don't like what you have to say
and I can't deal with it, it's nothing but the facts.  The fact is, Example
B, provided there's nothing else added, is secure.  It's not going to be
insecure out of the blue.  Nothing is going to happen, there's no bugs and
there's no way someone can exploit it.  Example A is downright, 100%
exploitable.  If that's suid root, say good-bye to your system.  Again, a
lame example in Perl, but serves the point that comparing programs/scripts
alone, illustrates that some are insecure and some are not.  Obviously these
are so basic, it's pathetic, but these are the problems, ultimately, with
many programs and many scripts people mention--people just blindly accepting
input and to system calls or who knows what.  It also shows that program vs.
program, Example B is more secure, and example A would make the list of
insecure programs.

> You can blast me all you want but I believe that IIS can be made
> just as secure as Apache.

Well, common sense dictates that's not true.  Since you have no ability to
see the source code, albeit it can help protect any holes from being found
in the first place, you do not have the ability to fix it.  Okay, so there's
patches, but you don't have the ability to modify it for other reasons of
security?  Are you a security guy or not?  Are you a programmer also?  If
you're not, how can you dare claim that a program you have no ability to
modify can be just as secure as one you can?  It's not logical, it really
isn't.  It is *possible* that IIS can be as secure as Apache, but we don't
know this.  We only see a ton of exploits.  And, far many more than Apache
has.  And, these are not things due to configuration or lack of competence
from sysadmins, but IIS itself.

If Apache had that record of problems with it's actual program, it wouldn't
be as popular as it is... then again, since anyone that can program well and
understands it can fix it and modify it into a quality web server that's
secure anyway (no small feat, for sure, if that was the case), then who
knows... oh, that is what Apache is... before this when it was known as
CERN, when Apache was designed around that idea... now CERN is dead and
Apache is huge... there's a reason for this.  I'm so sick of people being
either mindless MS bashers or mindless MS supporters.  Calm down about it.
After all, you nor I built it.

Use what you like, but don't deny that one's better quality of more secure
than the other, simply because you happen to have no basis to support the
idea that IIS is better.. It's not. Why does that bother you?  I admit, I
question your competence since you use it--no sys admin dealing with
security would.  I question your qualifications and for good reason.  If
your boss makes you and you like the features, so be it, but to argue with
people and scream it's just as good or better is ridiculous.  Be stubborn
all you like, it doesn't matter.  You can just get angry and try and make
fun of anyone that makes a point contrary to your own baseless views, but
the facts are facts.

> Same with close source vs. open source.

Yes and no.  Like you mentioned, the reputation and history of the company
that creates it, as well as the product.  MS IIS is lose, lose.  How anyone
would find a reason to deny that, is beyond logic.  And, like I said, not
knowing what's 'under the hood' bothers me.  If I didn't know how to program
or about security, I suppose it wouldn't make a difference.  Do you see how
you claiming the things you have claimed makes me question your
qualifications, since you don't seem to think it matters?  Again, that
doesn't mean I think closed source is a bad thing, or that closed source is
more insecure, but MS IIS is closed source and highly insecure.

> And I
> believe that you really cannot have a top ten list of insecure programs
> without making such points.

Sure you can.  What programs have the most issues recently and throughout
their product history.  How major are the current, recent and past issues.
How is the program's quality now?  Is is improved?  No, IIS hasn't.  They
patched holes, but more come out all the time.  Once every few months Apache
has an issue, but IIS is weekly.

>  It was meant to be brought to the table for
> discussion.  Nothing more, nothing less.

But we were talking about programs in their current state.  Thus, closed
source or not, is not the point.  The point is how insecure the programs
are, as they are.. .. Yes, that includes how they are when secured properly
and configured well--it would be ridiculous not to.  However, you are acting
like that's the reason.  it's not. IIS and Outlook, etc. have a history of
problems that have no relation to how it was configured.  Even the big
exploits and history of Sendmail and BIND were caused mostly because people
didn't take the proper measures to set them up right.  I.e., jailing BIND
and having it drop privileges.  Most people still don't and BIND had done
this themselves in later versions of 8.x and up.  I'm not saying those
programs couldn't be exploited like IIS, if it were 'just configured
better', but that would have minimized and sometimes completely prevented
it--not to mention people that patched it themselves and choose to run in
safer--which you can not do in Windows, but can on *nix flavors.  Don't get
so upset that there's more control and better options with an OS/kernel and
dist you personally aren't skilled with.

> I'm not going to respond to your
> other comments.

Who cares, you are just blurting out your opinions anyway and refusing to
accept reality... why such an arrogant response?  Don't like being wrong or
skilled?  Educate yourself and strive for better alternatives and gain the
knowledge.  Had everyone done this, we'd all be on some *nix system and not
have these problems.  Get offended all you like, but you have some nerve
with your arrogant attitude and then get on my case for telling you the
facts.  Again, see it as me being defensive all you like, but your signature
and claims and refusal to accept the facts, you may be as big a joke as
whathatsec.  And please don't bother with the "I'm more mature" bullshit.
You posted untrue things, I posted how they aren't correct.  You're
genuinely not making any sense or valid points.  If that pisses you off,
find a line of work where people don't question you, or pray your employer
doesn't find out.


> Vic Parat, Sr. Security Architect
> Network Systems Security, LLC
> www.nssecurity.com

And no, before you ask, knowing HTML doesn't qualify you as a security
expert.
--
Regards,
Tim Greer  [EMAIL PROTECTED]
Server administration, security, programming, consulting.

>
> ----- Original Message -----
> From: "Tim Greer" <[EMAIL PROTECTED]>
> To: "Vic Parat (NSS)" <[EMAIL PROTECTED]>; "Chris Berry"
> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Wednesday, July 02, 2003 1:40 PM
> Subject: Re: Ten least secure programs
>
>
> >
> >
> >
> > ----- Original Message -----
> > From: "Vic Parat (NSS)" <[EMAIL PROTECTED]>
> > To: "Tim Greer" <[EMAIL PROTECTED]>; "Chris Berry"
> > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> > <[EMAIL PROTECTED]>
> > Sent: Wednesday, July 02, 2003 1:25 PM
> > Subject: Re: Ten least secure programs
> >
> >
> > > Phew!  What a mouthful!
> >
> > Okay...
> >
> > > I can tell where this is going but I seriously
> > > doubt it would have any educational aspects to it,
> >
> > I don't think it's had that quality for a while.  If you can't deal with
> > your claims being responded to without taking it personally, I'm not
sure
> > what to tell you.
> >
> > > which is why we're all
> > > here.
> >
> > I'd have thought so, but arguing about how some people lack skills for
> > configuring and installing programs somehow reflecting on a program
itself
> > being insecure, really didn't help with that goal either.
> >
> > > Anyways, since you are apparently the greatest programmer that has
> > > ever lived, I thank you for your enlightenments.
> >
> > If you say so.  Apparently I'm an arrogant programmer because I don't
> agree
> > that every program out there _must_ be insecure to actually exist.  If
you
> > can't manage to code a secure program, maybe you should take some
courses.
> > Just sitting there and being content to blurt out these ridiculous and
> > untrue things, doesn't make them so.  The fact you claim it, ultimately
> just
> > means that logic alone dictates that you aren't qualified to make those
> > claims.
> >
> > I'm serious, I'm not saying it to offend you and I'm not doing like you
> are
> > below, and just handing out sarcasm and insults, because I feel insecure
> > about not actually knowing about the subject matter.  But if you refuse
to
> > believe that, you will likely never see the irony and the actual problem
> > being just that.  Think what you want, you're not the first to pretend
to
> > know.  We have enough arm-chair experts, which accounts for all the
> problems
> > with programs and why we're having this debate now... and why it's even
> > turned into a debate.  Try and be more original.  I.e., put up, or shut
> up,
> > ego and empty claims don't impress me.
> >
> >  > Just don't kick the dog when you get home;-)
> >
> > Hey, good effort.  And, it's better than making a valid point anyway.
> >
> > > Vic Parat, Sr. Security Architect
> > > Network Systems Security, LLC
> > > www.nssecurity.com
> >
> > I don't buy it.  No security expert would be making such ludicrous
> > statements.  I didn't mean to hurt your feelings, but if you are going
to
> > claim to run a security company, you should probably learn more about
the
> > field and subject matter.
> > --
> > Regards,
> > Tim Greer  [EMAIL PROTECTED]
> > Server administration, security, programming, consulting.
> >
> > >
> > > ----- Original Message -----
> > > From: "Tim Greer" <[EMAIL PROTECTED]>
> > > To: "Vic Parat (NSS)" <[EMAIL PROTECTED]>; "Chris Berry"
> > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> > > <[EMAIL PROTECTED]>
> > > Sent: Wednesday, July 02, 2003 12:46 PM
> > > Subject: Re: Ten least secure programs
> > >
> > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Vic Parat (NSS)" <[EMAIL PROTECTED]>
> > > > To: "Tim Greer" <[EMAIL PROTECTED]>; "Chris Berry"
> > > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>;
> > > > <[EMAIL PROTECTED]>
> > > > Sent: Wednesday, July 02, 2003 12:06 PM
> > > > Subject: Re: Ten least secure programs
> > > >
> > > >
> > > > > Not really interested in starting the "Apache vs. IIS" war but
> making
> > > the
> > > > > secured IIS vs. unsecured Apache comparison (no OS remember?) is
not
> > "a
> > > > > weird argument to make", especially concerning this thread.
> > > >
> > > > I think is very much is.  After all, what does a default install
have
> to
> > > do
> > > > with how secure the program is?  We're talking about the programs,
not
> > the
> > > > quality of administration skills or configuration.  That is the
> essence
> > of
> > > > how secure a program is or not, not the lack of skills of the person
> > that
> > > > set it up.  If that was the case, this discussion is utterly a moot
> > point,
> > > > since everything is now 100% dangerous, unless it was a program that
> was
> > > > 100% secure and didn't _allow_ the user to mess with it.
> > > >
> > > > > I find it quite
> > > > > relevant in that the only true difference between a secure program
> and
> > > an
> > > > > insecure one is proper configuration /*my opinion*/.
> > > >
> > > > That is ridiculous.  That is the difference between a "secure
> > > configuration"
> > > > and a "non secure configuration".  Configurations may be limited by
> the
> > > > program, or be poor(er) by default, but that has no bearing on how
> > secure
> > > > the program itself is.  We are talking about programs, which are
> > insecure
> > > or
> > > > not, and by how much, not "what if this program wasn't configured".
> Tat
> > > can
> > > > be true of anything and we can even discuss ways to make any service
> > > > insecure and this discussion is completely irrelevant.
> > > >
> > > > > Even with proper
> > > > > configuration, no program is void of bugs/vulnerabilities,
> > > >
> > > > That's not true at all.  It depends on the quality of code, who
coded
> > it,
> > > > the design, what the code does, how it works and then configuration
> and
> > > how
> > > > it's run.  To say that no program is void of bugs and exploits is
> > > senseless.
> > > > Many programs have no history of bugs or exploits.  Sure, there's
> > usually
> > > a
> > > > bug somewhere in most programs, but not all of them.  Some bugs are
> > major
> > > > and some are very minute.  As for exploits, more programs lack
> exploits
> > > than
> > > > bugs.  A bug is one thing, but an exploit is another.  It's
> sickeningly
> > > > simple to secure a program, even if it does have a small bug
> > somewhere...
> > > if
> > > > there's even a bug at all.  The mentality to say that no program is
> void
> > > is
> > > > security issues is ludicrous!  And please don't sink to that "It's
> only
> > a
> > > > matter of time until someone finds one" as if it's simply not
possible
> > to
> > > > have a secure program.
> > > >
> > > > > some just have
> > > > > not been discovered yet.
> > > >
> > > > Oh, there we go *deep friggin' sigh*... I knew that was coming.
> > > >
> > > > > Now what I do find to be a weird argument is the
> > > > > amount of configuration an OS (damn forgot about the no OS thing)
> > allows
> > > > one
> > > > > to do.
> > > >
> > > > Why?
> > > >
> > > > > Not trying to start the "Open Source vs. Closed Source" war
either,
> > > > > but just because you can hack the kernel in Linux doesn't make it
> > > anymore
> > > > > secure.
> > > >
> > > > No, I didn't claim it did mean that.  But it means that you *can*
> secure
> > > it,
> > > > if it's not, because you have the *ability* to do so.  You can
review
> > the
> > > > code and see potential or existing holes and fix this, you can
modify
> it
> > > to
> > > > work in the most secure manner.  This is a fact, there's nothing to
> > debate
> > > > about it.  Sure, most people can't do this due to lack of skills,
but
> > that
> > > > doesn't change the fact it matters.
> > > >
> > > > > That's left in the hands of the sys admin
> > > >
> > > > Or any home user that has the skills.
> > > >
> > > > > and yes you can do plenty
> > > > > to MS NT based OSs to make them just as secure as any Linux box.
> > > >
> > > > I'm not sure what is so confusing about this.  You can't just blurt
> out
> > a
> > > > statement and think that makes it so.  If you can't modify the
source,
> > you
> > > > can not have the same amount of control.  You rely steadily on the
> > skills
> > > of
> > > > those whom developed and built the kernel.  You can't change it.
With
> a
> > > > Linux kernel, you rely on people too, but can fix, improve and
modify
> it
> > > > (provided you have the skills).
> > > >
> > > > > And you
> > > > > can do plenty to make them insecure as well.
> > > >
> > > > Yes.
> > > >
> > > > > Now if this list is about "insecure programs, nothing more,
nothing
> > > less"
> > > > > then why are items like telnet listed?
> > > >
> > > > I asked the same thing... Anyway, telnetd has had a history of some
> > > security
> > > > issues, if that helps.
> > > >
> > > > > Whose telnet, Sun's,Linux's,MS's?
> > > > > Telnet is a lot more then a program and so is nfs, rlogin, rsh,
etc.
> > I
> > > > > think that this list does have some merit but it should definitely
> not
> > > be
> > > > > taken at face value.
> > > >
> > > > I agree, and we should be discussing the topic then--programs... not
> > > > configurations, not "if you keep it continually patched it's okay"
and
> > not
> > > > protocols or misusing a program.  If the program can have it's
> > limitations
> > > > defeated to open a hole in a manner that would result in any type of
> > > > compromise, then it's insecure to some degree, depending on what
that
> > is.
> > > > Hence, being listed.  Hence; MS IE, Outlook, IIS, BIND, Sendmail,
PHP,
> > > > Apache, Exim, you name it... not some though (take note)l such as
> > TinyDNS,
> > > > Qmail, Perl, etc.  Now, my previous comment that all programs aren't
> > going
> > > > to be exploitable is true.  However, do not construe that to mean
that
> > I'm
> > > > claiming there's no exploit waiting to be found in the (as far as we
> > know
> > > > right now) secure programs I just listed.  I know programs I code
are
> > > secure
> > > > and it's due to how they are coded and built.  I'm not being
arrogant,
> > > it's
> > > > simply a matter of only allowing specific things to happen or be
done,
> > and
> > > > checking.  So, I can only say this about my own programs for
> certain...
> > > > though I admit it's possible I could have opened a hole and never
knew
> > or
> > > > saw it--but I seriously doubt it given how I code and compile
programs
> > and
> > > > how they will run.  In other words, the simple matter of the fact
is,
> > most
> > > > of the programs mentioned that *are* insecure (or have a history of
> > being
> > > > insecure) were a direct result of simply having common sense
checking
> in
> > > the
> > > > programs... really.
> > > >
> > > > > But anyways I can feel Chris Berry thinking this is not what he is
> > > > > interested in so then I will go ahead and post my own question to
> the
> > > > list:
> > > >
> > > > Okay, I did the same.  That's what we're here for. :-)  Though I
admit
> > all
> > > > the semantics and ridiculous claims and scenarios are really just
> > wasting
> > > > everyone's time.
> > > >
> > > > >   What are your ten top criteria's for evaluating a tool (program,
> > > > service,
> > > > > protocol, etc) in terms of security?
> > > >
> > > > That's too broad.  There's too many variables involved.  You have to
> > test
> > > > and check everything from how it's run, to the user it runs as, what
> it
> > > > accepts for input, what it outputs, how it functions, if it creates
> any
> > > temp
> > > > files and so on... the purpose intended for it to serve and so, so
> much
> > > > more.
> > > >
> > > > > Is the amount of coverage on SF your only one?
> > > >
> > > > Heck no.
> > > >
> > > > > What about product support?
> > > >
> > > > For my own programs or for one's I use?
> > > >
> > > > > Vendor history?
> > > >
> > > > Certainly, though product history of the program I'd be using would
be
> > > just
> > > > as or more important, assuming it's open source and I can see,
review
> > and,
> > > > if need be, modify the source.
> > > >
> > > > > Open source vs. closed source?
> > > >
> > > > I would never, ever, use closed source given a choice.  I do on my
> home
> > > PC,
> > > > but not anything that would run an Internet service.
> > > >
> > > > > Corporate policy?
> > > >
> > > > That depends on the policies.  The most secure program/service is
the
> > > > ultimate goal.  I'm not sure how policies would change that, other
> than
> > a
> > > > manager refusing to use something they haven't used before or
> whatever,
> > > and
> > > > that is something you can try and change but may not be able to.
I'd
> > just
> > > > not get in a situation like that or work with some company that
didn't
> > > have
> > > > common sense.
> > > >
> > > > > Cost?
> > > >
> > > > Not an issue, I use open source software personally, so I can see
how
> > it's
> > > > coded/built and review the code and modify it if need be.  No, that
> > > doesn't
> > > > mean I think all closed source programs are a bad thing, I just do a
> > great
> > > > deal of things and never needed to go with that alternative.
> > > >
> > > > > Vendor reputation? ???
> > > >
> > > > Of course.
> > > >
> > > > > Do you even have a formal set of criteria's that a
> > > > > tool must meet in terms of security or do the bean counters make
the
> > > > > decisions for you?
> > > >
> > > > Use what's the most secure in regards to history of the product and
> > review
> > > > the code, configure and run it as securely as you can and so on...
> that
> > is
> > > > all that can be done.  What about creating your own programs, so you
> > don't
> > > > have to relay on people finding exploits that shouldn't exist if a
> coder
> > > > used common sense with information that has been available and out
> and
> > > > public for decades?
> > > >
> > > > > //I have my anti-flame suit on too so fire away
> > > >
> > > > Sweet.
> > > >
> > > > >
> > > > > Vic Parat, Sr. Security Architect
> > > > > Network Systems Security, LLC
> > > > > www.nssecurity.com
> > > >
> > > > Security firm...? Seriously?  If so, why in the world would you be
> > arguing
> > > > the points you did above?  I don't mean to sound like a jerk, but I
> > don't
> > > > get it...
> > > > --
> > > > Regards,
> > > > Tim Greer  [EMAIL PROTECTED]
> > > > Server administration, security, programming, consulting.
> > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Tim Greer" <[EMAIL PROTECTED]>
> > > > > To: "Vic Parat (NSS)" <[EMAIL PROTECTED]>; "Chris Berry"
> > > > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>;
> > > > > <[EMAIL PROTECTED]>
> > > > > Sent: Wednesday, July 02, 2003 10:31 AM
> > > > > Subject: Re: Ten least secure programs
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Vic Parat (NSS)" <[EMAIL PROTECTED]>
> > > > > > To: "Chris Berry" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> > > > > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > > > > > Sent: Tuesday, July 01, 2003 12:28 AM
> > > > > > Subject: Re: Ten least secure programs
> > > > > >
> > > > > >
> > > > > > > I would definitely question some of your choices (is Apache
more
> > > > secure
> > > > > > than
> > > > > > > IIS?)
> > > > > >
> > > > > > Yes, very much. :-)
> > > > > >
> > > > > > > but I think top honors for "the ten least secure computer
items"
> > is
> > > an
> > > > > > > under qualified system administrator.
> > > > > >
> > > > > > I agree 100%.  This is also why all the programs mentioned as
> > insecure
> > > > > too,
> > > > > > those pesky humans!
> > > > > >
> > > > > > Anyway, while I agree with you, the fact remains that the
programs
> > > > > > themselves differ from problems, one more so than the others.
> > Surely
> > > a
> > > > > > secured Windows server is more secure than a non-secured Linux
> > server,
> > > > but
> > > > > > that's sort of a strange argument to make.
> > > > > >
> > > > > > This thread is about insecure programs, nothing more, nothing
> less.
> > > > > > Sometimes they are more insecure than others due to a common
> > > > configuration
> > > > > > error or default setting and that comes down to a lame sys
admin.
> > > > Really
> > > > > > though, how many people are really even qualified sys admins?
> > > > > >
> > > > > > Anyway, the point being, some programs are far more exploitable,
> in
> > > > their
> > > > > > default or highly configured state, than others... when
comparing
> > them
> > > > as
> > > > > > default to each other, as well as configured well, to each
other.
> > > Then,
> > > > > > comparing them.  Also, mind the fact that depending on what
you're
> > > > talking
> > > > > > about, some of them don't allow you to have the control to
> configure
> > > > them
> > > > > > and are thus insecure.
> > > > > >
> > > > > > For example, Windows only allows to much.  There's a lot you can
> do,
> > > but
> > > > > > mostly a lot you can not.  Whereas a Linux of FreeBSD system,
you
> > have
> > > > > much
> > > > > > more you can do, right down into hacking the kernel however you
> > want,
> > > > and
> > > > > > even if far more involved of a process and much more skills
> needed,
> > > it's
> > > > > up
> > > > > > to the person and their skills to configure, hack and use their
> > skills
> > > > to
> > > > > > make the server/system far more secure than say a Windows system
> > > doesn't
> > > > > > allow.
> > > > > >
> > > > > > Personally, I find that a default Windows set up is about as
> > insecure
> > > as
> > > > a
> > > > > > default Linux set up.  Both need to have a lot done, but you can
> do
> > a
> > > > lot
> > > > > > more with a Linux  system.  Do most people have the time, let
> alone
> > > the
> > > > > > comprehension?  Surely not, so we go back to your comment about
> > > > > unqualified
> > > > > > sys admins.  I couldn't agree more.  However, two qualified sys
> > admins
> > > > > > skilled in their respective areas, the Linux sys admin can do
> more,
> > > > unless
> > > > > > that Windows sys admin is privileged enough to be offered the
> > Windows
> > > > > source
> > > > > > code to review and modify to locate and close any potential
holes.
> > > > > > --
> > > > > > Regards,
> > > > > > Tim Greer  [EMAIL PROTECTED]
> > > > > > Server administration, security, programming, consulting.
> > > > >
> > >
>


---------------------------------------------------------------------------
Evaluating SSL VPNs' Consider NEOTERIS, chosen as leader by top analysts!
The Gartner Group just put Neoteris in the top of its Magic Quadrant,
while InStat has confirmed Neoteris as the leader in marketshare.
     
Find out why, and see how you can get plug-n-play secure remote access in
about an hour, with no client, server changes, or ongoing maintenance.
          
Visit us at: http://www.neoteris.com/promos/sf-6-9.htm
----------------------------------------------------------------------------

Reply via email to