N K wrote:
By default, all connections to DB are restricted by only local ones. I
use the only superuser with non-standard name and very simple password
- "one" or "two", for example. Connection to DB is established over
SSH. Is it safe such technique?
That depends on what you're using the database for. If you've got an
application using a local connection, but it's coming in as the
superuser, then any compromise in the application could lead to the
eventual destruction of your entire database. The non-standard name for
the superuser is a technique called "security by obscurity" - it can
slow attackers down, but once they figure out that name, it's wide
open. As someone mentioned, passwords such as the ones in your example
would be easy prey for a dictionary attack.
Think like a hacker - how would you circumvent the security you
currently have? How hard is it to get on the machine? Do users get
unlimited SSH attempts, or do you ban IPs after three to five failed
attempts? Do you use username/password with SSH, or restrict it only to
shared keys? Is telnet, rsh, or some other remote service also installed?
Then, at the database level, try to isolate the access of each user to
only what they require - the "least privilege" concept. The Postgres
server owner (your non-standard superuser) should not be using the
database unless you're doing maintenance that requires it. You can
create separate databases and let a different user own them. From
there, you can create separate schemas (or just one), and a different
user can own it. You can have yet another user which has be granted
SELECT/INSERT/UPDATE/DELETE on each table (and SELECT/UPDATE on serial
sequences), and this is the user that the application uses.
This might seem like overkill, and for some purposes, maybe it is. Of
course, task one is making sure the people who need to get to the data
can get to it. Once you've gotten that settled, though, it's better to
implement strong security. You may never know if you needed it or not;
but, if you don't, the time you need it will become painfully apparent.
Daniel
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
