We were broken into recently, in a minor way, and that got me thinking
about security. Our dialups are all stored in an SQL database, complete
with passwords in cleartext... a gem for a potential cracker. The
password for this database was stored in cleartext inside of my
radius.cfg, so if someone comprimised Radiator and gained access to the
system, they would be able to get the password and thus all of our dialup
customers' passwords as well.
My solution is in three parts.
The first part is, make sure Radiator is *not* running as root. If it is,
and it is broken into, your server is effectively comprimised and you
cannot trust it anymore until you do a full reinstallation.
Secondly, make sure you are using a umask when writing your logfiles...
especially password logs and packet dumps.
Finally, store your SQL database password in a seperate file, only
readable by root.
Implementation of these three ideas can be done with a simple StartupHook:
StartupHook sub { \
my ($startf) = @_; \
my ($uid, $gid); \
if (defined($startf)) { \
main::log($LOG_NOTICE,"Will not be able to read new DB password"); \
return; \
} \
umask(0037); \
unless ((undef,undef,$uid,$gid) = getpwnam("radiusd")) { \
main::log($LOG_WARN,"Couldn't find user named 'radiusd'.. running as root!"); \
return; \
} \
$< = $> = $uid; \
$( = $) = $gid; \
main::log($LOG_NOTICE,"Changed UID to $uid and GID to $gid"); \
}
And wherever you have a 'DBAuth', do it like this:
DBAuth file:"/usr/local/etc/radius.auth"
And make sure the permissions on radius.auth are thus:
-r-------- root root
Here's an explaination.
When Radiator starts up, it starts as root. It is therefore able to read
the database password out of your 'radius.auth' file. Once the
configuration is read, the StartupHook is executed. This causes the real
and effective UIDs and GIDs to be switched to 'radiusd', and a fairly
restrictive umask to be set. Now, all log files created *after startup*
will be written with these permissions:
-rw-r----- radiusd radiusd
This way you can have people be a member of group 'radiusd' and be able to
read your logs, but if some *other* daemon was exploited on your system
(you weren't running them as root, were you?) the cracker wouldn't be able
to read these logs.
But most importantly, a 'cracker' who gains access through radiator won't
have access to the DBAuth password, becuase user 'radiusd' isn't allowed
to read that file.
Note these caveats:
- Logfiles _created_ at program startup, notably LogFile, will be created
with root permissions, and without the umask. This is *not* the case for
existing files, which will keep their original permissions; nor is it the
case for logs created *after* startup, for instance if you make a new log
file every day or every month. So, this should only creep up if you are
just running Radiator for the first time.
- The PasswordLogFile is *not* protected by this scheme. It would still
be possible for a cracker to gain access to this file, and thus your
users' passwords. There is no *simple* solution to this problem, that
would yet allow you to keep these logs. One solution would be to make a
FIFO on your filesystem and have a seperate daemon reading from it and
logging it, and just point your PasswordLogFile to that FIFO. But that's
getting fairly complicated.
- The cracker would gain access to your Client Secrets, so you might want
to put those in files as well... make the permissions identical to your
radius.auth file.
I hope that these suggestions will help give you all ideas on securing
your systems.
- D
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
