Re: Re[2]: Lotus Notes - Is this a bad thing?
From: mcl@convergens.dkDate: 08/09/02
- Previous message: Lubrano di Ciccone, Christophe (DEF): "RE: Two questions...."
- Maybe in reply to: Philip Storry: "Re[2]: Lotus Notes - Is this a bad thing?"
- Next in thread: Cavell.McDermott@apw.com: "Re: Lotus Notes - Is this a bad thing?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: Philip Storry <phil@philipstorry.net> From: mcl@convergens.dk Date: Fri, 9 Aug 2002 09:50:55 +0200
Hi Philip
> The defaults can be bad - I'd agree on that. But remember they have a
> firewall between them and the world - so things like HTTP defaults are
> less important. Only the Notes security counts if only port 1352 is
> accessible.
Well, yes and no. I agree that noone should be able to connect by HTTP to
that particular server but if users are allowed to set their own passwords
odds are that HTTP and Notes passwords will be the same for some users. I
recently did a scan of the HTTP passwords in our own environment - 20% had
obvious passwords (i.e. common words in Danish or the names of loved ones)
for HTTP login, among those our CEO. Most of those 20% had the same
password for the Notes ID. Convenience is a big risk... Now we've
double-hashed the passwords and everyone has been told to have non-obvious
passwords. I can just pray they actually do it... I plan on doing a
brute-force with obvious words on all our IDs one of these days just to see
what turns up, but it takes appr. an hour per ID to check all 500.000
words, and a lot more for hybrids, so I'll need to set aside a separate
machine for the project. When the current project is over, perhaps...
RSN... ;-)
> However, I recommend a second server be purchased if it's a permanent
> link - such a server is to be regarded as disposable, so that any
> security breaches are less serious. (Which is not to say it is to be
> any less secure.) It doesn't need to be a big server... And if they
> know enough about Notes, it can be installed into a different domain
> and certifier in order to isolate their production systems from harm.
Certainly, total separation would make it a kind of Notes-firewall which is
a Good Thing. And then only place stuff on the server that the partner or
partners are supposed to see. If it's on the server, it must be defined as
semi-public or potentially public. This would also mean that leaked
information (like the HTTP-passwords) would not necessarily compromise
anything else.
> mcd> There are a lot of checks that should be done before opening
anything and
> mcd> you'll need to check continuously for holes in the production
environment -
> mcd> there's no such thing as a permanently secured Notes, and
application
> mcd> developers (such as me) are not too disciplined in the Notes-world
so holes
> mcd> may pop up in unexpected places. We're a bit sheltered... The admins
should
> mcd> really, really mean it before they open the firewall for any kind of
> mcd> Notes-traffic. This could be a good place to go for the basics:
>
> As this is Notes only, the main things to be checked are who can
> access the server, the creation of new and replica databases, and the
> ACL's on databases. Cross-certification should also be watched
> closely, but physical security should be helpful there.
Yes, those are important, but there are some more subtle and very important
parameters that need to be addressed too, both by admins and developers. To
mention just a few:
- who can create and run agents - unrestricted scheduled LotusScript agents
can bypass the entire security model in minutes with a few simple tools.
- what kind of reader-access is granted to individual documents and who
grants it.
- who can create views and folders. It's a very effective way of bypassing
reader fields - anything (except Rich Text) will show up in categorized
columns despite restricted reader access to the documents themselves. Major
bug...
- who has control of the directory, esp. user and group creation and
modification.
- where are your ID-files...? If they're in the directory your installation
is compromised as soon as anyone can read it. Set up an escrow agent before
someone else does it for you.
- who can edit what and what databases are replicated both ways. Edits may
end up in your production system - do you want that to happen?
- what databases replicate. Watch those templates, they probably have the
same replica-ID across all servers inside and outside the organization. And
you *don't* want anyone to update your directory template for you...
> I disagree. The main fallacy here is that you're talking about
> securing against the rest of the world. A VPN may protect you from the
> rest of the world, but that associate he's connecting to has run of
> the house if you rely upon a VPN and their honesty. A VPN is no
> substitute for a secured Domino server in this environment. It would
> only take one disgruntled employee at their associates's site to be
> able to ruin a good production server.
Well, if only their server was allowed to connect, and only certain
databases replicated, it would not be a big problem if the server was
otherwise properly secured. It's just so much easier to do that with a
server with limited contents... But I agree, letting associates inside the
curtain wall certainly increases the risk of internal mayhem
proportionately with the number of possibly disgruntled employees. That's
why any information released to associates should be considered semi-public
or potentially public and any server they can access must be thoroughly
checked.
BTW, has anyone ever experienced external intrusion attempts on port 1352?
It's not something I've ever seen and I suspect Notes is not sexy enough
for anyone to consider it worth the effort to crack - yet.
Regards,
Morten Ranulf Clausen
Systems developer
Convergens A/S, Denmark
- Previous message: Lubrano di Ciccone, Christophe (DEF): "RE: Two questions...."
- Maybe in reply to: Philip Storry: "Re[2]: Lotus Notes - Is this a bad thing?"
- Next in thread: Cavell.McDermott@apw.com: "Re: Lotus Notes - Is this a bad thing?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|