Bastile Script....

[Jeff Carlin]

I tried the Bastile perl script, but I dont have the curses library so couldn't run it in text mode. When loading the server, I did choose X11 so there was no way to run the HP Bastile script. Why the heck would HP release Bastile as perl instead of a c program or a shell script? To run Bastile, you have to load up so much on your system which is the opposite of how lean you want a Bastile host!

[harry d brown jr]

AH. The bastille script is intended to be run on systems that weren't originally set up to be bastile servers, therefore there were probably some "assumptions" made about what features/products would and wouldn't be loaded.

Personally I use the bastile document and do it manually.

live free or die
harry

[Keith Buck]

It looks like you have several questions...let's see if I can answer all of them.

1. 'Curses library' error: I'm not totally sure here, but you probably just need to set your DISPLAY variable. Bastille doesn't require your machine to be running an Xserver (i.e. have a graphical monitor), but it does require an X client. You can then see the GUI on any Xserver running Linux or ReflectionX or whatever.

Now, the best way to do this is using Secure Shell and X11Forwarding. (I know, this is yet another thing to load, but you really do want it on your Bastion host). Grab T1471AA from software.hp.com. If you need more instructions, write back.

The Perl-Curses CPAN module doesn't work too well on HP-UX, so we decided to stick with the GUI for now. (it's really a lot easier to use anyway)

2. 'Why would HP release this as a Perl?' Bastille is actually an open source program released under the GPL. It was originally written for Linux, and we extended it to HP-UX (including additional content). Bastille really is the best program out there for this sort of thing. We also got a lot of customer feedback indicating the importance of being able to read the code to find out what it was doing to their system. This is much easier in Perl/shell, since we don't have to distribute the source separately, etc.

3. 'you have to load up so much on your system' - The _easiest_ way to run Bastille is indeed to load Perl 5.6.1.E onto your system, which includes Perl/Tk libraries for the GUI. You can then run the GUI and make choices for your individual system.

If you prefer the hard way, you can create a config file on one system, then copy it to another system (see user's guide distributed with Bastille) and run 'bastille -b' to apply that configuration to the other system.(systems should be similar). Or, you can create one by hand...but that gets even more difficult. You can do this on a machine with only a text console. (Yes, you still need Perl...sorry about that.)

If you are really concerned about Perl, you can remove it after you're done with the initial hardening process.

I hope that helps. If I missed something, please write back.

-Keith

[robert fowler_1]

I think the point is that if you wish to harden a server that doesnt have the HP X windows running and doesnt have access to a second box to install a x client on how the hell do you get this working.

Or am i missing something ??????

[Jeff Carlin]

I hardned the server(s) the old-fashioned way: by hand. Personally, I think it is obsured to be required to load up a server to run a script whos purpose is to lock down the system and lighten up the software load for security.

Perl is neat, fun and a hip new way to script, but there are times you don't or shouldn't use it just because you can. This is one such example. Securing a server should be done in the trimest way possible - it should have been done in sh or ksh or a compiled binary and written to use text only so it could be run from the console.

My $.02