This is just FYI -- do **not** panic :-).
I had multiple attempts to connect to my amindexd port from the outside
world yesterday. As far as I know (and I assume anyone in the Amanda core
group knows), there are no security problems with Amanda. Which doesn't,
of course, mean there aren't any.
So, I have two recommendations to everyone (which I've already mentioned
more than once -- this is just a pointed reminder):
* Do not configure Amanda to run as root. Use some other user who
only has enough privileges to do what Amanda needs to do.
Since "enough privileges" includes reading every file on your system
:-), you may wonder "why not root", and my answer is "if you don't
have to, you shouldn't". Running things as root just invites
problems. It's one thing to break a program running as (e.g.)
"amanda" with limited (write) access to the system. It's another
thing entirely to break that same program running as root and have
it start up any program it feels like.
Along these lines, your raw disk devices (if you're using "dump")
should not allow write access to the Amanda user. Read access
is sufficient.
* Run all Amanda services (amandad, amindexd and amidxtaped) under
TCP wrappers control.
Amandad should only allow access from your tape server. Nothing else
needs to contact it.
Amindexd and amidxtaped should only be enabled on the tape server.
The clients do not need to run them. Both services need to allow
access from all your clients. However, that only needs to be true
when doing a restore, so (if it's not a big hassle), adding the client
as it starts amrecover and removing it when done might be safer.
As I said, we don't know of any security problems in Amanda. Whoever was
poking at me yesterday may have just been playing around. But if someone
has found a hole and we haven't heard about it yet, you should do what
you can to protect yourself (good advice in any case).
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
