this is rather fast and loose, and there are some things obviously missing or glossed over. please, ask questions.
notes: i make a lot of assumptions in this. mainly, that the person reading it has a clue as to how to modify startup scripts, where logfiles live, how to build and install apps, etc. basic system administration stuff. the other thing is that this isn't specific to redhat. it isn't even specific to linux. this is the m&m/reece's peices approach to security. for the sake of brevity, and the fact that most servers people build have a single user, or a handful of trusted users, we are going to be hard and crunchy on the outside, soft and chewy on the inside. i won't touch on local security issues, nor will i get in to things like securing ftp, apache, etc. those are seperate discussions. ideally, you would run this server in an environment that includes a firewall and an ids system. all systems should have synchronized clocks. this is essential if you ultimately need to gather any forensic information that will be presented in any type of legal situation. before i get into it, one last thing: use strong passwords. again, USE STRONG PASSWORDS. ideally, your passwords, especially root, should appear as if they are line noise. you know, the garbage you would occasionally see when dialing up 300baud bbs's on your apple II with a catmodem and a really really bad peice of copper. heh. good password? bHf@4!jX. passwords are your first line of defense. if you can use some kind of token-based or one time password system, all the better. pre-install: 1. determine what services you _need_. is this going to be a web server? what additional services besides the actual web server do you require? php? perl? tomcat? 2. determine what services you _do not_ need. off the top of my head, some things you don't need are vim, vi, emacs, elvis, pico, kde, gnome, all of x for that matter, language sets, compilers other than gcc, etc. if you don't need it, don't install it. if you don't know if you need it or not, _find out_. do a google search on the package in question. take notes. 4. acquire additional tools. download the following tools and put them on portable media (cd-rom is best). lsof, nmap, tripwire/aide/L5, swatch/logcheck and openssh. some of these tools will be installed on the server being installed, others will be run from seperate machines as well (nmap). http://www.tripwire.com/downloads/tripwire_asr/ http://www.psionic.com/abacus/logcheck/ ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/lsof.tar.gz http://www.insecure.org/nmap/ install: 1. don't use the default install options. ever. the redhat "server", "workstation", and "hackme" options are not ideal. use the "custom" or "expert" option and hand pick the packages you want installed. under redhat, this isn't ideal, because of funky rpm interdependencies that still cause you to install stuff you don't really need. this is one reason why when i need to build a linux box i usually use slackware. it's simple, clean, and doesn't include the latest cutting edge versions of things you don't want on a server anyways. it still isn't ideal. 2. do _not_ install the machine on the wire. install it either offline, or on a net you have 100% control over. back in the days of sunos4.1.3/4 our favourite pastime was to look for newly installed machines announced in the newsites newsgroup and then (you guessed it) compromise them before they were secure. you saw what icky posted in regards to rhosts? sunos used to ship out of the box to trust all hosts. su bin, rlogin, su root. i have had machines compromised after a fresh install on internal, trusted networks. if you don't have 100% control over the local net, don't do it. your coworkers are evil. first boot: 1. disable everything in inetd.conf. you don't need it. sure, you can run tcpwrappers and all that, but running tcpwrappers is a stopgap, not a solution. ip addresses can be spoofed. 1. install the tools you downloaded and stored on portable media. 2. nmap the machine, scanning all ports (not just the trusted ports and handful of non-trusted ports nmap scans by default). just add -p1-65535 to the nmap command line. 3. jot down anything that is listening. do you need any of that stuff? if you recognize something and know what it is, go ahead and disable it. nmap only gives hints as to what is listening on a given port, mainly from the exhaustive services file that comes with it. 4. run lsof and look for anything listening. read the man page. you can tell lsof to list the names of processes that have open ports, the port they are listening to, and all other kinds of goodness. lsof is your friend. notice any services listening that shouldn't be? disable them. 5. configure logcheck to send you "interesting" log entries. preferably to an offsite email address that is secure. i have interesting entries for various machines sent to my textpager. again, your mileage may vary. you should also maintain a seperate logserver. if you are compromised, the attacker is almost certain to wipe your local logfiles and trojan the local syslog service. remote logging can show you when this occured. all of a sudden, no more logs from the hacked box. useful info. there are multiple ways to do this, syslog, syslog-ng, passive syslogging, etc. i use a combination of syslog and passive syslogging to have a redundant mirror of the syslogs on multiple machines. 6. install openssh. disable root logins. root should only log in on the console. if you need to elevate privledges, use su or better yet, sudo. 7. configure the local firewall. it could be any number of packages, ipfilter, ipfw, ipchains, whatever. configure it to DENY EVERYTHING and only allow the services you plan on making accessbile across the net. if you want to add egress filters, you can do that as well. i usually block all trusted ports except for services i will need to use from that machine (such as outbound dns queries if neccessary, ssh, etc). this is where having a stateful package like ipfilter comes in handy. remember that each package is different. they all handle filtering rules differently. some are stateful, some are not. rtfm. 5. build a baseline tripwire database. copy this database to offline media, such as a floppy disk or cdrom. ideally, you would build this baseline, burn it on cd-rom and then run tripwire against this database. that can be a little tricky, so if you want, just save a copy of the baseline on floppy. configure tripwire to run periodically (i like running it once an hour, your mileage may vary depending upon a lot of different factors). the baseline stored on floppies will be compared to the baseline on the machine every so often. once a week is good. this is to verify that someone hasn't tampered with the database. again, ideally this would be on cd-rom. while technically still hackable even though stored on r/o media, this will prevent 99% of the script kiddies out there from messing with your database. 6. bring the machine up on the net. 7. nmap the machine from another host and verify the firewall rules are functioning properly. if not, fix them. firewall rules can be tricky. 8. regularly look for vulnerability announcements that affect the distribution you are running. patch, and update your tripwire databases. suggestions: i prefer running systems with multiple firewalls in a dmz environment, even at home. all dmz machines also run local firewalls, filtering various traffic. my ideal configuration (not built yet, mind you) is as follows. the external firewall has 3 ports, external, dmz, rf-dmz for wireless. the interal firewall is a choke, two ports. internal and dmz. outside ------- dsl->external firewall->dmz dmz --- hub->ids system hub->passive syslog for dmz machines hub->externally accessible machines hub->internal firewall rf-dmz ------ ap->firewall (ipsec vpn only) internal -------- workstations, etc. -- christian void - [EMAIL PROTECTED] www.morphine.com/void/ gpg key available on request _______________________________________________ Bits mailing list [EMAIL PROTECTED] http://www.sugoi.org/mailman/listinfo/bits
