The installation is on the machine labeled 'Linux Firewall/Router' in this diagram:
There is a server shown in the schematic at .10that is shown operating 'behind the firewall' with the notebooks, but wasn't on the cart. I've put it there since the StartFirewall script shown later has a section of 'commented out' rules that apply to another server behind the firewall. Depending on the security requirements, it might be a good idea to provide another firewall for _that_ server, too, providing a DMZ type environment where there is additional protection for the 'internal server' from users of the LAN.
This is a text mode install since it's somewhat exotic to those who have never seen a character-based interface, & so we could more quickly get through the install and get to more ethereal topics, like securing the server and checking out port & packet sniffing software. Also, one of the common strains I hear about recent graduates from some other schools is that 'they have no experience at the command line.' Getting some experience there, and getting your eyes on the logs of an internet-connected *ix machine, will help differentiate you from other applicants who might roll their eyes and giggle at the mention of 'the command line' and not realize that industrial-strength networking is done at the command line.
I say there is 'value in learning this stuff' because some of the students I've seen get into network management & security careers in the past few years have built and operated Linux & Windows servers at home and/or at friends' places, watched their logs (Windoze logs stuff too!) to gain familiarity with internet & ethernet protocols, and mastered the art of keeping systems secure. This kind of familiarity with networking & security makes for a dynamite behavioral, technical interview, and helps substitute for some of the experience other have in the field.
The Core 4 text install choosing no GUI options takes a little less than 10 minutes. The step-by-step install procedure begins a ways down the page. First, we'll run through some topics for consideration as you set out to make your Linux installation...
Considerations for your installation:
Unless you're already skilled with the command line & character-based editors, learn vi, mc, or joe so you'll be comfortable editing the text files used to configure a *ix, or other command-line oriented, system with no GUI. You're welcome to develop your skills with your ssh account at info300.net.
There is probably the most value in learning 'vi', Visual Editor (actually vim on Fedora, vi IMproved) if you're wanting to go into networking, since it is available on _all_ *ix machines and with a little practice it be run from any keyboard. vi requires some practice since it requires getting into Insert, Replace, or Append mode to put or change text in a file & Escaping from that 'mode' to move the cursor. Commands, like the one to save a file and get _out_ of vi, wq, are entered only after hitting the : to get to a command prompt. There are plenty of vi tutorials, and some links for them on my Linux Links page.
The other editor choices mentioned here use Function Keys & don't require jumping in & out of this or that mode so they are simpler to master. But, they are not an 'official' *ix OS component like vi. 'joe' is a simple, character-based editor built for the PC keyboard's edit and function keys so it's less of a learning curve than vi. 'mc', Midnight Commander, provides a dual-'pane' interface so two directories can be juxtaposed and their contents copied/moved among them easily. A selected item is easily edited by hitting F4, then mc provides an easy-to-use text editor that provides syntax highlighting for html & php.
The Internet is a dangerous place, so don't start off displaying vulnerabilities by letting old distros run unattended while attached The Internet. Most older distros have easily detectable vulnerabilities (in components like mail, httpd, ssl, ssh, &c) and trying to upgrade the vulnerable components can lead to a 'dependency storm' that may take days to resolve. Whatever your chosen Linux distro, start with the 'latest stable release' until you're ready to shake the 'development tree' and try stuff _really_ at the bleeding edge. Always ally yourself with lists that will keep you noticed about vulnerabilities that apply to your particular distro. There are a couple of good lists for Linux-related & security issues in general on my Linux Links page.
For daily and seasonal reporting about the locations of networks from which probes and cracks, manual & automated, arise at The Internet Storm Center. They publish a list of subnets worth 'blackholing' in your hosts.deny and/or iptables script.
There's more to running a server than learning it's text editors. System Administration in general and specifically for Linux is found in the LAME, Linux Admin Made Easy, which is a classic introduction to the diligence of running a Linux server. YoLinux's Internet Security Tute is a good place to start into Internet and Linux security. Hacking Linux Exposed is another good intro if you want to spend a few $ for an introductory book, although I'm distressed they may characterize the 'hacker' as a bad guy, where many believe hackers wear white hats and crackers wear the black. Insecure.org is a mecca for hackers and crackers alike, has gifted us with nmap, and also keeps us posted on current threats from the crackers who use it.
The most useful installation for learning to run and secure a server is on a machine with a fixed IP address & a full-time internet connection. Some of our cable & DSL providers will provide these for their subscribers to run modest web-servers, others won't. If you're in the dorms, don't misbehave since you'll be on Vernon's radar in no time at all, but you're welcome to run benign services and your system will regularly be port scanned and checked for open mail relays.
If you can get the fixed IP, register a URL with godaddy.com or another reputable registrar. Use a domain registrar that provides 'full DNS control' so you can reference your IP in the DNS settings and make an MX (Mail eXchange) record that points to your URL so your email will not be shot down as spam. With this rig, you can be root on your own machine and run tcpdump, tethereal, nmap, snort, and otherwise do stuff you can't do on anybody else's web server.
If you don't have the fixed IP, and even if you use a dial-up connection, you can still do all this stuff, but it becomes a bit more complex. If your ISP's DHCP gives out a public, routable IP address, noip.com and other 'dynamic DNS' sites let you get past the lack of a static IP gracefully enough that you can setup, develop, and debug web services. It is a special challenge to set up a Linux machine so that it will work to share an DHCP-leased IP connection, firewall it, and watch the logs while you're connected.
Unless you've got a lot of bandwidth at home, use the machines in the 4th floor lab to get the Fedora Core 4 iso images from ftp://mirror.vcu.edu/pub/linux/fedora/4/i386/iso, where they will download in several minutes each and you can burn the isos onto your blank CDRs. If you get them from somewhere else, make sure to follow a similar path.
Make sure to use whatever options are needed to 'burn an iso image' of the filesystem onto the CD, since the default options of most CD-burners will usually just put the iso into the root directory of a blank, new filesystem they create. In the labs, use Roxio, started from the Programs menu, and choose 'write cd image' from the File menu. XP's CD writer doesn't burn iso images. If you're already on a Linux machine use cdrecord if you're brave or XCDRoast if you're GUI.
Learn more than one distro of Linux while you've got the time. Get into MySQL & PHP. Learn to administer Windows Server2003 & SQLServer2003 & .net while they're free from MSDNAA. Figure out what's the best for which situations and develop deep technical skills that are always in demand.
I've used Fedora here because it's similar to the Red Hat Enterprise that's required by IBM for some commercial applications I support, and I've got little time for hard knocks from more than two *ix flavors per season. Also, it's free and it's easy to keep it updated. 'yum', Yellow Dog Update Manager, works for Fedora and RedHat's upd2date does, too, just not as fast as the download sites they provide for RedHatEnterprise subscribers. Fedora promises a 'bleeding edge' release cycle of less than a year, and most of the free distros are similarly turbulent. For longer release cycles, Red Hat Enterprise is available at an Educational discount for $50.
There are other free Linux distros that are well supported by their community & easy to keep updated. Check out the links to other distro on my Linux Links page. If you want to build secure systems you'll need kernel-honing and other skills that go beyond this quick intro. Get started...
The Fedora Project and Red Hat Enterprise recently added a new wrinkle to the Linux file system: the Logical Volume Manager. This makes the dialog with the Druid (Fedora's fdisker & formatter) look somewhat different than the earlier installations since there is are now 'physical' and 'logical' views of the disk devices. Someone who clearly understands RAID & recovery of disks can use the LVM to excellent advantage, especially with these new hot-swappable SATA drives. So, I suggest you set up RAIDs, sacrifice disk drives (power them down) with abandon, and figure all this stuff out.
Meanwhile, the default 'auto partition' I suggest using for this quick demo/first time thru uses the LVM and it works fine, so I don't recommend trying to get along without it.
If you're installing on a GigaHz or better machine with plenty of RAM consider putting a Workstation install on it so you can get some experience with a Gnome and/or KDE desktop. A full graphic install may take 30, 45, or more minutes depending on how quick your machine is. Just like Windoze, the Linux GUI thrives on GHz & GBytes so more is better for a desktop machine. The GUI, Gnome, 'front ends' for ethereal, for example, are really an improvement over the text-based tool and is much easier to use. gkrellm is a fine GUI network & cpu performance monitor that will use Fedora's new instrumentation to show fan speed, CPU temperature, &c.
If you've also got an older machine or two you can make a server farm of your own and fine-tune your kernel-building and security skills as you customize each for its purpose. You can run a honeynet/dmz from which you can start to experience security-related stuff and develop security skills by watching for incursions by the hordes at the digital frontier and protecting your systems from them.
Will you be running a web server? In class I'm installing & running httpd on this machine that's otherwise being set up as a firewall/router so we can see Fedora's web document root and what happens if it's empty or an error is delivered, where you inform the world the exact version of your web server...
For max security, it's probably not a good idea to run other services that _might_ be compromised on the machine that's going to protect you from bandits. You will still get to observe te effects of virii & worms ancient and new, from Nimda through RedWorm, Slapper, and the more virulent & effuse forms constantly thrown past us by pirates in WindowsLand.
Will you be running a mail server? Sendmail, the default out-of-the-box mail server for Fedora, is difficult to configure and of little use without having a registered internet domain and control over the DNS so that you can set the MX record to point to that domain, so leave it out if you aren't going to register a domain for your IP. (I'll demo godaddy.com in class) If you want to access an email account on your server via an email client like OutlookExpress or Eudora, you'll need to make sure to load the imap package and configure pop3 and/or imap so they running. The 'imap' package handles POP3 & IMAP. Sendmail is no longer configured as an 'open relay' out of the box, and it needs to be opened up to relay mail from anywhere except localhost so if you want to relay mail out of your LAN you'll need to bone up on this simple manipulation of sendmail.mc.
Other services like DNS (bind), DHCP, and Samba are cool so you can learn how to run a Domain Name Server, make your firewall do DHCP for the machines behind it, and let the linux server show up in a Windoze Workgroup and participate in an SMB, peer-to-peer network as well as The Internet.
Plan to leave your new server unattached from the internet until id and essential services have been setup and you're ready to check out its 'internet profile' that will be clearly visible to the crackers roaming your subnet at will. In class I did this by running nmap against it from one of the servers in my office, before & after running setup to deselect un-needed services. Plan to reboot a few times to make sure everything works from bootup.
Don't install boot passwords unless you're always going to be there to supply them at reboot. If you've got the house or the office LAN running through your firewall/gateway you probably want it to restart unattended when the power starts flowing again.
The server's IP 'web identity' & security environment are mostly set by editing configuration files in /etc. Here are the files affected by the installation They will need editing if something was screwed up during the install, or if this installation is going to get the users & data from some other installation:
- /etc/sysconfig/network defines server name & gateway
- /etc/resolv.conf sets the DNS IP addresses
- /etc/sysconfig/network-scripts/ifcfg-eth0, eth1, &c hold the IP addresses for ethernet interfaces. If this server will be used as a firewall this should be set to the IP address for the firewall server, and the eth1 given an address like 192.168.1.1 (or 192.168.0.254 if you favor other extremes) appropriate for the LAN's gateway router.
- /etc/sysconfig/network-scripts/ like ifcfg-eth0:0 are used if any aliases have been created to handle more IP addresses on one NIC.
- Beware GUI tools: If RedHat's networking manager, either GUI or text-based, has been used make sure /etc/sysconfig/networking/devices entries are configured like their counterparts in network-scripts/, and that any entries in profiles/default. Some tools 'hijack' the command line settings and will overwrite the network admin's keystrokes at the next boot or service restart.
- /etc/hosts needs the IP address and name of all machines behind a firewall so they'll resolve without DNS.
- /etc/hosts.allow & hosts.deny are used by tcp wrappers/xinted to restrict access to services.
- /etc/group & its shadows define groups used for file access & other security purposes.
- /etc/passwd & /etc/groups & their shadows define users for mail and shell access. If you've got to move users to the new platform, you can restore these files on the new machine & edit them directly to take out the part at the beginning that 'overlaps' with the new machine before appending them to the /etc files on the new machine.
- /home/ gets a directory added, by default, as /sbin/useradd is used to add new users to a server.
- /root/ is root's 'home directory'
- /etc/rc.d/rc.local starts local processes like StartFirewall after all other bootup activity. It is preferable to handle any 'added stuff' by referencing it in rc.local. Don't modify OS scripts since that may complicate a move to some other platform in the future.
- /etc/httpd/conf/httpd.conf, only mod from defaults are for virtual servers and php parsing (html added), check the location of this carefully since it moves around.
- Sendmail stuff: If this server will be running sendmail to send mail into The Internet /etc/mail/sendmail.mc needs to have the DAEMON_OPTIONS line uncommented so that sendmail will listen on IPs other than 127.0.0.1. After making changes to sendmail.mc, one does make -C /etc/mail to put changes into sendmail.cf, which is really the configuration file for sendmail -- but it's so fragile they've made the sendmail.mc file for you to edit. In some other distros it takes 'm4 /etc/mail/sendmail.mc > /etc/sendmail.cf to apply the changes. Find out what's required for yours. Don't mess directly with sendmail.cf -- if sendmail needs much configuration consider choosing a new MTA like postfix...
Plan to run only essential services and don't plug the server into The Internet until unessential/insecure services have been shut off. Fewer are left running in today's distros, but there are still some that should be turned off unless you're willing to police their use. Services can be configured in /etc/xinetd and other config files and directories in /etc, but for just turning them on or off it's easy to use the text-based 'setup' command available to su.
The list of 'essential services' down in the installation steps is somewhat longer that the one we used to use in RedHat 7 and beyond, but several of the newer services that popped up with the Fedora Core series provide the instrumentation for better reporting of kernel and other system activity and I want to learn how to use them. Use F1 & google as you work through the services to learn more of what they do. Remember, some services are inherently insecure (like telnet, ftp, and the 'r processes' like rsh) and shouldn't be used unless there's a good reason and someone to tail their logs for signs of abuse.
After the CDs have run through, plan to choose essential services by running 'setup' from the command line, choosing 'system services' from its menu, using the space bar to select/deselect services, and navigating to the OK button to save them. Below, there is a list of 'essential' services to turn on. Everything else should be turned off unless you're sure you need it, and either know it's secure from The Internet or you know how to keep it secure.
The firewall/router startup is handled by an 'iptables script': /root/Added/StartFirewall.
If you'll be using this script, copy/paste/save it somewhere you can get it and copy it to your firewall easily when its needed after the OS install.
Your /etc/rc.d/rc.local will need to be edited to make
/root/Added/StartFirewall
its last line. These steps are included below, but will be easier if anticipated.
Upgrading an existing server:
If this is an upgrade of some existing server running an earlier version or different distro, spend some time discovering the differences between the OSs so you won't be surprised. Check for different places where the document root for the web server or other configuration files are kept. These have changed out from under me a few times since RedHat 4 days...
It's safer to make a fresh OS install and check it out your migration path while the old server is still doing its stuff than it is to 'do an upgrade' on the old server. If this is an emergency restore of a dead server, I hope you've got the essential stuff on tape, CD, or maybe on the Internet somewhere? If this is a new linux install without any 'legacy' to support, have at it.
Don't expect there will be no differences in configuration files like sendmail.cf, httpd.conf, or any others, since they may vary wildly between distros and releases of key components like mail, web, ssh, or other services. Test them individually before setting out to put them into production.
For these, and more subtle, reasons it is not wise to expect to backup the entire contents of /etc, or /var, or other directories and install them on the new machine. Ditto this for a DBMS's files, which might not survive a bump up in the Rev# and it might require using the DBMS's dump and reload features to migrate the database. It's nice when the entire migration can be done by saying 'tar -zxvf' but that's the exception rather than the rule.
Don't assume that a tar archive produced on one *ix flavor will be readable on another *ix. There may be subtle formatting or big-endian/little-endian issues moving from one processor family to another. Other methods, like cpio, may produce a more compatible tape or disk file.
Click here for some sample scripts & techniques for backing up the 'essential stuff' from the old server so it can be restored on a new server.
Starting the Core 4 install:
- Rig the PC to boot from the CD, if it isn't already rigged that way.
- When the CD boots you have a few seconds in which to type 'linux text', otherwise you'll be denied the spartan experience of the 'text mode installation' demo'd in class.
- Entering 'linux text' soon gets you to an interface where choices are hilighted by pressing the tab key, or an arrow key. When they are hilighted they are chosen by pressing the space bar or the enter key. Words to this effect are there at the bottom of the screen.
- Choose and enter 'Skip' for the Media check. Or, let it check your CDs for you. Even though it always prompts for CD #1, it will let you validate all 4 CDs in the set. Leaving the media check, Anaconda takes over and begins the install in something less than half a minute. It will probe for devices and begin a dialog with you shortly.
- For the next steps we in the USofA can choose the defaults for language & keyboard by choosing OK.
- Anaconda will look for existing partitions on your drive and offer the options of leaving them there or overwriting them with the new OS.
- Choose 'Reinstall the System' and avoid the hassles of a dual-boot installation, preferring to run Linux all the time on the boxes where it's installed.
- Choose 'Custom Install' so you can be picky and avoid the GUI stuff that would bloat up a 'minimum install'. Or, choose 'WorkStation' if you've got time and inclination to use the Linux GUI on the same server.
- At the Auto-partition dialog, elect to remove all partitions and to leave the * at hda (the first hard disk) and any others if you have them.
- Check out the partitioning info. The essential parts Linux will be using are a small /boot, a huge /, and a /swap large enough for your RAM. Make note of where these have been mounted as part of your machine's documentation. Then, tab until 'OK' is hilighted and hit enter.
- Take defaults on the next steps: Use the grub boot loader; leave 'boot local' blank & choose OK; say No to grub password; say OK to the default boot label; and let it sit at the MBR.
- Network configuration dialog: Take care to enter the appropriate addresses & subnet masks for your environment. In the first dialog, use the spacebar to unselect DHCP (unless you've got no fixed IP & need to use DHCP), then you'll be able to fill in the IP provided by your ISP in the eth0 setup. Assuming Anaconda found _both_ your ethernet cards, the next dialog will ask for the LAN IP address on the next window, where you can select the 'activate on boot' option and save a step later.
- If you've got a domain name registered enter it, including the .com or other domain at the end. If you don't, name it anything you that makes sense in your network since it won't be accessable by name from anywhere else on The Internet.
- The gateway is the address of your gateway router assigned by your ISP. If you're doing DHCP this isn't needed since the router will respond to your machine's plea for DHCP and get all this set automagically.
- Plug in your DNS IPs.
- Choose NO for the firewall, since we'll be supplying our own firewall script. Then, proceed without a firewall in spite of Fedora's warning otherwise.
- I'm not up to speed, yet, on all that SELinux, Security Enhanced Linux, has to offer so I've checked the 'warn' level of security and will look into it later.
- Operate your machine with Greenwich Mean Time (UCT), or choose your local time zone.
- Enter a strong passphrase including letters, numbers, and maybe some punctuation thrown in. Seeing a few 'brute force' attacks on ssh ports where thousands of guessing attempts have been made has made me a believer in this. If somebody picks up your ssh login name and password because you're using pop3 to check mail, where both are sent in clear text, you've got no security, so don't use an ssh login id, especially 'root', as a mail account.
- Next, Anaconda will wind around for a half minute or so and come up with
the 'Package Group Selection' dialog we got by choosing 'Custom Install' earlier.
If you chose 'Workstation' I'm not sure what happens here.
- Say no to XWindows, Gnome, and KDE.
- For Editors, F2 and choose joe if you want an easy editor, and leave vim.
- Say no to Engineering & Scientific and Graphical Internet
- For Text Based Internet, F2 and choose elinks & lynx. Later learn which you like best to do text-based browsing & easy http download of stuff to your server.
- Say no to Office, Sound & Video, Authoring & Publishing, Graphics, Games, and Server Configuration tools.
- For Web Server, F2 and if you want to save time & space, deselect all but http & webalizer if you want to be able to browse to graphic stats for your http service. If you're going the 'pure firewall route' don't choose anything for web server. If you'll be running PHP, you can choose it, and MySQL, too, on a later line.
- Say no to mailserver unless you've registered a url and are going to run a mail server on your firewall.
- For Windows File Server, F2 and choose components if you want to do Samba with your Windoze Network Neighborhood.
- Say no to DNS, FTP, and PostgreSQL, choose MySQL is you want it. (Choose mysql-php if you want to do PHP programming with MySQL).
- Say no to newsserver, network server, and legacy network.
- Say Yes to development tools and either take the defaults or take the time to learn which are likely to be needed later to make stuff, compile stuff, and do who knows what to get software and patches on your machine.
- Say no to X, gnome, KDE development, legacy (unless you want to install GUI & run Blender 3D, then its needed). Keep on No-ing for Java, Eclipse (excellent IDE for multi-languages, but not needed on a server), and Language Support.
- For System Tools, F2 and choose mc & nmap so you'll have an easy Linux navigator/editor and port sniffer.
- Say no to Printer Support & Everything.
- This gets you to a heart-thumping few minutes where Anaconda 'resolves dependencies'. If we get past this without any problems (and choosing minimum above will make that more likely) we're advised that a log will be kept, /root/install.log, so you can do a post-mortem or will have a birth certificate for a healthy system depending on what happens next.
- Take care to choose 'Continue' before hitting Enter on the 'Required Install Media' advice, which is the last screen in this phase of the install dialog. Unfortunately, taking the default here will discard all the steps just taken...
- The CD spins, the hard drive light flashes, and you'll need to nurse the CD drive for a little while. The install as done in class takes something less than 10 minutes...
- When the install is done, remove the last CD, let the machine reboot, plug in the ethernet cable to The Internet (it will be easier to figure out which is eth0 if we plug in one cable at a time), and get ready to secure the installation and get the firewall/server on The Internet...
Securing the server
- Don't leave the thing plugged into The Internet indefinitely without protection. These next few steps were done out of sequence for the demo so we could look at the machine from afar using nmap and see too many ports open. In you own install, you might want to delay plugging in the server and pinging the router until after you've run setup. I have seen machines compromised within minutes of going 'on the net' so usually exercise caution.
- Start checking for 'internet connectivity' by looking for appropriate green lights at the NIC and your DSL router or other 'internet box' if you're lucky to have it close by (In class we don't have the luxury of seeing two green lights, only the one on the NIC).
- 'Ping the router' by typing 'ping 128.172.189.254' (substitute _your_ router). Check to see if the NIC's light is flashing in synch with your pings & change the cable if it's not.
- Don't be dismayed to get no response for a little while or get 'no route' messages. Until there is a flurry of router ARPing and the router 'notices' the new NIC, you'll get no response. You can type tcpdump -i eth0 to see what traffic is there meanwhile.
- If you can't ping the router after a few minutes, especially if you've seen ARPs it's time to start debugging, examining the network settings in the configuration files mentioned above, using vi or mc to find and fix errors.
- In class we stopped at this point and ran nmap from another server to see what our 'profile' of open ports appears like.
- Login using root & the root password, and from the command line
run 'setup'. Cursor down to System Services, hit the tab key
to hilite Run Tool, hit Enter, and use the cursor arrow & space bar to
turn _on_ these services (put a splat there) & turn _off_ everything else:
- acpid
- apmd
- atd
- auditd
- autofs
- cpuspeed
- crond
- gpm
- haldemon
- httpd ? if you want to run a web server on this firewall, leave it off if webservices are tended by a machine behind the firewall
- imap ? to allow retrieval of email with a mail client like Outlook or Evolution, otherwise the mail sticks in the box until you use the command line to say 'mail'
- iptables ? say no if you'll be supplying your own iptables script as used in class
- keytable
- kudzu ? detects new hardware, turn it off when you're done...
- messagebus
- named? only run this if you want to get into DNS control & can watch it closely
- network
- random
- sendmail ? only if you've got a domain and make sure you're not operating an 'open relay'
- smb ? if you want to include your server/firewall in a Windows Network Neighborhood This needs to be running, then you need to configure Samba to make it work. Then you'll draw in those crackers that see your SMB port open...
- sshd ? do you even want to allow any remote ssh on a firewall? Maybe it's safer from the console?
- syslog
- xfs ? if you went with a GUI install this is the 'X font server' so you'll need it and see it on port 6000
- xinted
- When the system rebooted in class, we looked at it from another machine with nmap, expecting to see only ports open for ssh & http.
- Get the machine's hosts defined: Edit /etc/hosts to define the hosts that will operate behind your firewall. Copy or edit /etc/hosts.allow & hosts.deny to limit access to ssh and other services.
- Connect the cable to the LAN and see if the local machines can ping your firewall, 192.168.1.1 in the example above. They will need to have their ethernet port's TCP/IP properties for gateway/router set to 192.168.1.1, subnet to 255.255.255.0, and DNS set to whatever is appropriate for your network.
- Get the firewall installed: Use scp to copy the firewall script from
wherever you put it. For example:
cd /root/
mkdir /Added/
cd Added
scp astudent@info300.net:StartFirewall ./
Substitute your userid and/or the url where you stuffed your copy...
If it isn't already executable (ls -las will show this) make it so using chmod +x StartFirewall. - Use your favorite editor to edit StartFirewall. Change the IPs to suit your network, comment out lines that don't apply, or add lines for firewalling rules for your network.
- Use your favorite editor to edit /etc/rc.d/rc.local and add a reference
to the firewall script on the last line:
/root/Added/StartFirewall
is all that's needed. - iptables -L will show not much in the list until the script is run. While in /root/Added, type ./StartFirewall and see if you get any error messages. This script will produce no output if no errors are encountered. After running the script, type iptables -L and see what's changed.
- Reboot the system to make sure it runs StartFirewall on the way up.
- Check for 'internet connectivity' with the machines behind the firewall. These machines don't have to log in or do anything else for the server and they should be able to browse the internet. If they can't some debugging is needed in the firewall script, /etc/hosts, and maybe the network wiring.
- Make sure /etc/hosts.allow and hosts.deny are working as expected so xinetd's 'TCP Wrappers' will work to keep bandits from using your ssh to guess 1000's of login ids/passwords and other nasty tricks. Get yourself and/or a friend somewhere on a network other than your server's so you can test your security and make sure that you've not put any extra dots or anything in these files & they're working appropriately. Check here for samples of these files.
- In class this was where we used tcpdump & tethereal to look at network activity and detect the guys hacking at our machine with their WiFi connections. At home, this is where you'll want to start watching your logs, and learning to capture interesting stuff with ethereal...
- Setup a non-root login id using useradd and give it an initial password using passwd. The, exit from your root session, and resolve not to log in as root on your server anymore. Instead, log in with a non-root id and use 'su' to get to root privileges when you need them. That way, the logs will always show which user went to su when.
Fedora runs 'logwatch', which reviews, on a nitely basis, /var/log/messages & secure, your httpd & mail logs, and other places to advise you of anything out of line. Check email for root, mail -uroot, after you su into root and you'll get this advice every morning. Check your log files, expecially messages & secure, to get more details about what you see reported.
Update me, please, with your experience using this for installing Fedora Core 4. It was put together on June 24th & feedback will be helpful.