[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best Practices for LedgerSMB Security



Hi Roland;

On 9/19/06, Roland Porth <..hidden..> wrote:

 I have been following the discussion regarding the LedgerSMB
security/schema upgrades to resolve long-lingering SQL-Ledger security and
reliability issues.  The effort and progress you and the LedgerSMB team have
made is most impressive.  Thank you all!

Thanks and welcome to the community.

 I am starting to setup LedgerSMB for my small business.   With regards to
data Security, could you please summarize your current recommended "Best
Practices" regarding setting up LedgerSMB in an installation requiring
remote access via the internet.

Including the various levels:

Note that the below is just a *very* brief summary.  If you want
overall best practices, it isn't a bad move to search for the PCI
Security Spec and apply it.  But it doesn't cover specific software,
so....

Server configuration (debian)

I would generally recommend having some sort of firewalling in place.
This reduces your overall security profile because you have some
control over which ports are accessible from inside or outside your
network.  In general, provide no more access than you need.  If you
don't need to access the app from the internet, for example, don't let
that happen.  If you do, then by all means do.

Apache 2 configuration

The readme and faq have information on Apache configuration.  I will
let others fill this in except to say that *do not* let Apache serve
out pages from the users directory.

SSL configuration

If you need to access the software over untrusted networks such as the
internet, require SSL for the web server.

PostgreSQL 8.x configuration

At a minimum, use MD5 authentication (set in the pg_hba.conf).

If you want to further restrict the db, you could use SSL and require
client certs, etc.  LedgerSMB does not currenty support Kerberos as an
authentication method.

LedgerSMB configuration Thanks again,

There are a few limitations to bear in mind--

1) (inhereted from SQL-Ledger.) Permissions are not pervasively
enforced.  You cannot count on the access controls to separate user
functionality.

2)  No single-sign on support (yet).

These areas are areas of continuing focus and will be reduced over
time.  All known security defects have been fixed at the moment, but
the permission model leaves a lot to be desired.

Best Wishes,
Chris Travers