Bastille - blank passwords

[AndyMueller]

Ok, so this may sound rather odd, but I have been given a directive to provide some scurity hardening across a few additional servers in our footprint (we have bastille successfully running for several years on other servers).
However the application on this server will still be able to need to use telnet and ftp. Not a problem here, set that up in the config file. Now, the application also requires the use of some "blank" user account passwords, and apparently bastille can not handle this (imagine that, it IS after all a security HARDENING tool - duh). Any ideas how I may still allow users with blank passwords and run bastille? ssh is not an option, application does not support it.

Thanks in advance, Andy

[Steven E. Protter]

Shalom,

No, but you could use sftp and ssh part of openssh(HP calls it secure shell, free on http://software.hp.com) and set up password free login by exchanging public keys. Even windows users can be set up to connect without a password.

ssh-keygen -t dsa


take the id_dsa.pub file to the target server and cat it's contents to a file in .ssh folder called authorized_keys (append).

If you have already run bastille on the system, after of course putting content in those blank passwords you will have no problem with default permissions.

Secure, no password per say and makes management very, very happy.

SEP

[Bill Hassell]

Why bother running Bastille at all? Since the application requires no-password logins, anyone that can reach your server can login. Your server is simply not secure and the directive to provide hardening must be redirected at the application author. AS mentioned, you can lock down the system with Bastille and then 'fix' the special user accounts but the system would fail any security audit.

[Keith Buck]

I'm trying to figure out the best way to respond...you've already noticed the obvious oxymorons here...so I'll assume that anyone reading this will know that the constraints you are under make for a "humorous" situation in the best case.

More generally, you can "run" Bastille without making ANY changes to the system. Simply answer "No" to all the questions. So, any particular change you don't like can be avoided, and the trick is to find out which question is related to your application.

I'm still not sure why an application would need blank passwords, so it is probably not covered in the Bastille question (I wrote many of them, and didn't anticipate this).

So, here's where I start conjecturing.

#1. You are running on 11.11 (or 11.00)

#2. The way you answered the Account Security questions required trusted mode on 11.11/11.00. There are several features which require trusted mode on 11.11, fewer on 11.23, and even fewer on 11.31. I can't remember all the details of the different interactions...that's why you want to use Bastille to figure this out for you.

#3. Trusted mode, the way it is configured by default, does not allow you to set a blank password. (note that in some cases, you can have a blank password if it exists before you convert, but again we're getting complicated)

So, I would start by answering most of the Account Security questions "No" during the initial hardening process, and see if your applications work then. Next, I would look into fixing the application to work differently. In the meantime, there are still some Bastille questions that help prevent local user exploits so even if a single account is wide open, your risks are slightly reduced.

Hope that helps.

-Keith

[Robert Fritz]

Hi there,

While Keith is correct from a technical standpoint as to what Bastille does, I still think that at some point we have to be very careful when we start accepting oxymorons as "okay," especially in security. After all, who is going to get blamed if there is a security-problem, or the auditors "uncover" this?

Making a general-purpose account available to anyone that can contact the server is a very high risk. I agree with Bill on this point, and would encourage Steven's approach.

If Steven's approach won't work, you might also consider a /bin/false login shell, and a chrooted ftp to at least control what files the account can read and write.

That said, I sympathize a lot with your position. Competing "must" requirements often create strangeness if we're not careful. I wish you the best of luck, and don't envy you one bit.

[AndyMueller]

Thank you all that have replied thus far. Unfortunately I'm no closer to a solution. We are running 11.11 on the server in question. I'm caught between a rock and a hard place, whereby I have to secure a server (bastille), but still allow blank passwords for several application related accounts. It's absolutely absurd. Why bother hardening when application folks are allowed to use blank passwords? BTW, it an IBM UNiverse Database that does not support ssh and HAS to use ftp and telnet, sftp is not supported. But thanks for your suggestions and sympathy ...

Andy

[Robert Fritz]

Yes, it sounds like you're being asked to put bars and thick glass on the windows, but leave the front door open.

One last attempt:
1) I'm surprised that the DB folks can use a blank password... can you push back?
2) Failing that, can you characterize the needed commands and create restricted / chrooted shell accounts that at least limit the account to those specific commands / files that the DB needs?

-Robert