I need to install RHEL4u5 on a standalone server using the http install method. The new server being built is on an open network. Placing it on a private network for the duration of the install is not practical.

If I were installing from CD-ROM. I'd just unplug the network cable during install until I'd hardened the server.

But this is not an option, since I need to use the http install method in this case (after booting with a boot.iso on local media).

So the question is, during the http install phase, up until the "Reboot Now" screen, how worried should I be about the security of the box I'm building?

Other than packet-sniffing at the switch, are there any known exploits for this phase of installation?

Thanks for any insights or references for RTFM'ing.

quantsuff

Once network is up and running iptables should be up and running as well. Limiting network traffic to your HTTP source should work. If you add external repos during the install stage you should add those as well of course. Before you go for the initial reboot "chkconfig" to make certain only services except vital for remote management are up (only SSH AFAIK) or configure the firewall to only accept traffic between the box and your management IP (range).

I ended up doing the http install as below - nothing special, but it did involve physically touching the server a couple times:

---Anyone else have other suggestions for next time?

-boot with local boot.iso
-install from http install server
-disconnect network cable
-reboot
-inspect iptables file to verify only port 22 allowed (it was)
-configure hosts.allow, hosts.deny to only allow my workstation to connect
-configure sshd_conf to allow only my userid to ssh in
-restart sshd
-reconnect network cable, ifup
-connect to satellite server and patch
-continue with normal post-build tasks

sprinkle several reboots in with the above steps

Check out Kickstart - as well as preseeding the installer settings with a Kickstart file, you can specify scripts to run post install. From memory, every RHEL installation automatically creates a Kickstart file in /root. RHEL also includes a graphical tool for generating/editing files in the Kickstart format (system-config-kickstart, I think).

Thanks, I do use Kickstart on some servers, but usually it's on a secured network that we control, end-to-end.

What I was wondering in the original post was how safe from intrusion the box is during the http install process on a non-secure network (regardless of whether the install is being run by Kickstart or by a human).

The way I understand the network install, Anaconda is running in an instance of linux that booted off the install server. It's talking on the network via http to the install server. I was wondering if anyone has information on how vulnerable this special install environment might be on a wide-open network, during the time the install is running.

I assume it's stripped-down and fairly secure, but I've never read anything one way or another.

There's telnet and VNC functionality built in to Anaconda for remote access to the installer system, but IIRC you have to explicitly switch them on with boot flags.

I suspect that the only issues with an open network are a bit theoretical - how to ensure that the installer is actually talking to the server you think it is, and not receiving evil software from a compromised server.

My memory of Anaconda is growing fuzzy, but I think that the boot.iso just loads enough of an operating system to grab the main Anaconda software from your install server, and Anaconda in turn grabs RPMs from the server when it gets to that point in the installation routine. Obviously, Yum is very strict about package digital signatures, but I don't know about the package installation code used by RHEL 4 Anaconda, or whether the code on the boot.iso verifies the Anaconda software it fetches. If you can't find anything in the docs, you could ask on the Anaconda mailing list (politely of course). The developers post there, but many of the regulars have read and tinkered with the source code.