On Thu, 11 Oct 2001, Owen Boyle wrote:
[SNIP]
>
> Security has to be well-thought out. Fake security is worse than nothing
> because it provides an impression of safety and so leads to complacency.
>
Totally agreed, with a security policy for the company in place defining
everything related to such security. If there is no policy in place,
there is esentially no security onsite.
> The only way to ensure security is to secure the whole machine. Our
> system is behind a sturdy firewall and other sneaky protections and we
> run a minimalist set of services (certainly no telnet, ssh or FTP) -
> http and smtp basically. We are regularly audited by third-party
> security companies and come out clean every time. The machine itself is
> in a sealed room with only LAN access from selected machines owned by
> sys-admins (who know the root password - so you've got to trust us). So
> I think we're OK (but I'd be interested to hear if there are any chinks
> in our armour).
>
There was an interesting story relating to this in the recent SANS weekly
security updates, about a sysadmin, requests a secured room for the new
printserver, he's told by the boss there is no need and no place
available, leave it out in the open, afterall, it's only a printserver.
Weeks pass, then a mgr pages him from lunch, printing works not! He
rushes in, only to find said mgr sitting at the printserver playing a
game, he had formatted the systems drive and installed DOS for his "cool
game", it was an unused system afterall, wasn't it?!
> I admit that you might want to restrict who can start apache with
> mod_ssl if there is public access to the machine but hang on a minute...
> Why would anyone allow untrusted access to a machine on which they are
> going to run a secure HTTP server? Put it another way, would you feel
> happy sending your credit card number, even over SSL, to a machine that
> any Tom, Dick or Harry can log into?
>
> In other words, if you run a secure server, you have a *responsibility*
> to restrict access to it from your side of the FW. You would be opening
> yourself to tremendous liability if you took confidential details from
> clients and processed them on a machine which was insecure. "But, Judge,
> I had a passphrase..." won't cut much ice in the courts, I fear.
>
> In summary - Only if your machine is insecure do you "need" a passphrase
> - but if your machine is insecure you shouldn't be using it as an SSL
> server. Therefore, a passphrase is a waste of time.
>
There are missing issues here;
1) limiting access, physical and cyber-wise is not enough, one has to keep
patches up on the OS, and each and every other application this system
serves up
2) the level of experience of the admin(s) is a key factor in how secure
the machine is setup from the get-go as well. And this relates to
Rachel's issue. She seems to not be too up to reading documentation, and
lacking perhaps in years of admin experience, let alone system security
awareness. I'd not and am not at this point willing to tell her "this is
ot nessecary and that is and forget this". I think until she has a proper
security policy defined and the system and network audited for security.
Has the company done a risk analysis to define what risks are present and
what risks they are willing to deal with? She is better off restarting
apaches daily or fixing her httpd.conf and perl code. Never start talking
to those lacking secific skills about what is important and what can be
tossed aside, until one is fully aware of the skills they are facing.
Never advise one to forgoe certain security issues without a full
assesment of the issues involved, never advise someone they can be lax
here and there as long as this and that are covered until you have a full
idea of the skills and degree of security knowledge they possess.
3) the systems purpose, alluded to in #1 above, is this system open to the
public? Does it run more then merely httpd? Who has access to this
system both physical as well as cyber connections? These are important
issues that determine the degree of security required for the system.
Otherwise, I agree, once all the other issues are defined, and it has been
determined this system has no on other then admin(s) able to login tyo it,
it is not open to the outside world and vulnerable to internet hackers,
and the system does not trust inside servers, she is safe to kill the
passphrase. <note the following story after my signoff, relating to such
issues>.
Thanks,
Ron DuFresne
From: Simon Gales <[EMAIL PROTECTED]>
Subject: INCIDENT: WebCertificate.com hacked
To: [EMAIL PROTECTED]
I received the following email this morning (appropriately cleansed):
>> Dear Simon Gales
>>
>> I hate to inform you that your account
>> has been hacked on webcertificate.com and
>> ecount.com. These sites have very weak
>> security protection system and the database
>> with credit cards and other personal information
>> is not protected at all. Your personal details:
>>
>> 123 Spartacus lane
>> Cary IL 23456 US
>>
>> Your credit card information:
>>
>> 1111111111111111
>> expiration time: 10/11/12 1:23:45 PM
>>
>>
>> We offered them our help many times. But top
>> management of webcertificate.com and ecount.com
>> don't care about their customers - you. They
>> care only about their money.
>>
>> zilterio
>> www.zilterio.com
>>
I've notified [EMAIL PROTECTED] and VISA, and am awaiting their
response.
Since they've apparently already been informed (albeit in a questionable
manner) and customer information already disclosed, I felt it appropriate
to forward this on to BugTraq.
Related: http://www.ecommercetimes.com/perl/story/13147.html
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior consultant: darkstar.sysinfo.com
http://darkstar.sysinfo.com
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
-- Johnny Hart
testing, only testing, and damn good at it too!
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
