prakash0106

Linux Shortcuts and Commands: Linux Newbie Administrator Guide This is a practical selection of the commands we use most often. Press <Tab> to see the listing of all available command (on your PATH). On my small home system, it says there are 2595 executables on my PATH. Many of these "commands" can be accessed from your favourite GUI front-end (probably KDE or Gnome) by clicking on the right menu or button. They can all be run from the command line. Programs that require GUI have to be run from a terminal opened under a GUI. Legend: <> = single special or function key on the keyboard. For example <Ctrl> indicates the "control" key. italic = name of the file or variable you probably want to substitute with your own. fixed width = in-line Linux commands and filenames. Notes for the UNIX Clueless: 1. LINUX IS CASE-SENSITIVE. For example: Netscape, NETSCAPE and nEtscape are three different commands. Also my_filE, my_file, and my_FILE are three different files. Your user login name and password are also case sensitive. (This goes with the tradition of UNIX and the "c" programming language being case sensitive.) 2. Filenames can be up to 256 characters long and can contain letters, numbers, "." (dot), "_" (underscore), "-" (dash), plus some other not recommended characters. 3. Files with names starting with "." are normally not shown by the ls (list) or dir commands. Think of these files as "hidden". Use ls -a (list with the option "all") to see these files. 4. "/" is an equivalent to DOS "\" (root directory, meaning the parent of all other directories). 5. Under Linux, all directories appear under a single directory tree (there are no DOS-style drive letters). 6. In a configuration file, a line starting with # is a comment. 7.1 Linux essential shortcuts and sanity commands <Ctrl><Alt><F1> Switch to the first text terminal. Under Linux you can have several (6 in standard setup) terminals opened at the same time. <Ctrl><Alt><Fn> (n=1..6) Switch to the nth text terminal. tty Print the name of the terminal in which you are typing this command. <Ctrl><Alt><F7> Switch to the first GUI terminal (if X-windows is running on this terminal). <Ctrl><Alt><Fn> (n=7..12) Switch to the nth GUI terminal (if a GUI terminal is running on screen n-1). On default, nothing is running on terminals 8 to 12, but you can run another server there. <Tab> (In a text terminal) Autocomplete the command if there is only one option, or else show all the available options. THIS SHORTCUT IS GREAT! It even works at LILO prompt! <ArrowUp> Scroll and edit the command history. Press <Enter> to execute. <Shift><PgUp> Scroll terminal output up. Work also at the login prompt, so you can scroll through your bootup messages. <Shift><PgDown> Scroll terminal output down. <Ctrl><Alt><+> (in X-windows) Change to the next X-server resolution (if you set up the X-server to more than one resolution). For multiple resolutions on my standard SVGA card/monitor, I have the following line in the file /etc/X11/XF86Config (the first resolution starts on default, the largest determines the size of the "virtual screen"): Modes "1024x768" "800x600" "640x480" "512x384" "480x300" "400x300" "1152x864" <Ctrl><Alt><-> (in X-windows) Change to the previous X-server resolution. <Ctrl><Alt><BkSpc> (in X-windows) Kill the current X-windows server. Use if the X-windows server crushes and cannot be exited normally. <Ctrl><Alt><Del> Shut down the system and reboot. This is the normal shutdown command for a user at the text-mode console. Don't just press the "reset" button for shutdown! <Ctrl>c Kill the current process (mostly in the text mode for small applications). <Ctrl>d Log out from the current terminal. See also the next command. <Ctrl>d Send [End-of-File] to the current process. Don't press it twice else you also log out (see the previous command). <Ctrl>s Stop the transfer to the terminal. <Ctrl>q Resume the transfer to the terminal. Try if your terminal mysteriously stops responding. <Ctrl>z Send the current process to the background. exit Logout. I can also use logout for the same effect. (If you have started a second shell, e.g., using bash the second shell will be exited and you will be back in the first shell, not logged out.) reset Restore a screwed-up terminal (a terminal showing funny characters) to default setting. Use if you tried to "cat" a binary file. You may not be able to see the command as you type it. <MiddleMouseButton> Paste the text which is currently highlighted somewhere else. This is the normal "copy-paste" operation in Linux. (It doesn't work with Netscape and WordPerfect which use the MS Windows-style "copy-paste". It does work in the text terminal if you enabled "gpm" service using "setup".) Best used with a Linux-ready 3-button mouse (Logitech or similar) or else set "3-mouse button emulation"). ~ (tilde) My home directory (normally the directory /home/my_login_name). For example, the command cd ~/my_dir will change my working directory to the subdirectory "my_dir" under my home directory. Typing just "cd" alone is an equivalent of the command "cd ~". . (dot) Current directory. For example, ./my_program will attempt to execute the file "my_program" located in your current working directory. .. (two dots) Directory parent to the current one. For example, the command cd .. will change my current working directory one one level up. 7.2 Common Linux commands--system info pwd Print working directory, i.e., display the name of my current directory on the screen. hostname Print the name of the local host (the machine on which you are working). Use netconf (as root) to change the name of the machine. whoami Print my login name. id username Print user id (uid) and his/her group id (gid), effective id (if different than the real id) and the supplementary groups. date Print or change the operating system date and time. E.g., I could change the date and time to 2000-12-31 23:57 using this command: date 123123572000 To set the hardware (BIOS) clock from the system (Linux) clock, use the command (as root) setclock time Determine the amount of time that it takes for a process to complete + other info. Don't confuse it with the date command. E.g. I can find out how long it takes to display a directory content using: time ls who Determine the users logged on the machine. rwho -a (=remote who) Determine all users logged on your network. The rwho service must be enabled for this command to run. If it isn't, run setup as root to enable "rwho". finger user_name System info about a user. Try: finger root last Show listing of users last logged-in on your system. history | more Show the last (1000 or so) commands executed from the command line on the current account. The "| more" causes the display to stop after each screenful. uptime Show the amount of time since the last reboot. ps (=print status) List the processes currently run by the current user. ps axu | more List all the processes currently running, even those without the controlling terminal, together with the name of the user that owns each process. top Keep listing the currently running processes, sorted by cpu usage (top users first). In KDE, you can get GUI-based Ktop from "K"menu under "System"-"Task Manager" (or by executing "ktop" in an X-terminal). uname -a (= Unix name with option "all") Info on your (local) server. I can also use guname (in X-window terminal) to display the info more nicely. free Memory info (in kilobytes). df -h (=disk free) Print disk info about all the filesystems (in human-readable form) du / -bh | more (=disk usage) Print detailed disk usage for each subdirectory starting at the "/" (root) directory (in human legible form). cat /proc/cpuinfo Cpu info--it show the content of the file cpuinfo. Note that the files in the /proc directory are not real files--they are hooks to look at information available to the kernel. cat /proc/interrupts List the interrupts in use. cat /proc/version Linux version and other info cat /proc/filesystems Show the types of filesystems currently in use. cat /etc/printcap Show the setup of printers. lsmod (As root. Use /sbin/lsmod to execute this command when you are a non-root user.) Show the kernel modules currently loaded. set|more Show the current user environment. echo $PATH Show the content of the environment variable "PATH". This command can be used to show other environment variables as well. Use "set" to see the full environment. dmesg | less Print kernel messages (the content of the so-called kernel ring buffer). Press "q" to quit "less". Use less /var/log/dmesg to see what "dmesg" dumped into this file right after the last system bootup. 7.3 Basic operations any_command --help |more Display a brief help on a command (works with most commands). "--help" works similar to DOS "/h" switch. The "more" pipe is needed if the output is longer than one screen. man topic Display the contents of the system manual pages (help) on the topic. Try man man first. Press "q" to quit the viewer. The command info topic works similar and may contain more up-to-date information. Manual pages can be hard to read. Try any_command --help for short, easy to digest help on a command. If more info needed, have a look to the directory /usr/doc. To display manual page from a specific section, I may use something like in this example: man 3 exit (this displays an info on the command exit from section 3 of the manual pages). apropos topic Give me the list of the commands that have something to to do with my topic. help command Display brief info on a bash (shell) build-in command. ls List the content of the current directory. Under Linux, the command "dir" is an alias to ls. Many users have "ls" to be an alias to "ls --color". ls -al |more List the content of the current directory, all files (also those starting with a dot), and in a long form. Pipe the output through the "more" command, so that the display pauses after each screenful. cd directory Change directory. Using "cd" without the directory name will take you to your home directory. "cd -" will take you to your previous directory and is a convenient way to toggle between two directories. "cd .." will take you one directory up. cp source destination Copy files. E.g., cp /home/stan/existing_file_name . will copy a file to my current working directory. Use the "-r" option (for recursive) to copy the contents of whole directories, e.g. , cp -r my_existing/dir/ ~ will copy a subdirectory under my current working directory to my home directory. mcopy source destination Copy a file from/to a DOS filesystem (no mounting necessary). E.g., mcopy a:\autoexec.bat ~/junk . See man mtools for related commands: mdir, mcd, mren, mmove, mdel, mmd, mrd, mformat .... mv source destination Move or rename files. The same command is used for moving and renaming files and directories. ln source destination Create a hard link called destination to the file called source. The link appears as a copy of the original files, but in reality only one copy of the file is kept, just two (or more) directory entries point to it. Any changes the file are automatically visible throughout. When one directory entry is removed, the other(s) stay(s) intact. The limitation of the hard links are: the files have to be on the same filesystem, hard links to directories or special files are impossible. ln -s source destination Create a symbolic (soft) link called "destination" to the file called "source". The symbolic link just specifies a path where to look for the file. In contradistinction to hard links, the source and destination don't not have to tbe on the same filesystem. In comparison to hard links, the drawback of symbolic links are: if the original file is removed, the link is "broken", symbolic links can also create circular references (like circular references in spreadsheets or databases, e.g., "a" points to "b" and "b" points back to "a"). rm files Remove (delete) files. You must own the file in order to be able to remove it. On many systems, you will be asked or confirmation of deleation, if you don't want this, use the "-f" (=force) option, e.g., rm -f * will remove all files in my current working directory, no questions asked. mkdir directory Make a new directory. rmdir directory Remove an empty directory. rm -r files (recursive remove) Remove files, directories, and their subdirectories. Careful with this command as root--you can easily remove all files on the system with such a command executed on the top of your directory tree, and there is no undelete in Linux (yet). But if you really wanted to do it (reconsider), here is how (as root): rm -rf /* cat filename | more View the content of a text file called "filename", one page a time. The "|" is the "pipe" symbol (on many American keyboards it shares the key with "\") The pipe makes the output stop after each screenful. For long files, it is sometimes convenient to use the commands head and tail that display just the beginning and the end of the file. If you happened to use "cat" a binary file and your terminal displays funny characters afterwards, you can restore it with the command "reset". less filename Scroll through a content of a text file. Press q when done. "Less" is roughly equivalent to "more" , the command you know from DOS, although very often "less" is more convenient than "more". pico filename Edit a text file using the simple and standard text editor called pico. pico -w filename Edit a text file, while disabling the long line wrap. Handy for editing configuration files, e.g. /etc/fstab. find / -name "filename" Find the file called "filename" on your filesystem starting the search from the root directory "/". The "filename" may contain wildcards (*,?). locate filename Find the file name of which contains the string "filename". Easier and faster than the previous command but depends on a database that normally rebuilds at night. ./program_name Run an executable in the current directory, which is not on your PATH. touch filename Change the date/time stamp of the file filename to the current time. Create an empty file if the file does not exist. xinit Start a barebone X-windows server (without a windows manager). startx Start an X-windows server and the default windows manager. Works like typing "win" under DOS with Win3.1 startx -- :1 Start another X-windows session on the display 1 (the default is opened on display 0). You can have several GUI terminals running concurrently. Switch between them using <Ctrl><Alt><F7>, <Ctrl><Alt><F8>, etc. xterm (in X terminal) Run a simple X-windows terminal. Typing exit will close it. There are other, more advanced "virtual" terminals for X-windows. I like the popular ones: konsole and kvt (both come with kde) and gnome-terminal (comes with gnome). If you need something really fancy-looking, try Eterm. xboing (in X terminal). Very nice, old-fashioned game. Many small games/programs are probably installed on your system. I also like xboard (chess). shutdown -h now (as root) Shut down the system to a halt. Mostly used for a remote shutdown. Use <Ctrl><Alt><Del> for a shutdown at the console (which can be done by any user). halt reboot (as root, two commands) Halt or reboot the machine. Used for remote shutdown, simpler to type than the previous command. Network apps netscape (in X terminal) Run netscape (requires a separate Netscape installation). The current versions of Netscape (4.x) are known to be big and buggy. They occasionally crash by vanishing (no other harm done). Also, when not connected to the network , Netscape likes to refuse to do anything (looks like it hanged)-it revives when you connect. netscape -display host:0.0 (in X terminal) Run netscape on the current machine and direct the output to machine named "host" display 0 screen 0. Your current machine must have a permission to display on the machine "host" (typically given by executing the command xhost current_machine_name in the xterminal of the machine host. Other X-windows program can be run remotely the same way. lynx file.html View an html file or browse the net from the text mode. pine A good text-mode mail reader. Another good and standard one is elm. Your Netscape mail will read the mail from your Internet account. pine will let you read the "local" mail, e.g. the mail your son or a cron process sends to you from a computer on your home network. The command mail could also be used for reading/composing mail, but it would be inconvenient--it is meant to be used in scripts for automation. elm A good tex-mode mail reader. See the previous command. mutt A really basic but extremally useful and fast mail reader. mail A basic operating system tool for e-mail. Look at the previous commands for a better e-mail reader. mail is good if you wanted to send an e-mail from a shell script. licq (in X term) An icq "instant messaging" client. Another good one is kxicq. Older distributions don't have an icq client installed, you have to do download one and install it. talk username1 Talk to another user currently logged on your machine (or use "talk username1@machinename" to talk to a user on a different computer) . To accept the invitation to the conversation, type the command "talk username2". If somebody is trying to talk to you and it disrupts your work, your may use the command "mesg n" to refuse accepting messages. You may want to use "who" or "rwho" to determine the users who are currently logged-in. mc Launch the "Midnight Commander" file manager (looks like "Norton Commander" for Linux). telnet server Connect to another machine using the TELNET protocol. Use a remote machine name or IP address. You will be prompted for your login name and password--you must have an account on the remote machine to login. Telnet will connect you to another machine and let you operate on it as if you were sitting at its keyboard (almost). Telnet is not very secure--everything you type goes in open text, even your password! rlogin server (=remote login) Connect to another machine. The login name/password from your current session is used; if it fails you are prompted for a password. rsh server (=remote shell) Yet another way to connect to a remote machine. The login name/password from your current session is used; if it fails you are prompted for a password. ftp server Ftp another machine. (There is also ncftp which adds extra features and gftp for GUI .) Ftp is good for copying files to/from a remote machine. Try user "anonymous" if you don't have an account on the remote server. After connection, use "?" to see the list of available ftp commands. The essential ftp command are:ls (see the files on the remote system), ASCII, binary (set the file transfer mode to either text or binary, important that you select the proper one ), get (copy a file from the remote system to the local system), mget (get many files at once), put (copy a file from the local system to the remote system), mput (put many files at once), bye (disconnect). For automation in a script, you may want to use ncftpput and ncftpget, for example: ncftpput -u my_user_name -p my_password -a remote.host.domain remote_dir *local.html minicom Minicom program (looks like "Procomm for Linux"). File (de)compression tar -zxvf filename.tar.gz (=tape archiver) Untar a tarred and compressed tarball (*.tar.gz or *.tgz) that you downloaded from the Internet. tar -xvf filename.tar Untar a tarred but uncompressed tarball (*.tar). gunzip filename.gz Decompress a zipped file (*.gz" or *.z). Use gzip (also zip or compress) if you wanted to compress files to this file format. bunzip2 filename.bz2 (=big unzip) Decompress a file (*.bz2) zipped with bzip2 compression utility. Used for big files. unzip filename.zip Decompress a file (*.zip) zipped with a compression utility compatible with PKZIP for DOS. unarj e filename.arj Extract the content of an *.arj archive. uudecode -o outputfile filename Decode a file encoded with uuencode. uu-encoded files are typically used for transfer of non-text files in e-mail (uuencode transforms any file into an ASCII file). 7.4 Process control ps (=print status) Display the list of currently running processes with their process IDs (PID) numbers. Use ps axu to see all processes currently running on your system (also those of other users or without a controlling terminal), each with the name of the owner. Use "top" to keep listing the processes currently running. fg PID Bring a background or stopped process to the foreground. bg PID Send the process to the background. Opposite to fg. The same can be accomplished with <Ctrl>z. If you have stopped jobs, you have to type exit twice in row to log out. any_command& Run any command in the background (the symbol "&" means "run the proceeding command in the background"). batch any_command Run any command (usually one that is going to take more time) when the system load is low. I can logout, and the process will keep running. at 17:00 Execute a command at a specified time. You will be prompted for the command(s) to run, until you press <Ctrl>d. kill PID Force a process shutdown. First determine the PID of the process to kill using ps. killall program_name Kill program(s) by name. xkill (in an xwindow terminal) Kill a GUI-based program with mouse. (Point with your mouse cursor at the window of the process you want to kill and click.) lpc (as root) Check and control the printer(s). Type "?" to see the list of available commands. lpq Show the content of the printer queue. Under KDE (X-Windows), you may use GUI-based "Printer Queue" available from "K"menu-Utilities. lprm job_number Remove a printing job "job_number" from the queue. nice program_name Run program_name adjusting its priority. Since the priority is not specified in this example, it will be adjusted by 10 (the process will run slower), from the default value (usually 0). The lower the number (of "niceness" to other users on the system), the higher the priority. The priority value may be in the range -20 to 19. Only root may specify negative values. Use "top" to display the priorities of the running processes. renice -1 PID (as root) Change the priority of a running process to -1. Normal users can only adjust processes they own, and only up from the current value (make them run slower). <Ctrl>c, <Ctrl>z, <Ctrl>s, and <Ctrl>q also belong to this chapter but they were described previously. In short they mean: stop the current command, send the current command to the background, stop the data transfer, resume the data transfer. 7.5 Basic administration commands printtool (as root in X-terminal) Configuration tool for your printer(s). Settings go to the file /etc/printcap. setup (as root) Configure mouse, soundcard, keyboard, X-windows, system services. There are many distibution-specific configuration utilities, setup is the default on RedHat. Mandrake 7.0 offers very nice DrakConf . linuxconfig (as root, either in text or graphical mode). You can access and change hundreds of setting from it. Very powerful--don't change too many things at the same time, and be careful with changing entries you don't understand. xvidtune (in X-terminal). Adjust the settings of the graphical display for all resolutions so as to eliminate black bands, shift the display right/left/up/down, etc. (First use the knobs on your monitor to fit your text mode correctly on the screen.) To make the changes permanent, display the frequencies on the screen and transfer them to the setup file /etc/X11/XF86Config. alias ls="ls --color=tty" Create an alias for the command "ls" to enhance its format with color. In this example, the alias is also called "ls" and the "color" option is only envoke when the output is done to a terminal (not to files). Put the alias into the file /etc/bashrc if you would like the alias to be always accessible to all users on the system. Type "alias" alone to see the list of aliases on your system. adduser user_name Create a new account (you must be root). E.g., adduser barbara Don't forget to set up the password for the new user in the next step. The user home directory is /home/user_name. useradd user_name The same as the command " adduser user_name ". userdel user_name Remove an account (you must be a root). The user's home directory and the undelivered mail must be dealt with separately (manually because you have to decide what to do with the files). groupadd group_name Create a new group on your system. Non-essential but can be handy even on a home machine with a small number of users. passwd Change the password on your current account. If you are root, you can change the password for any user using: passwd user_name chmod perm filename (=change mode) Change the file access permission for the files you own (unless you are root in which case you can change any file). You can make a file accessible in three modes: read ®, write (w), execute (x) to three classes of users: owner (u), members of the same group as the owner (g), others on the system (o). Check the current access permissions using: ls -l filename If the file is accessible to all users in all modes it will show: rwxrwxrwx The first triplet shows the file permission for the owner of the file, the second for his/her group, the third for others. A "no" permission is shown as "-". E.g., this command will add the permission to read the file "junk" to all (=user+group+others): chmod a+r junk This command will remove the permission to execute the file junk from others: chmod o-x junk Also try here for more info. You can set the default file permissions for the news files that you create using the command umask (see man umask). chown new_ownername filename chgrp new_groupname filename Change the file owner and group. You should use these two commands after you copy a file for use by somebody else. su (=substitute user id) Assume the superuser (=root) identity (you will be prompted for the password). Type "exit" to return you to your previous login. Don't habitually work on your machine as root. The root account is for administration and the su command is to ease your access to the administration account when you require it. You can also use "su" to assume any other user identity, e.g. su barbara will make me "barbara" (password required unless I am a superuser). kernelcfg (as root in X terminal). GUI to to add/remove kernel modules. You can do the same from the command line using the command "insmod", but "insmode" is less "newbie-friendly". lsmod List currently loaded kernel modules. A module is like a device driver--it provides operating system kernel support for a particular piece of hardware or feature. modprobe -l |more List all the modules available for your kernel. The available modules are determined by how your Linux kernel was compliled. Every possible module/feature can be compiled on linux as either "hard wired" (fast, non-removable), "module" (maybe slower, but loaded/removable on demand), or "no" (no support for this feature at all). insmod parport insmod ppa (as root) Insert modules into the kernel (a module is roughly an equivalent of a DOS device driver). This example shows how to insert the modules for support of the external parallel port zip drive (it appears to be a problem to get the external zip drive to work in any other way under RH6.0 ). rmmod module_name (as root, not essential). Remove the module module_name from the kernel. setserial /dev/cua0 port 0x03f8 irq 4 (as root) Set a serial port to a non-standard setting. The example here shows the standard setting for the first serial port (cua0 or ttyS0). The standard PC settings for the second serial port (cua1or ttyS1) are: address of i/o port 0x02f8, irq 3. The third serial port (cua2 or ttyS2): 0x03e8, irq 4. The forth serial port (cua3 or ttyS3): 0x02e8, irq 3. Add your setting to /etc/rc.d/rc.local if you want it to be set at the boot time. See man setserial for good a overview. fdisk (as root) Linux hard drive partitioning utility (DOS has a utility with the same name). cd /usr/src/linux-2.0.36 make xconfig (as root in X terminal). Nice GUI front-end for configuration of the kernel options in preparation for compilation of your customized kernel. (The directory name contains the version of your Linux kernel so you may need to modify the directory name if your Linux kernel version is different than 2.0.36 used in this example. You also need the "Tk" interpreter and the kernel source code installed. ) The alternatives to "make xconfig" are: "make config" (runs a scripts that asks you questions in the text mode) and "make menuconfig" (runs a text-based menu-driven configuration utility). Try: less /usr/doc/HOWTO/Kernel-HOWTO for more information. After the configuration, you may choose to proceed with kernel compilation of the new kernel by issuing the following commands: make dep make zImage The last command will take some time to complete (maybe 0.5 h, depending on your hardware). It produces the file "zImage", which is your new Linux kernel. Next: make modules make modules_install Read: /usr/doc/HOWTO/Kernel-HOWTO for information on how to install the new kernel. You will probably also find it useful to read "man depmode". Configuration, compilation and installation of a new kernel is not difficult but it CAN lead to problems if you don't know what you are doing. Compilation of a kernel is a good way to test your hardware, because it involves a massive amount of computing. If your hardware is "flaky", you will most likely receive the "signal 11" error (read the beatiful /usr/doc/FAQ/txt/GCC-SIG11-FAQ). See this for details on kernel upgrade. depmod -a (as root) Build the module dependency table for the kernel. This can, for example, be useful after installing and booting a new kernel. Use "modprobe -a" to load the modules. ldconfig (as root) Re-create the bindings and the cache for the loader of dynamic libraries ("ld"). You may want to run ldconfig after an installation of new dynamically linked libraries on your system. (It is also re-run every time you boot the computer, so if you reboot you don't have to run it manually.) mknod /dev/fd0 b 2 0 (=make node, as root) Create a device file. This example shows how to create a device file associated with your first floppy drive and could be useful if you happened to accidentally erase it. The options are: b=block mode device (c=character mode device, p=FIFO device, u=unbuffered character mode device). The two integers specify the major and the minor device number. fdformat /dev/fd0H1440 mkfs -c -t ext2 (=floppy disk format, two commands, as root) Perform a low-level formatting of a floppy in the first floppy drive (/dev/fd0), high density (1440 kB). Then make a Linux filesystem (-t ext2), checking/marking bad blocks (-c ). Making the files system is an equivalent to the high-level format. badblocks /dev/fd01440 1440 (as root) Check a high-density floppy for bad blocks and display the results on the screen. The parameter "1440" specifies that 1440 blocks are to be checked. This command does not modify the floppy. fsck -t ext2 /dev/hda2 (=file system check, as root) Check and repair a filesystem. The example uses the partition hda2, filesystem type ext2. dd if=/dev/fd0H1440 of=floppy_image dd if=floppy_image of=/dev/fd0H1440 (two commands, dd="data duplicator") Create an image of a floppy to the file called "floppy_image" in the current directory. Then copy floppy_image (file) to another floppy disk. Works like DOS "DISKCOPY". Program installation rpm -ivh filename.rpm (=RedhatPackageManager, install, verbose, hashes displayed to show progress, as root.) Install a content of RedHat rpm package(s) and print info on what happened. Keep reading if you prefer a GUI installation. rpm -qpi filename.rpm (=RedhatPackageManager, query, package, list.) Read the info on the content of a yet uninstalled package filename.rpm. rpm -qpl filename.rpm (=RedhatPackageManager, query, package, information.) List the files contained in a yet uninstalled package filename.rpm. rpm -qf filename (=RedhatPackageManager, query, file.) Find out the name of the *.rpm package to which the file filename (on your hardrive) belongs. rpm -e packagename (=RedhatPackageManager, erase=uninstall.) Uninstall a package pagckagename. Packagname is the same as the beginning of the *.rpm package file but without the dash and version number. kpackage gnorpm glint (in X terminal, as root if you want to be able to install packages) GUI fronts to the Red Hat Package Manager (rpm). "glint" comes with RH5.2, "gnorpm" with RH6.0, "kpackage" comes with RH6.1 or must be installed separately but is the best of the three. Use any of them to view which software packages are installed on your system and the what not-yet-installed packages are available on your RedHat CD, display the info about the packages, and install them if you want (installation must be done as root). Accessing drives/partitions mount See here for details on mounting drives. Examples are shown in the next commands. mount -t auto /dev/fd0 /mnt/floppy (as root) Mount the floppy. The directory /mnt/floppy must exist, be empty and NOT be your current directory. mount -t auto /dev/cdrom /mnt/cdrom (as root) Mount the CD. You may need to create/modify the /dev/cdrom file depending where your CDROM is. The directory /mnt/cdrom must exist, be empty and NOT be your current directory. mount /mnt/floppy (as user or root) Mount a floppy as user. The file /etc/fstab must be set up to do this. The directory /mnt/floppy must not be your current directory. mount /mnt/cdrom (as user or root) Mount a CD as user. The file /etc/fstab must be set up to do this. The directory /mnt/cdrom must not be your current directory. umount /mnt/floppy Unmount the floppy. The directory /mnt/floppy must not be your (or anybody else's) current working directory. Depending on your setup, you might not be able to unmount a drive that you didn't mount. 7.6 Network administration tools netconf (as root) A very good menu-driven setup of your network. pingmachine_name Check if you can contact another machine (give the machine's name or IP), press <Ctrl>C when done (it keeps going). route -n Show the kernel routing table. nslookup host_to_find Query your default domain name server (DNS) for an Internet name (or IP number) host_to_find. This way you can check if your DNS works. You can also find out the name of the host of which you only know the IP number. traceroute host_to_trace Have a look how you messages trave to host_to_trace (which is either a host name or IP number). ipfwadm -F -p m (for RH5.2, seen next command for RH6.0) Set up the firewall IP forwarding policy to masquerading. (Not very secure but simple.) Purpose: all computers from your home network will appear to the outside world as one very busy machine and, for example, you will be allowed to browse the Internet from all computers at once. echo 1 > /proc/sys/net/ipv4/ip_forward ipfwadm-wrapper -F -p deny ipfwadm-wrapper -F -a m -S xxx.xxx.xxx.0/24 -D 0.0.0.0/0 (three commands, RH6.0). Does the same as the previous command. Substitute the "x"s with digits of your class "C" IP address that you assigned to your home network. See here for more details. In RH6.1, masquarading seems broken to me--I think I will install Mandrake Linux:). ifconfig (as root) Display info on the network interfaces currently active (ethernet, ppp, etc). Your first ethernet should show up as eth0, second as eth1, etc, first ppp over modem as ppp0, second as ppp1, etc. The "lo" is the "loopback only" interface which should be always active. Use the options (see ifconfig --help) to configure the interfaces. ifup interface_name (/sbin/ifup to it run as a user) Startup a network interface. E.g.: ifup eth0 ifup ppp0 Users can start up or shutdown the ppp interface only when the right permission was checked during the ppp setup (using netconf ). To start a ppp interface (dial-up connection), I normally use kppp available under kde menu "internet". ifdown interface_name (/sbin/ifdown to run it as a user). Shut down the network interface. E.g.: ifdown ppp0 Also, see the previous command. netstat | more Displays a lot (too much?) information on the status of your network. Music-related commands cdplay play 1 Play the first track from a audio CD. eject Get a free coffee cup holder )). (Eject the CD ROM tray). play my_file.wav Play a wave file. mpg123 my_file.mp3 Play an mp3 file. mpg123 -w my_file.wav my_file.mp3 Create a wave audio file from an mp3 audio file. knapster (in X terminal) Start the program to downolad mp3 files that other users of napster have displayed for downloading. Really cool! cdparanoia -B "1-" (CD ripper) Read the contents of an audio CD and save it into wavefiles in the current directories, one track per wavefile. The "1-" means "from track 1 to the last". -B forces putting each track into a separate file. playmidi my_file.mid Play a midi file. playmidi -r my_file.mid will display text mode effects on the screen. sox (argument not given here) Convert from almost any audio file format to another (but not mp3s). See man sox. Graphics-related commands kghostview my_file.ps Display a postscript file on screen. I can also use the older-looking ghostview or gv for the same end effect. ps2pdf my_file.ps my_file.pdf Make a pdf (Adobe portable document format) file from a postscript file. gimp (in X terminal) A humble looking but very powerful image processor. Takes some learning to use, but it is great for artists, there is almost nothing you can't do with gimp. Use your mouse right button to get local menus, and learn how to use layers. Save your file in the native gimp file format *.xcf (to preserve layers) and only then flatten it and save as png (or whatever). There is a large user manual /usr/ gphoto (in X terminal) Powerful photo editor. giftopnm my_file.giff > my_file.pnm pnmtopng my_file.pnm > my_file.png Convert the propriatory giff graphics into a raw, portable pnm file. Then convert the pnm into a png file, which is a newer and better standard for Internet pictures (better technically plus there is no danger of being sued by the owner of giff patents) regards, Prakash.M 9840304424

vpn=linux Chapter 2. Theory 2.1. What is a VPN? VPN stands for Virtual Private Network. A VPN uses the Internet as it's transport mechanism, while maintaining the security of the data on the VPN. ----------------------------------------------------------------------------- 2.2. But really, what IS a VPN? There are several answers to that question. It really depends on your network layout. The most common configuration is to have a single main internal network with remote nodes using VPN to gain full access to the central net. The remote nodes are commonly remote offices or employees working from home. You can also link two small (or large) networks to form an even larger single network. ----------------------------------------------------------------------------- 2.3. So how does it work? Put simply, to make a VPN, you create a secure tunnel between the two networks and route IP through it. If I've lost you already, you should read [http://www.tldp.org/HOWTO/'>http://www.tldp.org/HOWTO/Networking-Overview-HOWTO.html]'>http://www.tldp.org/HOWTO/Networking-Overview-HOWTO.html] The Linux Networking Overview HOWTO to learn more about networking with Linux. Here are some diagrams to illustrate this concept: \ \ -------- / / -------- Remote ______| Client |______\ Internet \_____| Server |______ Private Network | Router | / / | Router | Network -------- \ \ -------- / / Client Router ---------------------------------------------------- | /-> 10.0.0.0/255.0.0.0 \ | Remote | |--> 172.16.0.0/255.240.0.0 |--> Tunnel >---\ | Network >---|--|--> 192.168.0.0/255.255.0.0 / |--|----> Internet 192.168.12.0 | | | | | \-----> 0.0.0.0/0.0.0.0 --> IP Masquerade >--/ | ---------------------------------------------------- Server Router ---------------------------------------------------- | /-> 10.0.0.0/255.0.0.0 \ | | /--> Tunnel >--|--> 172.16.0.0/255.240.0.0 |--|----> Private Internet >--|--| \--> 192.168.0.0/255.255.0.0 / | Network | | | 172.16.0.0/12 | \-----> 0.0.0.0/0.0.0.0 -----> /dev/null | 192.168.0.0/16 ---------------------------------------------------- The above diagram shows how the network might be set up. If you don't know what IP Masquerading is, you should probably read the The Linux Networking Overview HOWTO and come back once you understand how it works. The Client Router is a Linux box acting as the gateway/firewall for the remote network. The remote network uses the local IP address 192.168.12.0. For the sake of a simple diagram, I left out the local routing information on the routers. The basic idea is to route traffic for all of the private networks (10.0.0.0, 172.16.0.0, and 192.168.0.0) through the tunnel. The setup shown here is one way. That is, while the remote network can see the private network, the private network cannot necessarily see the remote network. In order for that to happen, you must specify that the routes are bidirectional. From the diagram you should also note that all of the traffic coming out of the client router appears to be from the client router, that is, all from one IP address. You could route real numbers from inside your network but that brings all sorts of security problems with it. ----------------------------------------------------------------------------- 2.4. SSH and PPP The system that I describe to implement VPN uses SSH and PPP. Basically I use ssh to create a tunnel connection, and then use pppd to run TCP/IP traffic though it. That's what makes up the tunnel. The real trick to getting ssh and pppd to play well together is the utility written by Arpad Magosanyi that allows the redirection of standard in and standard out to a pseudo tty. This allows pppd to talk through ssh as if it were a serial line. On the server side, pppd is run as the users shell in the ssh session, completing the link. After that, all you need to do is the routing. ----------------------------------------------------------------------------- 2.5. Alternative VPN Systems There are of course other ways of setting up a VPN. Here are a couple of other systems: ----------------------------------------------------------------------------- 2.5.1. PPTP PPTP is a Microsoft protocol for VPN. It is supported under Linux, but is known to have serious security issues. I do not describe how to use it here since it is covered by the [http://www.tldp.org/HOWTO/ VPN-Masquerade-HOWTO.html] Linux VPN Masquerade HOWTO. ----------------------------------------------------------------------------- 2.5.2. IP Sec IP Sec is a different set of protocols from SSH. I don't actually know all that much about it, so if someone wants to help me out with a description, I'd be most appreciative. Again, I do not describe how to use it here since it is covered by the [http://www.tldp.org/HOWTO/VPN-Masquerade-HOWTO.html] Linux VPN Masquerade HOWTO. ----------------------------------------------------------------------------- 2.5.3. CIPE CIPE is a kernel level network encryption system that may be better suited to enterprise setups. You can find out more about it at [http://sites.inka.de /sites/bigred/devel/cipe.html] the CIPE homepage. ----------------------------------------------------------------------------- Chapter 3. Server This section tells you how to set up the server side of things. I figured that this should go first since without a server, your client is kind of useless. ----------------------------------------------------------------------------- 3.1. Security - keeping people out Security is very important for a VPN. That's why you're building one in the first place, isn't it? You need to keep a few things in mind while setting up your server. ----------------------------------------------------------------------------- 3.1.1. Trim your daemons Since this server is going to be on both sides of your firewall, and set up to forward traffic into your network, it's a good idea to secure the box as well as you possibly can. You can read up more on Linux security in the [/ HOWTO/Security-HOWTO.html] Linux Security HOWTO. In this case I killed everything but sshd and a Roxen Web server. I use the web server to download a couple of files (my scripts, etc) for setting up new machines to access the VPN. I don't use an FTP server since it's harder to configure one to be secure than it is to just make a few files available with a web server. Plus, I only need to be able to download files. If you really want to run different servers on your gateway, you might want to think about restricting access to them to only those machines on your private network. ----------------------------------------------------------------------------- 3.1.2. Don't allow passwords Yes, it sounds kind of silly, but it got your attention, didn't it? No, you don't use passwords, you disable them completely. All authentication on this machine should be done via ssh's public key authentication system. This way, only those with keys can get in, and it's pretty much impossible to remember a binary key that's 530 characters long. So how do you do that? It requires editing the /etc/passwd file. The second field contains either the password hash, or alternatively 'x' telling the authentication system to look in the /etc/shadow file. What you do is change that field to read "*" instead. This tells the authentication system that there is no password, and that none should be allowed. Here's how a typical /etc/passwd file looks: ... nobody:x:65534:100:nobody:/dev/null: mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash joe:*:504:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd bill:*:504:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd frank:*:504:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd ... Note that I've done more than just editing the second field. I'll explain the other fields later on. ----------------------------------------------------------------------------- 3.2. User Access - letting people in User access is done via ssh's authentication scheme. As stated above, this is how users get access to the system, while maintaining a high level of security. If you're not familiar with ssh, check out [http://www.ssh.org/] http://www.ssh.org/. Note that I am using ssh version 1, not version 2. There is a big difference, notably that version 1 is free, and 2 isn't. ----------------------------------------------------------------------------- 3.2.1. Configuring sshd You'll need to configure sshd. The idea is to disable password authentication and rhosts authentication. The following options should be present in your /etc/sshd_config file. PermitRootLogin yes IgnoreRhosts yes StrictModes yes QuietMode no CheckMail no IdleTimeout 3d X11Forwarding no PrintMotd no KeepAlive yes RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication no PermitEmptyPasswords no UseLogin no ----------------------------------------------------------------------------- 3.3. Restricting Users Now that you're keeping the bad people out, and only letting the good people in, you may need to make sure that the good people behave themselves. This is most easily done by not letting them do anything except run pppd. This may or may not be necessary. I restrict users because the system that I maintain is dedicated to VPN, so users have no business doing anything else on it. ----------------------------------------------------------------------------- 3.3.1. sudo or not sudo There is this neat little program called sudo that allows the admin on a Unix system to grant certain users the ability to run certain programs as root. This is necessary in this case since pppd must be run as root. You'll need to use this method if you want to allow users shell access. Read up on how to setup and use sudo in the sudo man page. Using sudo is best on multi-use systems that typically host a small number of trusted users. If you decide to not allow users to have shell access, then the best way to keep them from gaining it is to make their shell pppd. This is done in the / etc/passwd file. You can see /etc/passwd file that I did this for the last three users. The last field of the /etc/passwd file is the user's shell. You needn't do anything special to pppd in order to make it work. It gets executed as root when the user connects. This is certainly the simplest setup to be had, as well as the most secure, and ideal for large scale and corporate systems. I describe exactly what all needs to be done later in this document. You can Section 5.7 if you like. ----------------------------------------------------------------------------- 3.4. Networking Now that your users have access to the system, we need to make sure that they have access to the network. We do that by using the Linux kernel's firewalling rules and routing tables. Using the route and ipfwadm commands, we can set up the kernel to handle network traffic in the appropriate ways. For more info on ipfwadm, ipchains and route see the [http://www.tldp.org/ HOWTO/Linux-Networking-HOWTO.html] Linux Networking HOWTO. ----------------------------------------------------------------------------- 3.4.1. The Kernel In order for any of this to work, you must have your kernel configured correctly. If you don't know how to build your own kernel, then you should read the [http://www.tldp.org/HOWTO/Kernel-HOWTO.html] Kernel HOWTO. You'll need to make sure that the following kernel options are turned on in addition to basic networking. I use a 2.0.38 kernel in my system. For 2.0 kernels: * CONFIG_FIREWALL * CONFIG_IP_FORWARD * CONFIG_IP_FIREWALL * CONFIG_IP_ROUTER * CONFIG_IP_MASQUERADE (optional) * CONFIG_IP_MASQUERADE_ICMP (optional) * CONFIG_PPP For 2.2 kernels: * CONFIG_FIREWALL * CONFIG_IP_ADVANCED_ROUTER * CONFIG_IP_FIREWALL * CONFIG_IP_ROUTER * CONFIG_IP_MASQUERADE (optional) * CONFIG_IP_MASQUERADE_ICMP (optional) * CONFIG_PPP ----------------------------------------------------------------------------- 3.4.2. Filter Rules First, we write firewall filter rules that allow our users to access our internal nets, while restricting them from accessing the outside internet. This sounds strange, but since the users already have access to the internet, why let them use the tunnel to access the net? It wastes both bandwidth and processor resources. The filter rules that we use depend upon which internal nets we use, but translate to: "Allow traffic coming from our VPNs that is destined for our internal nets to go there." So how do we do that? As always, it depends. If you are running a 2.0 kernel, you use the tool called ipfwadm, but if you are using a 2.2 kernel, you use the utility called ipchains. To set the rules with ipfwadm, run it with options similar to the following: # /sbin/ipfwadm -F -f # /sbin/ipfwadm -F -p deny # /sbin/ipfwadm -F -a accept -S 192.168.13.0/24 -D 172.16.0.0/12 To set the rules with ipchains, run it with options similar to the following: # /sbin/ipchains -F forward # /sbin/ipchains -P forward DENY # /sbin/ipchains -A forward -j ACCEPT -s 192.168.13.0/24 -d 172.16.0.0/12 For those using 2.2 kernels, please read Section 6.1.3. ----------------------------------------------------------------------------- 3.4.3. Routing Now that users are allowed to access our nets, we need to tell the kernel where to send the packets. On my system, I have two ethernet cards, one is on the external network, while the other is on the internal network. This helps keep things secure, as outbound traffic is masqueraded by the gateway, and any incoming traffic is filtered and routed by the Cisco Router. For most setups, the routing should be simple. Next, route all traffic destined for the private networks out the internal interface, and all other traffic out the external interface. The specific routing commands depend on which internal nets you are using. Below is an example of what they might look like. These lines are of course in addition to your basic routes for your local nets. I also doubt that you are using all 3 groups of internal numbers: Assuming that 172.16.254.254 is the internal gateway: # /sbin/route add -net 10.0.0.0 netmask 255.0.0.0 gw 172.16.254.254 dev eth1 # /sbin/route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.16.254.254 dev eth1 # /sbin/route add -net 192.168.0.0 netmask 255.255.0.0 gw 172.16.254.254 dev eth1 One additional note on routing. If you are using two way routing for say, a remote office, then you will need to do one more thing. You need to set up routes on the server that point back to the client. The easiest way to accomplish this is to run a cron job every minute that quietly sets back routes. If the client is not connected, route will just spit out an error (that you've conveniently sent to /dev/null.) ----------------------------------------------------------------------------- Chapter 4. Client Now we examine the client end. In practice, when used to allow access to a remote network, this box can easily serve as a Samba (Windows Networking) server, DHCP server, and even an internal web server. The important thing to remember is that this box should be as secure as possible, as it runs your whole remote network. ----------------------------------------------------------------------------- 4.1. The Kernel First things first, you must have ppp available in your kernel. If you are going to allow multiple machines to use the tunnel, then you need to have firewalling and forwarding available too. If the client is going to be a single machine, ppp is enough. ----------------------------------------------------------------------------- 4.2. Bring up the link The link is created by running pppd through a pseudo terminal that is created by pty-redir and connected to ssh. This is done with something similar to the following sequence of commands: # /usr/sbin/pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c blowfish -i /root/.ssh/identity.vpn -l joe > /tmp/vpn-device # sleep 10 # /usr/sbin/pppd `cat /tmp/vpn-device` # sleep 15 # /sbin/route add -net 172.16.0.0 gw vpn-internal.mycompany.com netmask 255.240.0.0 # /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask 255.255.0.0 What this does is run ssh, redirecting the input and output to pppd. The options passed to ssh configure it to run without escape characters (-e), using the blowfish crypto algorithm (-c), using the identity file specified (-i), in terminal mode (-t), with the options 'Batchmode yes' (-o). The sleep commands are used to space out the executions of the commands so that each can complete their startup before the next is run. ----------------------------------------------------------------------------- 4.3. Scripting If you don't want to have to type those commands in every time that you want to get the tunnel running, I've written a set of bash scripts that keep the tunnel up and running. You can download the package from [http:// www.shinythings.com/vpnd/vpnd.tar.gz] here. Just download and uncompress it into /usr/local/vpn. Inside you'll find three files: * vpnd: The script that controls the tunnel connection. * check-vpnd: a script to be run by cron to check that vpnd is still up. * pty-redir: a small executable needed to initialize the tunnel. You'll need to edit the vpnd script to set things like the client's username and the server's names. You may also need to modify the starttunnel section of the script to specify which networks you are using. Below is a copy of the script for your reading enjoyment. You'll note that you could put the script in a different directory, you just need to change the VPN_DIR variable. #! /bin/bash # # vpnd: Monitor the tunnel, bring it up and down as necessary # USERNAME=vpn-username IDENTITY=/root/.ssh/identity.vpn VPN_DIR=/usr/local/vpn LOCK_DIR=/var/run VPN_EXTERNAL=vpn.mycompany.com VPN_INTERNAL=vpn-internal.mycompany.com PTY_REDIR=${VPN_DIR}/pty-redir SSH=${VPN_DIR}/${VPN_EXTERNAL} PPPD=/usr/sbin/pppd ROUTE=/sbin/route CRYPTO=blowfish PPP_OPTIONS="noipdefault ipcp-accept-local ipcp-accept-remote local noauth nocrtscts lock nodefaultroute" ORIG_SSH=/usr/bin/ssh starttunnel () { $PTY_REDIR $SSH -t -e none -o 'Batchmode yes' -c $CRYPTO -i $IDENTITY -l $USERNAME > /tmp/vpn-device sleep 15 $PPPD `cat /tmp/vpn-device` $PPP_OPTIONS sleep 15 # Add routes (modify these lines as necessary) /sbin/route add -net 10.0.0.0 gw $VPN_INTERNAL netmask 255.0.0.0 /sbin/route add -net 172.16.0.0 gw $VPN_INTERNAL netmask 255.240.0.0 /sbin/route add -net 192.168.0.0 gw $VPN_INTERNAL netmask 255.255.0.0 } stoptunnel () { kill `ps ax | grep $SSH | grep -v grep | awk '{print $1}'` } resettunnel () { echo "reseting tunnel." date >> ${VPN_DIR}/restart.log eval stoptunnel sleep 5 eval starttunnel } checktunnel () { ping -c 4 $VPN_EXTERNAL 2>/dev/null 1>/dev/null if [ $? -eq 0 ]; then ping -c 4 $VPN_INTERNAL 2>/dev/null 1>/dev/null if [ $? -ne 0 ]; then eval resettunnel fi fi } settraps () { trap "eval stoptunnel; exit 0" INT TERM trap "eval resettunnel" HUP trap "eval checktunnel" USR1 } runchecks () { if [ -f ${LOCK_DIR}/tunnel.pid ]; then OLD_PID=`cat ${LOCK_DIR}/vpnd.pid` if [ -d /proc/${OLD_PID} ]; then echo "vpnd is already running on process ${OLD_PID}." exit 1 else echo "removing stale pid file." rm -rf ${LOCK_DIR}/vpnd.pid echo $$ > ${LOCK_DIR}/vpnd.pid echo "checking tunnel state." eval checktunnel fi else echo $$ > ${LOCK_DIR}/vpnd.pid eval starttunnel fi } case $1 in check) if [ -d /proc/`cat ${LOCK_DIR}/vpnd.pid` ]; then kill -USR1 `cat ${LOCK_DIR}/vpnd.pid` exit 0 else echo "vpnd is not running." exit 1 fi ;; reset) if [ -d /proc/`cat ${LOCK_DIR}/vpnd.pid` ]; then kill -HUP `cat ${LOCK_DIR}/vpnd.pid` exit 0 else echo "vpnd is not running." exit 1 fi ;; --help | -h) echo "Usage: vpnd [ check | reset ]" echo "Options:" echo " check Sends running vpnd a USR1 signal, telling it to check" echo " the tunnel state, and restart if neccesary." echo " reset Sends running vpnd a HUP signal, telling it to reset" echo " it's tunnel connection." ;; esac ln -sf $ORIG_SSH $SSH settraps runchecks while true; do i=0 while [ $i -lt 600 ]; do i=((i+1)) sleep 1 done eval checktunnel done ----------------------------------------------------------------------------- 4.4. LRP - Linux Router Project I actually run this setup on Pentium 90's running the LRP distribution of Linux. LRP is a distribution of Linux that fits in, and boots off of a single floppy disk. You can learn more about it at [http://www.linuxrouter.org/] http://www.linuxrouter.org/ You can download my LRP package for the VPN client from [http://www.shinythings.com/vpnd/vpnd.lrp] here. You will also need both the ppp and ssh packages from the LRP site. ----------------------------------------------------------------------------- Chapter 5. Implementation In this section, I explain step by step how to set up your VPN system. I'll start with the server, and then move on to the client. For the purposes of an example, I will invent a situation that would require a couple of different kinds of VPN set up. ----------------------------------------------------------------------------- 5.1. Planning Let's imagine that we have a company, called mycompany.com. At our head office, we are using the 192.168.0.0 reserved network, breaking the class B into 256 class C networks to allow routing. We have just set up two small remote offices, and want to add them to our network. We also want to allow employees who work from home to be able to use their DSL and cable modem connections instead of making them use dialup. To start, we need to plan things out a little. I decide that I want to give each remote office a class C network range to allow them to expand as necessary. So, I reserve the 192.168.10.0 and 192.168.11.0 nets. I also decide that for home users, I've got enough numbers that I don't need to masquerade them on the VPN server side. Each client gets it's own internal IP. So, I need to reserve another class C for that, say 192.168.40.0. The only thing that I must now do is to add these ranges to my router. Let's imagine that our company owns a small Cisco (192.168.254.254) that handles all of the traffic through our OC1. Just set routes on the Cisco such that traffic headed to these reserved nets goes to our VPN server (192.168.40.254). I put the VPN server into the home user's net for reasons that should become clear later. We'll name the external interface of the server vpn.mycompany.com, and the internal vpn-internal.mycompany.com. As for external numbers, we don't need to know them explicitly. You should have your own numbers, supplied by your ISP. ----------------------------------------------------------------------------- 5.2. Gather the tools We will need a few pieces of software. Get the following packages, and install them where specified. ----------------------------------------------------------------------------- 5.2.1. For the Server: * pppd (version 2.3 or greater) * ssh (version 1.2.26 or better) ----------------------------------------------------------------------------- 5.2.2. For the Client: * pppd (same version as server) * ssh * [ftp://ftp.vein.hu/ssa/contrib/mag/pty-redir-0.1.tar.gz] pty-redir ----------------------------------------------------------------------------- 5.3. Server: Build the kernel To start, you probably need to rebuild your kernel for the server. You need to make sure that the following kernel options are turned on in addition to basic networking and everything else that you might need. If you've never built your own kernel before, read the [/HOWTO/Kernel-HOWTO.html] Kernel HOWTO. For 2.0 kernels: * CONFIG_FIREWALL * CONFIG_IP_FORWARD * CONFIG_IP_FIREWALL * CONFIG_IP_ROUTER * CONFIG_PPP For 2.2 kernels: * CONFIG_FIREWALL * CONFIG_IP_ADVANCED_ROUTER * CONFIG_IP_FIREWALL * CONFIG_IP_ROUTER * CONFIG_PPP ----------------------------------------------------------------------------- 5.4. Server: Configure Networking If you are building a server that has only one network card, I suggest that you think about buying another, and rewiring your network. The best way to keep your network private is to keep it on it's own wires. So if you do have two network cards, you'll need to know how to configure both of them. We'll use eth0 for the external interface, and eth1 for the internal interface. ----------------------------------------------------------------------------- 5.4.1. Configuring the interfaces We first should configure the external interface of the server. You should already know how to do this, and probably already have it done. If you don't, then do so now. If you don't know how, go back and read the [/HOWTO/ NET3-4-HOWTO.html] Networking HOWTO Now we bring up the internal interface. According to the numbers that we've chosen, the internal interface of the server is 192.168.40.254. so we have to configure that interface. For 2.0 kernels, use the following: # /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast 192.168.40.255 # /sbin/route add -net 192.168.40.0 netmask 255.255.255.0 dev eth1 For 2.2 kernels, use the following: # /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast 192.168.40.255 That gets our basic interfaces up. You can now talk to machines on both local networks that are attached to the server. ----------------------------------------------------------------------------- 5.4.2. Setting routes We can now talk to machines on our local nets, but we can't get to the rest of our internal network. That requires a few more lines of code. In order to reach the other machines on other subnets, we need have a route that tells traffic to go to the Cisco router. Here's that line: # /sbin/route add -net 192.168.0.0 gw 192.168.254.254 netmask 255.255.0.0 dev eth1 That line tells the kernel that any traffic destined for the 192.168.0.0 network should go out eth1, and that it should be handed off to the Cisco. Traffic for our local net still gets where it is supposed to because the routing tables are ordered by the size of the netmask. If we were to have other internal nets in our network, we would have a line like the above for each net. ----------------------------------------------------------------------------- 5.4.3. Making filter rules Now that we can reach every machine that we could need to, we need to write the firewall filtering rules that allow or deny access through the VPN server. To set the rules with ipfwadm, run it like so: # /sbin/ipfwadm -F -f # /sbin/ipfwadm -F -p deny # /sbin/ipfwadm -F -a accept -S 192.168.40.0/24 -D 192.168.0.0/16 # /sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16 # /sbin/ipfwadm -F -a accept -b -S 192.168.11.0/24 -D 192.168.0.0/16 To set the rules with ipchains, run it like so: # /sbin/ipchains -F forward # /sbin/ipchains -P forward DENY # /sbin/ipchains -A forward -j ACCEPT -s 192.168.40.0/24 -d 192.168.0.0/16 # /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d 192.168.0.0/16 # /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.11.0/24 -d 192.168.0.0/16 This tells the kernel to deny all traffic except for the traffic that is coming from the 192.168.40.0/24 network and destined for the 192.168.0.0/16 network. It also tells the kernel that traffic going between the 192.168.10.0 /24 and 192.168.0.0/16 nets is allowed, and the same for the 192.168.11.0 net. These last two are bidirectional rules, this is important for getting the routing to work going both ways. ----------------------------------------------------------------------------- 5.4.4. Routing For home users, everything will work fine to here. However for the remote offices, we need to do some routing. First of all, we need to tell the main router, or Cisco, that the remote offices are behind the VPN server. So specify routes on the Cisco that tell it to send traffic destined for the remote offices to the VPN server. Now that that is taken care of, we must tell the VPN server what to do with the traffic destined for the remote offices. To do this, we run the route command on the server. The only problem is that in order for the route command to work, the link must be up, and if it goes down, the route will be lost. The solution is to add the routes when the clients connects, or more simply, to run the route command frequently as it's not a problem to run it more than is necessary. So, create a script and add it to your crontab to be run every few minutes, in the script, put the following: /sbin/route add -net 192.168.11.0 gw 192.168.10.253 netmask 255.255.255.0 /sbin/route add -net 192.168.10.0 gw 192.168.11.253 netmask 255.255.255.0 ----------------------------------------------------------------------------- 5.5. Server: Configure pppd Now we will configure pppd on the server to handle VPN connections. If you are already using this server to handle dialup users or even dialing out yourself, then you should note that these changes may affect those services. I go over how to avoid conflicts at the end of this section. ----------------------------------------------------------------------------- 5.5.1. /etc/ppp/ This directory may contain a number of files. You probably already have a file called options. This file holds all of the global options for pppd. These options cannot be overridden by pppd on the command line. ----------------------------------------------------------------------------- 5.5.2. /etc/ppp/options Your options file should contain at least the following: ipcp-accept-local ipcp-accept-remote proxyarp noauth The first two lines tell pppd to accept what the other end specifies for IP addresses. This is necessary when hooking up remote offices, but can be disabled if you are only connecting home users. It's okay to leave it on, as it does not prevent the server from assigning addresses, it only says it that it's okay to accept what the client asks for. The third line is very important. From the pppd man page: proxyarp Add an entry to this system's ARP [Address Resolu- tion Protocol] table with the IP address of the peer and the Ethernet address of this system. This will have the effect of making the peer appear to other systems to be on the local ethernet. This is important because if it is not done, local traffic will not be able to get back through the tunnel. The last line is just as important. This tells pppd to allow connections without username and password. This is safe since authentication is already handled by sshd. ----------------------------------------------------------------------------- 5.5.3. Avoiding conflicts If you are handling other services with pppd, you should consider that the configurations for these other services may not be the same as what the VPN system needs. pppd is designed such that the options in the main options file /etc/ppp/options cannot be overridden by options specified at runtime. This is done for security reasons. In order to avoid conflict, determine which options cause the conflict, and move them from the main file into a separate options file that is loaded when the appropriate application of pppd is run. ----------------------------------------------------------------------------- 5.6. Server: Configure sshd The following is what my /etc/sshd_config file looks like. Yours should look the same or similar: # This is the ssh server system wide configuration file. Port 22 ListenAddress 0.0.0.0 HostKey /etc/ssh_host_key RandomSeed /etc/ssh_random_seed ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin yes IgnoreRhosts yes StrictModes yes QuietMode no FascistLogging yes CheckMail no IdleTimeout 3d X11Forwarding no PrintMotd no KeepAlive yes SyslogFacility DAEMON RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication no PermitEmptyPasswords no UseLogin no The important points to note are that password authentication is disabled as are all of the "R" services. I have also turned off mail checking and the message of the day as they can confuse pppd on the client side. I still allow root login, but as this can only be done with a key, it is adequately safe. ----------------------------------------------------------------------------- 5.7. Server: Set up user accounts Now we'll set up the user accounts. ----------------------------------------------------------------------------- 5.8. Add vpn-users group just run: # /usr/sbin/groupadd vpn-users Now cat the /etc/group file and look at the last line. It should be the entry for the vpn-users group. Note the third field. This is the group ID (GID). Write it down, as we'll need it in a minute. For this example, the GID is 101. ----------------------------------------------------------------------------- 5.9. create the vpn-users home directory We're going to use a single home directory for all of the users. So just run: # mkdir /home/vpn-users ----------------------------------------------------------------------------- 5.10. The .ssh directory Now create the .ssh directory in the vpn-users home directory. # mkdir /home/vpn-users/.ssh ----------------------------------------------------------------------------- 5.11. Adding users Now comes the fun part. We're going to edit the /etc/passwd file by hand. Normally you let the system handle this file, but for an unusual setup like this, it is easier to do it yourself. To start, open the /etc/passwd file and see what's in there. Here's an example of what you might find: ... nobody:x:65534:100:nobody:/dev/null: mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash joe:*:1020:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd bill:*:1020:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd frank:*:1020:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd ... You'll find the first user on most any system. The second one is me. After that are a few made up vpn-users. The first field is the username, and the second is the password field. The third is user ID (UID) and the fourth is the group ID (GID). After that comes some info on who the people are in the fifth field. The sixth field is the user's home directory, and the last is their shell. As you can see, each field is separated by a colon. Look at the last three lines. The only difference between them is the username in the first field, and the user info in the fifth field. What we want to do is create lines like this for each user. Don't just use one user for all of the connections, you'll never be able to tell them apart if you do. So copy the last line of this file and edit it so that it looks something like the above. Make sure that the second field has an asterisk (*). The second field should be unique to all the other IDs in the file. I used 1020. You should use a number above 1000, since those below are typically reserved for system use. The fourth field should be the group ID for vpn-users. I told you to write it down, now is the time that you need it. So put the group ID in there. Lastly, change the home directory to /home/vpn-users, and the shell to /usr/sbin/ pppd. Now copy that line to make more users. Just edit the first the fifth fields and you're set. ----------------------------------------------------------------------------- 5.12. Server: Administration One of the advantages to using this system for user accounts is that you can take advantage of the UNIX user administration commands. Since each client is logged in as a user, you can use standard methods to get user statistics. The following are a few commands that I like to use to see what all is going on. who Prints the users currently logged in, as well as when they logged in, from where (name or IP), and on which port. w This command prints a more extensive listing of who is currently logged in. It also tells you uptime and load averages for the system. It also lists the user's current process (which should be -pppd for VPN clients) as well as idle time, and current CPU usage for all processes as well as the current process. Read the w man page for more info. last [username] This lists the login history for the specified user, or for all users if a username is not provided. It's most useful for finding out how well the tunnels are running as it prints the length of time that the user was logged in, or states that the user is still logged in. I should warn you that on a system that has been up a long time, this list can grow extremely long. Pipe is through grep or head to find out exactly what you want to know. You can also control which users are allowed to connect by modifying the / home/vpn-users/.ssh/authorized_keys file. If you remove the user's public key line from this file, they won't be able to log in. ----------------------------------------------------------------------------- 5.13. Client: Build the kernel Now we move onto the client. First we must rebuild the kernel so that it can support all of the functions that we need. The minimum requirement is to have ppp in the kernel. You will need forwarding, a firewall, and a gateway only if you are going to allow other machines access to the tunnel. For this example, I will setup one of the remote office machines in my example layout. Add the following options to your kernel. Again, if you've never built a kernel before, read the [/HOWTO/Kernel-HOWTO.html] Kernel HOWTO. For 2.0 kernels: * CONFIG_PPP * CONFIG_FIREWALL * CONFIG_IP_FORWARD * CONFIG_IP_FIREWALL * CONFIG_IP_ROUTER * CONFIG_IP_MASQUERADE * CONFIG_IP_MASQUERADE_ICMP For 2.2 kernels: * CONFIG_PPP * CONFIG_FIREWALL * CONFIG_IP_ADVANCED_ROUTER * CONFIG_IP_FIREWALL * CONFIG_IP_ROUTER * CONFIG_IP_MASQUERADE * CONFIG_IP_MASQUERADE_ICMP ----------------------------------------------------------------------------- 5.14. Client: Configure Networking Now we should setup the networking on our client box. Let's assume that we've configured the external network and that it works. Now we will configure the internal interface of the client to service our intranet. ----------------------------------------------------------------------------- 5.14.1. Interface We need to first bring up the internal network interface. To do this, add the following to your /etc/rc.d/rc.inet1 (or equivalent) file: For 2.0 Kernels: /sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0 /sbin/route add -net 192.168.10.0 netmask 255.255.255.0 dev eth1 For 2.2 Kernels: /sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0 ----------------------------------------------------------------------------- 5.14.2. Filter rules To set up the remote office, we will want to set up our filter rules that allow traffic to go both directions through the tunnel. Add the following lines to your /etc/rc.d/rc.inet1 (or equivalent) file: For 2.0 kernels: /sbin/ipfwadm -F -f /sbin/ipfwadm -F -p deny /sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16 For 2.2 kernels: /sbin/ipchains -F forward /sbin/ipchains -P forward DENY /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d 192.168.0.0/16 You may have noticed that these lines look like what we have on the server. That's because they are the same. These rules just say where traffic is allowed to go between these two networks. ----------------------------------------------------------------------------- 5.14.3. Routing The only extra routes that are needed are created by the script that bring the tunnel up. ----------------------------------------------------------------------------- 5.15. Client: Configure pppd You may not need to edit the client's /etc/ppp/options file at all. You will if the "auth" option is present, or some of the other priveledged options. Try it, and if it fails, a black /etc/ppp/options will work. just keep adding the options from the old file to figure out which one broke it (if it's not obvious) and see if you can get around that. Maybe you don't need them at all. You probably don't if you don't use pppd for anything else. ----------------------------------------------------------------------------- 5.16. Client: Configure ssh As root on the client, run the following lines: # mkdir /root/.ssh # ssh-keygen -f /root/.ssh/identity.vpn -P "" This will create two files, identity.vpn and identity.vpn.pub in the .ssh directory. The first is your private key, and should be kept such. Never send this over the net unless it is via an encrypted session. The second file is your public key, and you can send this anywhere you want, it only serves to allow you access to other systems, and cannot be used to get into your own. It is a text file with one line in it that is your actual key. At the end of the line is the comment field which you may change without fear of breaking the key. an example key looks something like this: 1024 35 1430723736674162619588314275167.......250872101150654839 root@vpn-client.mycompany.com It's actually a lot longer than that, but it wouldn't fit on the page if I showed the whole thing. Copy your key into the /home/vpn-users/.ssh/ authorized_keys file on the server. Make sure that there is only one key per line, and that each key is not broken onto multiple lines. You may alter the comment field all that you like in order to help you remember which line goes with which user. I highly recommend doing so. ----------------------------------------------------------------------------- 5.17. Client: Bring up the connection Now we'll try to actually make the connection to the VPN server. First we'll need to make a single connection to set up the ssh known_hosts file. Run this: # ssh vpn.mycompany.com Answer "yes" when it asks you if you want to continue connecting. The server will tell you "permission denied", but that's okay. It's important that you use the same name for the server that you are using in your connection scripts. Now run the following lines. You will obviously need to change the options to suit your setup. # /usr/sbin/pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c blowfish -i /root/.ssh/identity.vpn -l vpn-user vpn.mycompany.com > /tmp/vpn-device

securing linux Securing Linux These instructions are probably specific to RedHat Linux 6.x. If you are running some other distribution you should be familiar with Linux and system management and be able to adapt these instructions. Decide what services you need to provide with this machine. If it is your desktop machine and noone else needs access to it over the network, then you do not need to provide any services to the internet. In that case do not even start up inetd at all. The best way to do this is to just delete /etc/inetd.conf Edit /etc/inetd.conf to stop services that are not needed. Here is what your /etc/inetd.conf file should look like: ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd shell stream tcp nowait root /usr/sbin/tcpd in.rshd login stream tcp nowait root /usr/sbin/tcpd in.rlogind talk dgram udp wait root /usr/sbin/tcpd in.talkd ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd time stream tcp nowait nobody /usr/sbin/tcpd in.timed time dgram udp wait nobody /usr/sbin/tcpd in.timed auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e -o Restrict the services that are staying open to specific machines through the use of tcp wrappers. Tcp wrappers are installed by default on RedHat 5.x machines, but they are not doing anything other than logging. Tcp wrappers use the files /etc/hosts.deny and /etc/hosts.allow to determine which users and domainnames are allowed to connect to services on your machine. Here is /etc/hosts.deny: # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # The portmap line is redundant, but it is left to remind you that # the new secure portmap uses hosts.deny and hosts.allow. In particular # you should know that NFS uses portmap! ALL: ALL portmap: ALL and here is /etc/hosts.allow: # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # ALL: 127.0.0.1, 128.227.64.XXX portmap: 128.227.64.0/255.255.255.0 portmap: 255.255.255.255 0.0.0.0 XXX identifies a particular machine that you want to allow access to. For example you might have the ip number of your office PC if the Linux machine is in your lab and you want to be able to telnet in. After making the above changes send a HUP to the inetd process Test your setup: make sure finger is not answering: finger @localhost check to see if telnet works from the hosts which are allowed: telnet yourhostname from the local machine telnet yourhostname from a machine not listed in /etc/hosts.allow telnet yourhostname from a machine listed in /etc/hosts.allow Next cut back on the daemons started at boot time. To see some of what is being started type /sbin/chkconfig --list. This will tell you which daemons are being started in what runlevels. If you see something like this: atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off gpm 0:off 1:off 2:on 3:on 4:on 5:on 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off nfsfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off random 0:off 1:on 2:on 3:on 4:on 5:on 6:off keytable 0:off 1:off 2:on 3:on 4:on 5:on 6:off pcmcia 0:off 1:off 2:on 3:on 4:on 5:on 6:off linuxconf 0:off 1:off 2:on 3:on 4:on 5:on 6:off lpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off kerneld 0:off 1:on 2:on 3:on 4:on 5:on 6:off inet 0:off 1:off 2:off 3:on 4:on 5:on 6:off portmap 0:off 1:off 2:off 3:on 4:on 5:on 6:off routed 0:off 1:off 2:off 3:on 4:on 5:on 6:off sound 0:off 1:off 2:off 3:on 4:on 5:on 6:off sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off You can start turning things off. For example, routed is being started in run levels three, four, and five. It should not be started, so I type /sbin/chkconfig --del routed Turn off services that are not chkconfig compliant. To do this I like to remove the link from /etc/rc.d/init.d/whatever to /etc/rc.d/rc?.d/SnnWhatever. Basically the way things work is you have startup/shutdown scripts in /etc/rc.d/init.d which are linked to from the different runlevel directories. If you remove the link then the scripts are never called. I don't remove the original script in case I need it later. For example, suppose inetd is being started and the script is not chkconfig compliant. I look for the link by doing: cd /etc/rc.d find . -print | grep inet Here is the output: ./init.d/inet ./rc0.d/K50inet ./rc1.d/K50inet ./rc2.d/K50inet ./rc3.d/S50inet ./rc4.d/S50inet ./rc5.d/S50inet ./rc6.d/K50inet This tells me that inetd is being started in runlevels 3, 4 and 5. I remove the links and then reboot and there are no longer any of the inetd controlled services to worry about. Configure sendmail for queuing only: edit /etc/sysconfig/sendmail and change DAEMON=yes to no create a /etc/sendmail.cf file that forwards to the mail server for Physics. To do this use the clientproto.mc file which comes with sendmail and specify phys.ufl.edu as the mail server. Or you can use the file which I have already made for sendmail 8.9.3. To use this file just backup /etc/mail/sendmail.cf and replace it with mine. If phys.ufl.edu is not your smtp server please look through the cf file and specify your smtp server and domain name. Please remember to edit /etc/aliases and specify that mail destined for "root" goes to the appropriate person. If that person is you then just look for the line in the file with root on the left hand side and put your email address on the right hand side. On current RedHat distributions this line is commented out and the mail goes to "marc." Edit /etc/rc.d/rc.local to stop telling people what kernel you are running and the OS. Just put a welcome message, or some kind of warning in /etc/issue rather than the output of uname. People will telnet to every machine in a subnet looking for a particular revision of RedHat which they know has a security problem. Have the machine scanned for known problems, contact us to schedule this. Restrict the machines that can get an XDM session from you (unless you are serving Xterminals or PC full screen sessions). The file to edit is /etc/X11/xdm/Xaccess. You will want to comment out two lines in this file which allow any machine to be served XDM and also the chooser which responds to broadcasts: #* #any host can get a login window #* CHOOSER BROADCAST #any indirect host can get a chooser Not really related to security, but this is useful info. To have X startup in 16bpp mode rather than 8bpp edit the file /etc/X11/xdm/Xservers and set the line for the local display (screen :0) like so: :0 local /usr/X11R6/bin/X -bpp 16 Once you are sure that X is working fine you can make the machine boot in X by default. To do this edit /etc/inittab and change the default runlevel: # Default runlevel. The runlevels used by RHS are: # 0 - halt (Do NOT set initdefault to this) # 1 - Single user mode # 2 - Multiuser, without NFS (The same as 3, if you do not have networking) # 3 - Full multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) # id:5:initdefault: Reconfigure rsh and install ssh. rsh needs to be moved out of the users path so that it is only used if ssh fails and the user is warned that they are using an insecure protocol. Remove the rsh binary by typing rpm -e rsh Now grab the rpm source file from the ftp site and install it (rpm -i) into /usr/src/redhat/SOURCES the tar file you need is netkit-rsh*.tar.gz Unpack it and configure ./configure --prefix=/usr/notinpath --disable-pam --disable-shadow This only sets the install path for rsh though, edit the file pathnames.h in the rcp and rsh dir to change the path from: #define _PATH_RSH "/usr/bin/rsh" to: #define _PATH_RSH "/usr/notinpath/bin/rsh" When you actually install the programs you will have to make the directories as the Makefile does not do it. Configure ssh to fall back to the rsh binary just installed: ./configure --with-x --with-rsh=/usr/notinpath/bin/rsh \ --program-transform-name='s/^s/r/' --with-libwrap \ --with-etcdir=/etc/ssh --with-rsaref Refer to our general ssh page for more info. Here is what your /etc/inetd.conf should now look like: ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e -o Turn off anonymous ftp access (if you have to have ftp at all) by editing /etc/ftpaccess You will see a line : class all real,guest,anonymous * Just remove the words guest and anonymous from the line.

THE ONE PAGE LINUX MANUAL A summary of useful Linux commands Version 3.0 May 1999 squadron@powerup.com.au Starting & Stopping shutdown -h now Shutdown the system now and do not reboot halt Stop all processes - same as above shutdown -r 5 Shutdown the system in 5 minutes and reboot shutdown -r now Shutdown the system now and reboot reboot Stop all processes and then reboot - same as above startx Start the X system Accessing & mounting file systems mount -t iso9660 /dev/cdrom /mnt/cdrom Mount the device cdrom and call it cdrom under the /mnt directory mount -t msdos /dev/hdd /mnt/ddrive Mount hard disk “d” as a msdos file system and call it ddrive under the /mnt directory mount -t vfat /dev/hda1 /mnt/cdrive Mount hard disk “a” as a VFAT file system and call it cdrive under the /mnt directory umount /mnt/cdrom Unmount the cdrom Finding files and text within files find / -name fname Starting with the root directory, look for the file called fname find / -name ”*fname*” Starting with the root directory, look for the file containing the string fname locate missingfilename Find a file called missingfilename using the locate command - this assumes you have already used the command updatedb (see next) updatedb Create or update the database of files on all file systems attached to the linux root directory which missingfilename Show the subdirectory containing the executable file called missingfilename grep textstringtofind /dir Starting with the directory called dir , look for and list all files containing textstringtofind The X Window System xvidtune Run the X graphics tuning utility XF86Setup Run the X configuration menu with automatic probing of graphics cards Xconfigurator Run another X configuration menu with automatic probing of graphics cards xf86config Run a text based X configuration menu Moving, copying, deleting & viewing files ls -l List files in current directory using long format ls -F List files in current directory and indicate the file type ls -laC List all files in current directory in long format and display in columns rm name Remove a file or directory called name rm -rf name Kill off an entire directory and all it’s includes files and subdirectories cp filename /home/dirname Copy the file called filename to the /home/dirname directory mv filename /home/dirname Move the file called filename to the /home/dirname directory cat filetoview Display the file called filetoview man -k keyword Display man pages containing keyword more filetoview Display the file called filetoview one page at a time, proceed to next page using the spacebar head filetoview Display the first 10 lines of the file called filetoview head -20 filetoview Display the first 20 lines of the file called filetoview tail filetoview Display the last 10 lines of the file called filetoview tail -20 filetoview Display the last 20 lines of the file called filetoview Installing software for Linux rpm -ihv name.rpm Install the rpm package called name rpm -Uhv name.rpm Upgrade the rpm package called name rpm -e package Delete the rpm package called package rpm -l package List the files in the package called package rpm -ql package List the files and state the installed version of the package called package rpm -i --force package Reinstall the rpm package called name having deleted parts of it (not deleting using rpm -e) tar -zxvf archive.tar.gz or tar -zxvf archive.tgz Decompress the files contained in the zipped and tarred archive called archive ./configure Execute the script preparing the installed files for compiling User Administration adduser accountname Create a new user call accountname passwd accountname Give accountname a new password su Log in as superuser from current login exit Stop being superuser and revert to normal user Little known tips and tricks ifconfig List ip addresses for all devices on the machine apropos subject List manual pages for subject usermount Executes graphical application for mounting and unmounting file systems /sbin/e2fsck hda5 Execute the filesystem check utility on partition hda5 fdformat /dev/fd0H1440 Format the floppy disk in device fd0 tar -cMf /dev/fd0 Backup the contents of the current directory and subdirectories to multiple floppy disks tail -f /var/log/messages Display the last 10 lines of the system log. cat /var/log/dmesg Display the file containing the boot time messages - useful for locating problems. Alternatively, use the dmesg command. * wildcard - represents everything. eg. cp from/* to will copy all files in the from directory to the to directory ? Single character wildcard. eg. cp config.? /configs will copy all files beginning with the name config. in the current directory to the directory named configs. [xyz] Choice of character wildcards. eg. ls [xyz]* will list all files in the current directory starting with the letter x, y, or z. linux single At the lilo prompt, start in single user mode. This is useful if you have forgotten your password. Boot in single user mode, then run the passwd command. ps List current processes kill 123 Kill a specific process eg. kill 123 Configuration files and what they do /etc/profile System wide environment variables for all users. /etc/fstab List of devices and their associated mount points. Edit this file to add cdroms, DOS partitions and floppy drives at startup. /etc/motd Message of the day broadcast to all users at login. etc/rc.d/rc.local Bash script that is executed at the end of login process. Similar to autoexec.bat in DOS. /etc/HOSTNAME Conatins full hostname including domain. /etc/cron.* There are 4 directories that automatically execute all scripts within the directory at intervals of hour, day, week or month. /etc/hosts A list of all know host names and IP addresses on the machine. /etc/httpd/conf Paramters for the Apache web server /etc/inittab Specifies the run level that the machine should boot into. /etc/resolv.conf Defines IP addresses of DNS servers. /etc/smb.conf Config file for the SAMBA server. Allows file and print sharing with Microsoft clients. /etc/X11/XF86Confi g Config file for X-Windows. ~/.xinitrc Defines the windows manager loaded by X. ~ refers to user’s home directory. File permissions If the command ls -l is given, a long list of file names is displayed. The first column in this list details the permissions applying to the file. If a permission is missing for a owner, group of other, it is represented by - eg. drwxr-x—x Read = 4 Write = 2 Execute = 1 File permissions are altered by giving the chmod command and the appropriate octal code for each user type. eg chmod 7 6 4 filename will make the file called filename R+W+X for the owner, R+W for the group and R for others. chmod 7 5 5 Full permission for the owner, read and execute access for the group and others. chmod +x filename Make the file called filename executable to all users. X Shortcuts - (mainly for Redhat) Control|Alt + or - Increase or decrease the screen resolution. eg. from 640x480 to 800x600 Alt | escape Display list of active windows Shift|Control F8 Resize the selected window Right click on desktop background Display menu Shift|Control Altr Refresh the screen Shift|Control Altx Start an xterm session Printing /etc/rc.d/init.d/lpd start Start the print daemon /etc/rc.d/init.d/lpd stop Stop the print daemon /etc/rc.d/init.d/lpd status Display status of the print daemon lpq Display jobs in print queue lprm Remove jobs from queue lpr Print a file lpc Printer control tool man subject | lpr Print the manual page called subject as plain text man -t subject | lpr Print the manual page called subject as Postscript output printtool Start X printer setup interface ~/.Xdefaults Define configuration for some Xapplications. ~ refers to user’s home directory. Get your own Official Linux Pocket Protector - includes handy command summary. Visit: www.powerup.com.au/~squadron

10 Red Hat® Linux™ Tips and Tricks 1-800-COURSES www.globalknowledge.com Expert Reference Series of White Papers Written and Provided by Introduction Are you looking for a quick and simple reference guide to help you navigate Red Hat® Linux™ systems? Look no further! Global Knowledge and Red Hat have assembled these 10 Tips and Tricks from Red Hat Certified Engineers® (RHCEs) to give you an edge on managing these systems. 1.Wiping a Hard Drive By Dominic Duval, Red Hat Certified Engineer Have you ever needed to completely wipe out critical data from a hard drive? As we all know, mkfs doesn’t erase a lot. (You already knew this, right?) mkfs and its variants (e.g., mkfs.ext3 and mke2fs) only get rid of a few important data structures on the filesystem, but the data is still there! For a SCSI disk connected as /dev/sdb, a quick dd if=/dev/sdb | strings will let anyone recover text data from a supposedly erased hard drive. Binary data is more complicated to retrieve, but the same basic principle applies: the data was not completely erased. To make things harder for the bad guys, an old trick was to use the ‘dd’ command as a way to erase a drive. Note: This command will erase your disk! dd if=/dev/zero of=/dev/sdb There’s one problem with this: newer, more advanced, techniques make it possible to retrieve data that were replaced with a bunch of 0s. To make it more difficult, if not impossible, for the bad guys to read data that was previously stored on a disk, Red Hat ships the “shred” utility as part of the coreutils RPM package. Launching “shred” on a disk or a partition will write repeatedly (25 times by default) to all locations on the disk. Note: Be careful with this one too! shred /dev/sdb This is currently known to be a very safe way to delete data from a hard drive before, let’s say, you ship it back to the manufacturer for repair or before you sell it on eBay! Compiled by Red Hat Certified Engineers 10 Red Hat® Linux™ Tips and Tricks Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 2 2. How To Determine the Manufacturer of a Laptop Battery By Dominic Duval, Red Hat Certfied Engineer With all the recent news about laptop batteries suddenly exploding, it might be a good idea to determine the manufacturer and model number of the battery that’s currently connected to your laptop. A simple file, included with the 2.6 kernel that runs on Red Hat Enterprise Linux 4, can easily show this information on any laptop running with ACPI enabled: cat /proc/acpi/battery/BAT0/info Look for the “model number” and “OEM info” fields. 3. Sharing a Hot Spare Device in Software RAID By Forrest Taylor, Red Hat Certified Engineer Have you ever wondered if you could share a hot spare device between two software RAID arrays? You can share a hot spare device if you put mdadm in daemon mode and have it poll your RAID arrays. Let's assume that you have two RAID 1 arrays with one hot spare configured in this manner: /dev/md0 RAID1 -- /dev/sda1 /dev/sdb1 /dev/md1 RAID1 -- /dev/sdc1 /dev/sdd1 /dev/sde1 (Hot Spare) This setup shows /dev/md0 with two devices, and /dev/md1 with three devices, with /dev/sde1 as a hot spare. In this scenario, you want to share /dev/sde1 with /dev/md0 if it should need it. To do that, you must configure the /etc/mdadm.conf file and define a spare-group name. In /etc/mdadm.conf, start off by listing all of the devices: echo "DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1" >> /etc/mdadm.conf Scan the RAID arrays for the current details, and add it to the file: mdadm -D -s >> /etc/mdadm.conf /etc/mdadm.conf should now contain something like the following: # Caution, the ARRAY and UUID should be on the same line. Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 3 DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=29bc861f:6f1c72b0:162f7a88:1db03ffe devices=/dev/sda1,/dev/sdb1 ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aee2ae4c:ec7e4bab:51aefe40:9b54af78 devices=/dev/sdc1,/dev/sdd1,/dev/sde1 At this point, you need to create a spare-group entry for each array. The name does not matter, as long as it is the same for each array that you want to share the hot spare device(s). Here, we choose "shared" as the name of the spare-group and add an entry for each ARRAY in the /etc/mdadm.conf file: # Caution, the ARRAY and UUID should be on the same line. DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=29bc861f:6f1c72b0:162f7a88:1db03ffe devices=/dev/sda1,/dev/sdb1 spare-group=shared ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aee2ae4c:ec7e4bab:51aefe40:9b54af78 devices=/dev/sdc1,/dev/sdd1,/dev/sde1 spare-group=shared Once the configuration file is ready, mdadm can run in daemon mode and poll the devices. If mdadm determines that a device has failed, it will look for an array in the same spare-group that contains all of the standard devices plus a hot spare device. If it finds any, it will move the hot spare to the array that needs it. In our case, if /dev/md0 were to lose a device, it would look at /dev/md1 and find the two devices of the array plus a hot spare, and it will move the hot spare device to /dev/md0 and begin the rebuild process. Run mdadm in daemon mode and have it monitor and scan the arrays: mdadm -F -s -m root@localhost -f The default poll time is 60 seconds, but can be changed using the -d option (e.g., -d 300 would poll every 5 minutes). Now test out this feature by failing and removing a device from /dev/md0: mdadm /dev/md0 -f /dev/sda1 -r /dev/sda1 The next time that mdadm polls the devices, it should determine that /dev/md1 has a spare device, and it should move /dev/sde1 to /dev/md0 and rebuild the array. You can then add in /dev/sda1 and it will become your hot spare device: mdadm /dev/md0 -a /dev/sda1 Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 4 4. USB when the Drivers Aren't Available By Dominic Duval, Red Hat Certfied Engineer As a way to save a few valuable pennies on newer PCs, manufacturers are increasingly getting rid of the good old PS/2 keyboard and mouse interfaces. As a result, some recent systems only ship with USB ports to which we need to connect a USB keyboard and mouse. USB is all well and good, but what if the driver for your USB controller is not loaded? In practice, this is not a problem, as Red Hat loads the ehci- hcd and uhci-hcd drivers automatically at boot time. There are situations, namely in emergency mode, where the USB drivers won't be available. So you won't even be able to enter a command. This is due to the fact that in emergency mode all drivers need to be provided in the initrd file under /boot, and USB is not there by default. The trick is to add those drivers, so that they will be available earlier. The 'mkinitrd' command can do precisely that with the '--with' argument (this only works under RHEL4): mkinitrd --with=ehci-hcd --with=uhci-hcd /boot/newinitrd-`uname - r`.img `uname -r` Add a new entry in your grub.conf file (always do backups!) that points to this new initrd image, and you're done! Your USB keyboard now works in emergency mode. 5. Using Proc By Steve Bonneville, Red Hat Certfied Engineer In /proc, there are subdirectories for each process running on the system, named based on the PID number of the process. In each of these directories, there is a fd/ subdirectory that contains files that represent the file descriptors the process currently has open. These files are actually symlinks that point to the actual device, socket, or other file the process currently has open and mapped to that file descriptor. If you have a program that can read input from a file but not from standard input, or that can write to a file but not to standard output, you may be able to cheat by taking advantage of these special files: /proc/self/fd/0 is standard input of the current process /proc/self/fd/1 is standard output of the current process /proc/self/fd/2 is standard error of the current process For example if 'myfilter' can only read from a file, which it takes as its first argument, you can make it read from standard input instead with: 'myfilter /proc/self/fd/0' Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 5 Another example: 'cat filename > /proc/self/fd/2' sends the contents of filename out standard error instead of standard output. Whether these tricks will behave in a sane manner will depend on how the process actually handles the file it opens. 6. Growing the Devices in a RAID Array By Forrest Taylor, Red Hat Certfied Engineer As hard disk space is ever increasing, you may get replacement drives that are significantly larger than the original devices that they replace, so this tip will show how to increase the size of a RAID array using larger partitions to replace smaller partitions in the original RAID array. We will assume that you have a RAID 5 array using three partitions (/dev/sdb1, /dev/sdc1, and /dev/sdd1) on /dev/md0. These partitions are 1 GB each, giving you about 2 GB of usable space. You add new disks and create three partitions (/dev/sde1, /dev/sdf1, and /dev/sdg1) of 5 GB in size. By the end, you should have about 10 GB of usable space. After you have created the partitions and set the partitions type to 0xfd, you can add these devices to the array. They will become hot spares: mdadm /dev/md0 -a /dev/sde1 /dev/sdf1 /dev/sdg1 Fail the original devices one at a time, ensuring that the array rebuilds after each failed device. Note: Do not fail more than one of the original devices without verifying that the array has finished rebuilding. If you fail two devices in a RAID 5 array, you may destroy data! First, fail and remove the first device, and verify that the array has finished rebuilding: mdadm /dev/md0 -f /dev/sdb1 -r /dev/sdb1 watch cat /proc/mdstat Once it has finished rebuilding, fail the second device: mdadm /dev/md0 -f /dev/sdc1 -r /dev/sdc1 watch cat /proc/mdstat Once it has finished rebuilding, fail the third device: mdadm /dev/md0 -f /dev/sdd1 -r /dev/sdd1 watch cat /proc/mdstat Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 6 After it has finished rebuilding, you have replaced all of the 1 GB original devices with the new 5 GB devices. However, we are not finished yet.We have two problems: the RAID array is still only using 1 GB of my 5 GB devices, and the filesystem is still 2 GB. First, grow the RAID array. mdadm can grow the RAID array to a certain size, using the -G and -z options. The -z option can take a currently undocumented argument of max, which will resize the array to the maximum available space: mdadm -G /dev/md0 -z max `cat /proc/mdstat` and `mdadm -D /dev/md0` should show that the array is now using a 5 GB device size. Second, we need to enlarge the filesystem to match. Assuming that you have an ext3 filesystem on /dev/md0, and that you have mounted it, you can increase the size of the filesystem by using ext2online: ext2online /dev/md0 After that command completes, you should see about 10 GB of usable space. 7. Installing Third-Party RPMs By Doug Bunger, Red Hat Certified Engineer After rebuilding a system, it may be necessary to add several additional RPMs. These could be third-party applications or vendor-specific patches. Trying to do an RPM -i or -U with an *.rpm would fail if the process encountered an error. Since the list of RPMs might include packages that were not included with the Red Hat distribution, a -F might not work. In such a case, the following could help: find /start/dir -name "*.rpm" \ -exec rpm -Uvh --aid {} \; The first line of the command would get a list of the RPMs available in the directory (/start/dir, in the example). The second line would install each RPM in turn. Depending on the nature of the RPMs, it may be necessary to issue the command twice, though the --aid option should attempt to resolve dependencies. 8. Partprobe By Richard Keech, Red Hat Certified Engineer Many system administrators may be in the habit of re-booting their systems to make partition changes visible to the kernel. With Red Hat Enterprise Linux, this is not usually necessary. The partprobe command, from the parted package, informs the kernel about changes to partitions. After all, anything that can help you avoid a re-boot has to be a good thing! Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 7 For example: # cat /proc/partitions major minor #blocks name 3 0 58605120 hda 3 1 200781 hda1 3 2 2040255 hda2 3 3 56364052 hda3 8 01018880 sda 8 110224 sda1 # partprobe # cat /proc/partitions major minor #blocks name 3 0 58605120 hda 3 1 200781 hda1 3 2 2040255 hda2 3 3 56364052 hda3 8 0 1018880 sda 8 1 10224 sda1 8 2 1008640 sda2 9. Pyshell By Brad Smith, Red Hat Certified Engineer Python developers: You probably know that the python interpreter can be run in interactive mode, allowing you to quickly try out an approach or prototype a script. Fedora includes an even more powerful version of this tool from an unlikely source. The wxPython-common-gtk2-unicode package provides files related to the wxWindows widget set and, more-or-less unrelated to the rest of the package's contents, a tool called pyshell. Pyshell performs the same basic function as the interactive-mode python interpreter, but with a lot of great bells and whistles. Try importing a module, such as "os" and then referencing an element of the module: >>> import os >>> os. When "." is typed, up pops a list of every property and method within the "os" module. You can use the mouse or arrow keys (plus tab-completion) to select what you want. If you select a method, begining the argument list with "(" pops up a list of the method's accepted arguments and its pydoc string, where applicable. The best part is that, since pyshell reads the pydoc information for each module as it is loaded, this works for any module, including those you've written yourself. Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 8 Moving around within pyshell can take some getting used to. The up arrow moves you up line by line instead of moving through the interpreter's history like it does in the basic interpreter. Ctrl+Up moves through the history. However, the history is in blocks, not lines. So, for example, if you'd defined a class earlier on and then pressed Ctrl+Up, when you reached the class in your history, its whole definition would come up. You could then use the arrow keys to move around the definition, making changes. Ctrl+Enter even allows you to insert new lines into the definition. When you're done, press Enter and the class is re-defined according to your revised code. Pyshell makes it even easier than before to write and test small applications “on the fly.” Once you've got the hang of it, try out the even fancier alternative, pycrust, which integrates a number of tools for browsing structures within the interpreter's memory, viewing output, etc into pyshell.Want more? Try pyalamode, which has all the features of pycrust, plus an integrated version of the pyalacarte text editor, for all your cut-and-pasting needs (cutting and pasting into any other editor works fine too). 10. Un-killable Processes By Johnathan Kupferer, Red Hat Certified Engineer Before Red Hat Enterprise Linux 4, there really wasn't a good way to handle processes that had entered an uninterruptible sleep waiting on an unresponsive NFS server. This was particularly frustrating because the umount man page promises that “-f” will "Force unmount.” This allows an NFS-mounted filesystem to be unmounted if the NFS server is “unreachable." That was how it was supposed to work, with the caveat that the filesystem must have originally been mounted with "soft" or "intr" options.Well, no more. Though the man page doesn't say so, umount -f now comes to the rescue and will unmount hard and uninterruptible mounts. Learn More Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge. Check out our complete Red Hat Linux curriculum at www.globalknowledge.com/redhat. For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to speak with a sales representative. Through expert instruction, you will understand key concepts and how to apply them to your specific work situation. Choose from more than 700 courses, delivered through Classrooms, e-Learning, and On-site sessions, to meet your IT and management training needs. Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 9 regards, Prakash.M 9840304424

ip chain # Red Hat 7.1 Linux firewall using ipchains # May, 2001 # configured by Dennis G. Allard and Don Cohen, http://oceanpark.com # # Permission to copy is granted provided that credit is given # to the author and whatever HOWTOs are used to understand this # stuff. # # No warrenty is implied. Use at your own risk!! # This web page documents my old ipchains firewall. I have # updated my firewall to use iptable and udpated the description # of my firewall at http://oceanpark.com/notes/firewall_example.html. # This file is /etc/sysconfig/ipchains, intended for # consumption by the script /etc/rc.d/init.d/ipchains, # which makes use of the script /sbin/ipchains-restore. # In Red Hat 7.1, the man page for ipchains and for # ipchains-restore does not document the syntax of this # file. I had to read the script to understand better # what is going on. # The firewall that the Red Hat 7.1 installer set up for me # in response to my request for a high level of security # was too restrictive. And, I couldn't find any GUI tool # in either GNOME or KDE to reconfigure the firewall. # For example, the KDE menu item for editing my firewall # showed an empty set of rules even though this file and # the above startup script existed. So I had no confidence # in the GUI firewall tools, resulting in my decision to edit # this file manually. # The network # ----------- # # This firewall was running on a gateway machine having two # ethernet interfaces, an external one, eth0, which is # my DSL connection to my ISP, and an internal one, eth1 # which is assigned to 198.211.65.1, an IP number on my # class C network. I run a web server, DNS server, and # sendmail on the firewall machine itself. # # Using this file in a more complex network would require # some modifications. Particular attention would need to # be given to using the right the IP numbers and interfaces, # among other things. :-) # Running this script # ------------------- # # Red Hat 7.1 runs /etc/rc.d/init.d/ipchains at system # startup, which uses this file as input. You can # turn ipchains on and off via chkconfig. See: # # chkconfig --list | grep ipchains # # You can restart the ipchains firewall via: # # /etc/rc.d/init.d/ipchains restart # # A good way to show your ipchains rules is with: # # ipchains -vnL # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # ACCEPT all UDP packets for certain UDP services # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # SYN packets are specified via the -y flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets (the default input chain policy.) # # In other words, we allow any TCP packet through that is part of an # established TCP connection, but we are very selective in just which # connections we permit to be made to start off with. IMPORTANT: # ipchains is less powerful than iptables since iptables, introduced # in linux kernel 2.4 provides for Stateful Packet Inspection. ipchains # will allow packets in that are not part of an existing TCP connection. # Although such packets will not normally be processed by an application, # they can be used as part of a denial of service attack. We recommend # that you use an iptables firewall, which is able to audit connections # more completely. See: # # IPTABLES Firewall Example # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. By stopping all other packets in their tracks, we limit # attempts to attack our internal network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html # # oceanpark.com firewall rules (using ipchains) # --------------------------------------------- # Tell ipchains-restore what default policies to use... :input ACCEPT :forward ACCEPT :output ACCEPT # The above will accept anything not prevented by the following rules. # Deny any packet coming in on the public internet interface eth0 # which has source address of our local network (attempt to spoof an # address which should never come from any place but eth1) or which # claims to be from the reserved local loop network 127.0.0.0. -A input -i eth0 -s 198.211.65.0/24 -j DENY -A input -i eth0 -s 127.0.0.0/8 -j DENY # Accept all tcp SYN packets for protocols SMTP, HTTP, and SSH # Note, SMTP connections are further audited by my SMTP server -A input -s 0/0 -d 198.211.65.1/32 25 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT # If you query remote DNS servers, permit UDP responses from it # -A input -s <remote DNS server IP> 53 -d 0/0 -p udp -j ACCEPT # I had to add the following line to make my DNS server honor requests # from the public internet. -A input -s 0/0 -d 0/0 53 -p udp -j ACCEPT # Open up IMAP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 143 -p tcp -y -j ACCEPT # Open up FTP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 20 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT # Allow all inputs from the internal and local interfaces -A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT -A input -s 0/0 -d 0/0 -i lo -j ACCEPT # If we wanted to use masqueading (can do even for legit internal IPs) # -A forward -s 198.211.65.78 -j MASQ # Finally, DENY all connection requests to any UDP port not yet provided # for and all SYN connection requests to any TCP port not yet provided # for. Using DENY instead of REJECT means that no 'ICMP port # unreachable' response is sent back to the client attempting to # connect. I.e., DENY just ignores connection attempts. Hence, use of # DENY causes UDP connection requests to time out and TCP connection # requests to hang. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # Note that there is a fundamental difference between UDP and TCP # protocols. With UDP, there is no 'successful connection' response. # With TCP, there is. So an attacking client will be left in the dark # about whether or not the denied UDP packets arrived and will hang # waiting for a response from denied TCP ports. An attacker will not # be able to immediately tell if UDP connection requests are simply # taking a long time, if there is a problem with connectivity between # the attacking client and the server, or if the packets are being # ignored. This increases the amount of time it takes for an attacker # to scan all UDP ports. Similarly, TCP connection requests to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP pot unreachable' response. -A input -s 0/0 -d 0/0 -p udp -j DENY -A input -s 0/0 -d 0/0 -p tcp -y -j DENY # end of firewall rules

ip table # Red Hat Linux firewall using iptables # # Created: October 2002 # Last Revised: August 2006 # # Authors: Dennis G. Allard (allard@oceanpark.com) and Don Cohen (don@isis.cs3-inc.com) # # This script works on on servers running Red Hat 7.3, 8.0, 9.0, and # RHEL ES 3 and 4. Variants of this script are in active use on # many servers. # # No warranty is implied. Use at your own risk!! # Using this script # ----------------- # # I save this file as /etc/sysconfig/iptables-precursor # and then source it and run iptables-save to create # /etc/sysconfig/iptables, which is an input file # consumed by the script /etc/rc.d/init.d/iptables, # which in turn makes use of the script /sbin/iptables-restore. # # Before mucking with setting up iptables, you should # disconnect the machine from the internet. Examine # and understand the current set of iptables rules # before you reconnect to the internet. # # To configure the set of iptables rules: # # /etc/rc.d/init.d/iptables stop # source /etc/sysconfig/iptables-precursor # # To save the current set of iptables rules for use at next reboot: # # iptables-save > /etc/sysconfig/iptables # # To dynamically restart iptables after modifying /etc/sysconfig/iptables: # # /etc/rc.d/init.d/iptables restart # # Note that /etc/rc.d/init.d/iptables is a script. You can read it to # gain understanding of how iptables uses iptables-restore to restore # iptables firewall rules at reboot. # # To examine the current set of rules in effect: # # /etc/rc.d/init.d/iptables status # # However, I prefer to show the current set of rules via: # # iptables -nvL -t filter # iptables -nvL -t nat # # or # # iptables -vL -t filter # iptables -vL -t nat # # # To configure iptables to be used at next system reboot: # # chkconfig --add iptables # # To see if iptables is currently configured to start at boot, do: # # chkconfig --list iptables # # (You might have to do chkconfig --del ipchains to remove ipchains) # # The rest of this file is derived from my old ipchains script. # # A word about routing # -------------------- # # Note that this web page does not discuss routing decisions. Routing # (see the 'ifconfig' and 'route' commands) decides which interface an # incoming packet will be delivered to, i.e. if a given packet will be # 'input' to this machine or be 'forwarded' to some interface for # delivery to another machine, say on an internal network. You should # have your routing configured before you attempt to configure your # firewall. # # Caveat. DNAT and SNAT provide a way for the IPTABLES firewall to modify the # Destination or Source IP addresses of a packet and, in this way, interact # with routing decisions. See section below: 'More about NAT and routing'. # # The network # ----------- # # This firewall is running on a gateway machine having multiple ethernet # interfaces, a public one, eth0, which is a DSL connection to an ISP, # and one or more internal ones, including eth1, which is assigned to # 192.168.0.1, an IP number on my internal private network. My public # network has static IP numbers depicted below as x.y.z.... Actual # IP numbers would, of course, be a sequence of four octets. For this # script, I assume that the firewall is running on the same machine # having the interfaces configued with my public IPs. For this reason, # most of the rules below are INPUT rules. Were I to route some of my public # static IP numbers to interfaces on one or more machines inside the # firewall on the internal network, I would modify certain rules to be # FORWARD rules instead of INPUT rules. I show some examples below of # FORWARD rules. Finally, the script is just for a single server IP, # hence all of the "/32" network masks below. A more realistic situation # would involve using IP ranges and their corresponding network masks. # # The gateway at my ISP is x.y.z.1. I run a few web servers on # x.y.z.w, a DNS server on x.y.z.n, and qmail on x.y.z.m. # # Using this file in a more complex network would require some # modifications. Particular attention would need to be given to using # the right the IP numbers and interfaces, among other things. :-) # # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # ACCEPT all UDP packets for certain UDP services # # Currently the only UDP connections I accept are to my secure DNS # server, tinydns. For an explanation of why tinydns is secure, see: # http://www.faqts.com/knowledge_base/view.phtml/aid/8739/fid/699. # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # # SYN packets are specified via the -syn flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets that are part of existing connections # # DENY all other TCP packets. # # In other words, we allow any TCP packet through that is part of an # established TCP connection, but we are very selective in just which # connections we permit to be made to start off with. # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. This is done via 'Stateful Packet Inspection' provided by the # netfilter functionality added to linux as of kernel 2.4. By stopping all # other packets in their tracks, we limit attempts to attack our internal # network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html # # begin oceanpark.com firewall rules (using iptables) # --------------------------------------------------- # Here we go... # # Configure default policies (-P), meaning default rule to apply if no # more specific rule below is applicable. These rules apply if a more specific rule below # is not applicable. Defaults are to DROP anything sent to firewall or internal # network, permit anything going out. # iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # # Flush (-F) all specific rules # iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat # The rest of this file contains specific rules that are applied in the order # listed. If none applies, then the above policy rules are used. # # Forward all packets from eth1 (internal network) to eth0 (the internet). # iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT # # Forward packets that are part of existing and related connections from eth0 to eth1. # iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT # # Permit packets in to firewall itself that are part of existing and related connections. # iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # Note, in the above two rules, a connection becomes ESTABLISHED in the # iptables PREROUTING chain upon receipt of a SYNACK packet that is a # response to a previously sent SYN packet. The SYNACK packet itself is # considered to be part of the established connection, so no special # rule is needed to allow the SYNACK packet itself. # # Allow all inputs to firewall from the internal network and local interfaces # iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT # # Enable SNAT functionality on eth0 # # SNAT (Source NAT) is used to map private source IP numbers of # interfaces on the internal LAN to one of my public static IP numbers. # SNAT performs this mapping when a client running on one of the # internal hosts (x.y.z.c) initiates a TCP connection (SYN) through # eth0. # iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth0 -j SNAT --to-source x.y.z.c # # Alternative to SNAT -- MASQUERADE # # If your firewall has a dynamic IP number because it connects to the # internet itself via DHCP, then you probably cannot predict what the IP # number is of your firewall's interface connected to the internet. In # this case, you need a rule like the following that assigns the (an) IP # number associated with eth0 to outgoing connections without you needing # to know in advance (at time of writing this rule) what that IP number is: # # iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE # # Note that the above SNAT and MASQUERADE rules are applicable # independent of how a host on the internal network is assigned its own # internal IP number. The host could be assigned a static IP number on # an internal nonpublic network (e.g. 10. or 192.168.) or it could be # itself assigned a dynamic IP number from your own DHCP server running # on the firewall, or it could even have a public static IP number. # However, it seems unlikely that one would want to assign a public IP # number to a host and then proceed to hide that number from the public. # # # Deny any packet coming in on the public internet interface eth0 # which has a spoofed source address from our local networks: # iptables -A INPUT -i eth0 -s x.y.z.s/32 -j DROP iptables -A INPUT -i eth0 -s x.y.z.c/32 -j DROP iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP # # Accept all tcp SYN packets for protocols SMTP, HTTP, HTTPS, and SSH: # (SMTP connections are further audited by our SMTP server) # iptables -A INPUT -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 80 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 443 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # Notice that the above rules are all INPUT rules. My current network # does not require me to make use of FORWARD rules, since I run all # publicly accessible servers directly on my firewall machine. But I # promised above in the description of my network to give examples of # rules used when there are servers running on machines on the internal # network. Following are examples of FORWARD rules I would use if I ran # mail, web, and ssh servers on machines on the internal network inside # the firewall. # # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 80 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 443 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # # The first three of the above four rules would be used if my routing # delivered packets having destination IP x.y.z.m, port 25, or IP # x.y.z.w, port 80 or 443, to an interface connected to my internal # network (i.e. the packet was being FORWARDed). The fourth of the above # four rules is similar but operates on any destination IP, port 22. # # The difference between an INPUT rule and a FORWARD rule is that an # INPUT rule applies to packets that are 'input' to this machine (the # machine on which these iptables firewall rules are installed), whereas # a FORWARD rule applies to packets that are being 'fowarded', i.e. to # packets that are passing through this machine to some other machine, # such as a machine on my internal network. # # If I ran my mail server on an internal machine, I would no longer # need my previous INPUT rule for x.y.z.m and would use the above # FORWARD rule instead. # # # Begin Caveat, More about NAT and routing # # The above talk of routing is independent of the rules defined here. # I.e., routing is determined by ifconfig, route, et. al. I have not # yet seen any very good explanation of how to setup the static routing # table (what you see as output from the `route` command). I will not # attempt to remedy that lacuna at this time. If you know of some # good documenation that completely and accurately explains the # semantics of the ifconfig and route commands, i.e., explains what # affect each has such that I can reliably predict what the output # of `route` will be after executing a sequence of ifconfig and # route commands, then please do let me know. # # What *can* be done by IPTABLES rules that has the 'feel' of routing is # DNAT (Destintion NAT) and SNAT (Source NAT). DNAT and SNAT rules are, # respectively, mechnisms to map the incoming destination IP number and # outgoing source IP number to different IP numbers. For example, SNAT # can be used to map an internal source IP number to any one of your # external public IP numbers so that a workstation on your internal # network will appear to servers on the internet to which it connects to # have a source IP number equal to the mapped public IP number. # # DNAT goes the other way. It is a mechanism used typically to map # public destination IP numbers to internal private IP numbers. (In # fact, DNAT could also map public to public or private to private or # private to public, but that is left as an exercise for the reader). # So, for example, if you run a mail server on a machine configured with # an internal IP number but wish to expose that service to the external # world via a public IP number, DNAT is for you. # # Now, DNAT and SNAT are *not* routing but can *interact* with routing. # Routing decides whether a packet is going to be INPUT to this machine # or be FORWARDed to another machine. That decision is done by routing. # Once that decision is made, and only then, are the IPTABLES filtering # rules (FORWARD and INPUT rules) applied to a given packet. On the # other hand DNAT is applied by a PREROUTING rule and SNAT by a POSTROUTING # rule. It is now time for you to read the following Packet Filtering # HOWTO section: # # http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-9.html # # which states: # # It's common to want to do Network Address Translation (see the # NAT HOWTO) and packet filtering. The good news is that they mix # extremely well. [editor- The NAT HOWTO can be found at: # http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html] # # You design your packet filtering completely *ignoring* any NAT you # are doing. The sources and destinations seen by the packet filter # will be the `real' sources and destinations. For example, if you # are doing DNAT to send any connections to 1.2.3.4 port 80 through # to 10.1.1.1 port 8080, the packet filter would see packets going # to 10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80. # Similarly, you can ignore masquerading: packets will seem to come # from their real internal IP addresses (say 10.1.1.1), and replies # will seem to go back there. # # # Hence, INPUT/FORWARD rules would operate on destination IP numbers # *after* a DNAT rule is applied. But if you don't have any DNAT rules, # then INPUT/FORWARD would apply to the IP numbers as they are in the # incoming packet. # # INPUT or FORWARD would be needed purely depending on whether your # routing would cause the packet to stay on the machine where the # firewall is installed or be forwarded to another machine. THAT # decision is done by routing and *not* by DNAT or SNAT or anything # else in this firewall script. # # It is perfectly possible for the machine having the firewall to have # both public and internal IPs configured and/or for some packets to be # INPUT and others to be FORWARDed. # # DNAT is done by a PREROUTING rule, so you should think of things as # proceeding in the following order: # # 1. apply PREROUTING DNAT rules (if any) to map destination IP # 2. apply routing decisions (see ifconfig et. al.) # 3a. apply INPUT rules to packets having a destination IP on this machine # 3b. apply FORWARD rules to packets having a destination IP elsewhere # 4. apply POSTROUTING SNAT rules (if any) to map source IP # # (3a and 3b can be done in either order since they apply to a mutually # exclusive set of packets) # # I *think* that's correct. # # End Caveat, More about NAT and routing # # # Sometimes I run older versions of SSH on port 2200: # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 2200 --syn -j ACCEPT # # For imapd via stunnel (instead of xinetd-based imapd): # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 993 --syn -j ACCEPT # # For xinetd-based IMAP server (see /etc/xinetd.conf for who can use it): # #iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 143 --syn -j ACCEPT # # For DHCP server: # iptables -A INPUT -i eth1 -p tcp --sport 68 --dport 67 -j ACCEPT iptables -A INPUT -i eth1 -p udp --sport 68 --dport 67 -j ACCEPT # # For LDAP clients: # #iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 389 -syn -j ACCEPT #dga- worry about LDAP later (after I decode LDAP documentation (- # # DNS queries: # # Permit responses from our ISP's DNS server. When a client running on our # host makes a DNS query, the outgoing query is allowed since we permit all # outgoing packets. The reply will be a UDP connection back to the high # numbered client port from which the query was made. So we only need to # permit UDP packets from our ISP's DNS servers back to high numbered ports: # #iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT # # But since we trust our ISP DNS Server not not have been hacked and we may # not be sure what our client IP range is, we loosen this to: # iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 -j ACCEPT # # Running a caching DNS Server # # We need to permit querying a remote DNS server. Since I am running # a caching DNS server on x.y.z.d that makes requests for DNS lookups # to external DNS servers, those servers send back responses via UDP to # the high numbered client port on x.y.z.d where the caching server listens. # I could of course increase security by running the dns cache on its own # machine/IP and restricting to just that machine/IP. # iptables -A INPUT -p udp -s 0/0 --source-port 53 -d x.y.z.d/32 --destination-port 1024:65535 -j ACCEPT # # Running a DNS server (tinydns) # # When we run a DNS server, we have to accept UDP from anywhere to port 53 # iptables -A INPUT -p udp -s 0/0 -d 0/0 --destination-port 53 -j ACCEPT # # Running a Master DNS Server to update slave DNS servers # # You may have your server colocated at an ISP and may arrange to have your # ISP provide your primary and secondary DNS with the ISP DNS servers slaving # off of your master DNS server. This has the advantage of letting you be # in full control of the DNS zone files yet keeping the DNS servers exposed # to the public outside of your network. To achieve this, in addition to # permitting vanilla DNS responses from the ISP DNS serves, you also need # to allow TCP connections from the ISP Master DNS Server: # # Allow DNS zone transfers via TCP from ISP Master DNS server: # # iptables -A INPUT -p tcp -s <ISP Master DNS server IP>/32 -d 0/0 --destination-port 53 --syn -j ACCEPT # # For some other custom server running here listening on port <port number>: # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port <port number> --syn -j ACCEPT # # For FTP server, restricted to specific local hosts (and see /etc/xinetd.conf): # (for public file transfers we use scp, sftp, and related SSH file transfer tools) # iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 20 --syn -j ACCEPT iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 21 --syn -j ACCEPT iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 20 --syn -j ACCEPT iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 21 --syn -j ACCEPT # # For Samba (smbd and nmbd), restricted to specific local client hosts (x.y.z.c): # iptables -A INPUT -p tcp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 139 --syn -j ACCEPT iptables -A INPUT -p udp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 137 -j ACCEPT # #Special cable modem rules. I used to have a third ethernet card, #eth2, attached to a separate ISP via a cable modem and used the rules #shown below to cause a specific Windows machine on my internal network #(192.168.0.128) to send traffic out via DSL and get it back via cable. #This violates ingres filtering rules but seems to work. It was neat #since my cable modem had higher inbound bandwidth and it permitted #me to do downloads without impacting my DSL inbound bandwidth. #I no longer have that third interface, so no longer use this technique. # #iptables -A INPUT -i eth2 -s 68.65.209.39/32 -j DROP #iptables -A INPUT -i eth2 -s 127.0.0.0/8 -j DROP #iptables -t nat -A POSTROUTING -s 192.168.0.128/32 -d 0/0 -j SNAT --to-source 68.65.209.39 # # Finally, DENY all connection requests to any UDP port not yet provided # for and all SYN connection requests to any TCP port not yet provided # for. Using DENY instead of REJECT means that no 'ICMP port # unreachable' response is sent back to the client attempting to # connect. I.e., DENY just ignores connection attempts. Hence, use of # DENY causes UDP connection requests to time out and TCP connection # requests to hang. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # # Note that there is a fundamental difference between UDP and TCP # protocols. With UDP, there is no 'successful connection' response. # With TCP, there is. So an attacking client will be left in the dark # about whether or not the denied UDP packets arrived and will hang # waiting for a response from denied TCP ports. An attacker will not # be able to immediately tell if UDP connection requests are simply # taking a long time, if there is a problem with connectivity between # the attacking client and the server, or if the packets are being # ignored. This increases the amount of time it takes for an attacker # to scan all UDP ports. Similarly, TCP connection requests to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP port unreachable' response. iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP # end oceanpark.com firewall rules (using iptables) # -------------------------------------------------

ip tables # Red Hat Linux firewall using iptables # # Created: October 2002 # Last Revised: August 2006 # # Authors: Dennis G. Allard (allard@oceanpark.com) and Don Cohen (don@isis.cs3-inc.com) # # This script works on on servers running Red Hat 7.3, 8.0, 9.0, and # RHEL ES 3 and 4. Variants of this script are in active use on # many servers. # # No warranty is implied. Use at your own risk!! # Using this script # ----------------- # # I save this file as /etc/sysconfig/iptables-precursor # and then source it and run iptables-save to create # /etc/sysconfig/iptables, which is an input file # consumed by the script /etc/rc.d/init.d/iptables, # which in turn makes use of the script /sbin/iptables-restore. # # Before mucking with setting up iptables, you should # disconnect the machine from the internet. Examine # and understand the current set of iptables rules # before you reconnect to the internet. # # To configure the set of iptables rules: # # /etc/rc.d/init.d/iptables stop # source /etc/sysconfig/iptables-precursor # # To save the current set of iptables rules for use at next reboot: # # iptables-save > /etc/sysconfig/iptables # # To dynamically restart iptables after modifying /etc/sysconfig/iptables: # # /etc/rc.d/init.d/iptables restart # # Note that /etc/rc.d/init.d/iptables is a script. You can read it to # gain understanding of how iptables uses iptables-restore to restore # iptables firewall rules at reboot. # # To examine the current set of rules in effect: # # /etc/rc.d/init.d/iptables status # # However, I prefer to show the current set of rules via: # # iptables -nvL -t filter # iptables -nvL -t nat # # or # # iptables -vL -t filter # iptables -vL -t nat # # # To configure iptables to be used at next system reboot: # # chkconfig --add iptables # # To see if iptables is currently configured to start at boot, do: # # chkconfig --list iptables # # (You might have to do chkconfig --del ipchains to remove ipchains) # # The rest of this file is derived from my old ipchains script. # # A word about routing # -------------------- # # Note that this web page does not discuss routing decisions. Routing # (see the 'ifconfig' and 'route' commands) decides which interface an # incoming packet will be delivered to, i.e. if a given packet will be # 'input' to this machine or be 'forwarded' to some interface for # delivery to another machine, say on an internal network. You should # have your routing configured before you attempt to configure your # firewall. # # Caveat. DNAT and SNAT provide a way for the IPTABLES firewall to modify the # Destination or Source IP addresses of a packet and, in this way, interact # with routing decisions. See section below: 'More about NAT and routing'. # # The network # ----------- # # This firewall is running on a gateway machine having multiple ethernet # interfaces, a public one, eth0, which is a DSL connection to an ISP, # and one or more internal ones, including eth1, which is assigned to # 192.168.0.1, an IP number on my internal private network. My public # network has static IP numbers depicted below as x.y.z.... Actual # IP numbers would, of course, be a sequence of four octets. For this # script, I assume that the firewall is running on the same machine # having the interfaces configued with my public IPs. For this reason, # most of the rules below are INPUT rules. Were I to route some of my public # static IP numbers to interfaces on one or more machines inside the # firewall on the internal network, I would modify certain rules to be # FORWARD rules instead of INPUT rules. I show some examples below of # FORWARD rules. Finally, the script is just for a single server IP, # hence all of the "/32" network masks below. A more realistic situation # would involve using IP ranges and their corresponding network masks. # # The gateway at my ISP is x.y.z.1. I run a few web servers on # x.y.z.w, a DNS server on x.y.z.n, and qmail on x.y.z.m. # # Using this file in a more complex network would require some # modifications. Particular attention would need to be given to using # the right the IP numbers and interfaces, among other things. :-) # # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # ACCEPT all UDP packets for certain UDP services # # Currently the only UDP connections I accept are to my secure DNS # server, tinydns. For an explanation of why tinydns is secure, see: # http://www.faqts.com/knowledge_base/view.phtml/aid/8739/fid/699. # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # # SYN packets are specified via the -syn flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets that are part of existing connections # # DENY all other TCP packets. # # In other words, we allow any TCP packet through that is part of an # established TCP connection, but we are very selective in just which # connections we permit to be made to start off with. # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. This is done via 'Stateful Packet Inspection' provided by the # netfilter functionality added to linux as of kernel 2.4. By stopping all # other packets in their tracks, we limit attempts to attack our internal # network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html # # begin oceanpark.com firewall rules (using iptables) # --------------------------------------------------- # Here we go... # # Configure default policies (-P), meaning default rule to apply if no # more specific rule below is applicable. These rules apply if a more specific rule below # is not applicable. Defaults are to DROP anything sent to firewall or internal # network, permit anything going out. # iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # # Flush (-F) all specific rules # iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat # The rest of this file contains specific rules that are applied in the order # listed. If none applies, then the above policy rules are used. # # Forward all packets from eth1 (internal network) to eth0 (the internet). # iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT # # Forward packets that are part of existing and related connections from eth0 to eth1. # iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT # # Permit packets in to firewall itself that are part of existing and related connections. # iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # Note, in the above two rules, a connection becomes ESTABLISHED in the # iptables PREROUTING chain upon receipt of a SYNACK packet that is a # response to a previously sent SYN packet. The SYNACK packet itself is # considered to be part of the established connection, so no special # rule is needed to allow the SYNACK packet itself. # # Allow all inputs to firewall from the internal network and local interfaces # iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT # # Enable SNAT functionality on eth0 # # SNAT (Source NAT) is used to map private source IP numbers of # interfaces on the internal LAN to one of my public static IP numbers. # SNAT performs this mapping when a client running on one of the # internal hosts (x.y.z.c) initiates a TCP connection (SYN) through # eth0. # iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth0 -j SNAT --to-source x.y.z.c # # Alternative to SNAT -- MASQUERADE # # If your firewall has a dynamic IP number because it connects to the # internet itself via DHCP, then you probably cannot predict what the IP # number is of your firewall's interface connected to the internet. In # this case, you need a rule like the following that assigns the (an) IP # number associated with eth0 to outgoing connections without you needing # to know in advance (at time of writing this rule) what that IP number is: # # iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE # # Note that the above SNAT and MASQUERADE rules are applicable # independent of how a host on the internal network is assigned its own # internal IP number. The host could be assigned a static IP number on # an internal nonpublic network (e.g. 10. or 192.168.) or it could be # itself assigned a dynamic IP number from your own DHCP server running # on the firewall, or it could even have a public static IP number. # However, it seems unlikely that one would want to assign a public IP # number to a host and then proceed to hide that number from the public. # # # Deny any packet coming in on the public internet interface eth0 # which has a spoofed source address from our local networks: # iptables -A INPUT -i eth0 -s x.y.z.s/32 -j DROP iptables -A INPUT -i eth0 -s x.y.z.c/32 -j DROP iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP # # Accept all tcp SYN packets for protocols SMTP, HTTP, HTTPS, and SSH: # (SMTP connections are further audited by our SMTP server) # iptables -A INPUT -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 80 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 443 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # Notice that the above rules are all INPUT rules. My current network # does not require me to make use of FORWARD rules, since I run all # publicly accessible servers directly on my firewall machine. But I # promised above in the description of my network to give examples of # rules used when there are servers running on machines on the internal # network. Following are examples of FORWARD rules I would use if I ran # mail, web, and ssh servers on machines on the internal network inside # the firewall. # # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 80 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 443 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # # The first three of the above four rules would be used if my routing # delivered packets having destination IP x.y.z.m, port 25, or IP # x.y.z.w, port 80 or 443, to an interface connected to my internal # network (i.e. the packet was being FORWARDed). The fourth of the above # four rules is similar but operates on any destination IP, port 22. # # The difference between an INPUT rule and a FORWARD rule is that an # INPUT rule applies to packets that are 'input' to this machine (the # machine on which these iptables firewall rules are installed), whereas # a FORWARD rule applies to packets that are being 'fowarded', i.e. to # packets that are passing through this machine to some other machine, # such as a machine on my internal network. # # If I ran my mail server on an internal machine, I would no longer # need my previous INPUT rule for x.y.z.m and would use the above # FORWARD rule instead. # # # Begin Caveat, More about NAT and routing # # The above talk of routing is independent of the rules defined here. # I.e., routing is determined by ifconfig, route, et. al. I have not # yet seen any very good explanation of how to setup the static routing # table (what you see as output from the `route` command). I will not # attempt to remedy that lacuna at this time. If you know of some # good documenation that completely and accurately explains the # semantics of the ifconfig and route commands, i.e., explains what # affect each has such that I can reliably predict what the output # of `route` will be after executing a sequence of ifconfig and # route commands, then please do let me know. # # What *can* be done by IPTABLES rules that has the 'feel' of routing is # DNAT (Destintion NAT) and SNAT (Source NAT). DNAT and SNAT rules are, # respectively, mechnisms to map the incoming destination IP number and # outgoing source IP number to different IP numbers. For example, SNAT # can be used to map an internal source IP number to any one of your # external public IP numbers so that a workstation on your internal # network will appear to servers on the internet to which it connects to # have a source IP number equal to the mapped public IP number. # # DNAT goes the other way. It is a mechanism used typically to map # public destination IP numbers to internal private IP numbers. (In # fact, DNAT could also map public to public or private to private or # private to public, but that is left as an exercise for the reader). # So, for example, if you run a mail server on a machine configured with # an internal IP number but wish to expose that service to the external # world via a public IP number, DNAT is for you. # # Now, DNAT and SNAT are *not* routing but can *interact* with routing. # Routing decides whether a packet is going to be INPUT to this machine # or be FORWARDed to another machine. That decision is done by routing. # Once that decision is made, and only then, are the IPTABLES filtering # rules (FORWARD and INPUT rules) applied to a given packet. On the # other hand DNAT is applied by a PREROUTING rule and SNAT by a POSTROUTING # rule. It is now time for you to read the following Packet Filtering # HOWTO section: # # http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-9.html # # which states: # # It's common to want to do Network Address Translation (see the # NAT HOWTO) and packet filtering. The good news is that they mix # extremely well. [editor- The NAT HOWTO can be found at: # http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html] # # You design your packet filtering completely *ignoring* any NAT you # are doing. The sources and destinations seen by the packet filter # will be the `real' sources and destinations. For example, if you # are doing DNAT to send any connections to 1.2.3.4 port 80 through # to 10.1.1.1 port 8080, the packet filter would see packets going # to 10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80. # Similarly, you can ignore masquerading: packets will seem to come # from their real internal IP addresses (say 10.1.1.1), and replies # will seem to go back there. # # # Hence, INPUT/FORWARD rules would operate on destination IP numbers # *after* a DNAT rule is applied. But if you don't have any DNAT rules, # then INPUT/FORWARD would apply to the IP numbers as they are in the # incoming packet. # # INPUT or FORWARD would be needed purely depending on whether your # routing would cause the packet to stay on the machine where the # firewall is installed or be forwarded to another machine. THAT # decision is done by routing and *not* by DNAT or SNAT or anything # else in this firewall script. # # It is perfectly possible for the machine having the firewall to have # both public and internal IPs configured and/or for some packets to be # INPUT and others to be FORWARDed. # # DNAT is done by a PREROUTING rule, so you should think of things as # proceeding in the following order: # # 1. apply PREROUTING DNAT rules (if any) to map destination IP # 2. apply routing decisions (see ifconfig et. al.) # 3a. apply INPUT rules to packets having a destination IP on this machine # 3b. apply FORWARD rules to packets having a destination IP elsewhere # 4. apply POSTROUTING SNAT rules (if any) to map source IP # # (3a and 3b can be done in either order since they apply to a mutually # exclusive set of packets) # # I *think* that's correct. # # End Caveat, More about NAT and routing # # # Sometimes I run older versions of SSH on port 2200: # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 2200 --syn -j ACCEPT # # For imapd via stunnel (instead of xinetd-based imapd): # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 993 --syn -j ACCEPT # # For xinetd-based IMAP server (see /etc/xinetd.conf for who can use it): # #iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 143 --syn -j ACCEPT # # For DHCP server: # iptables -A INPUT -i eth1 -p tcp --sport 68 --dport 67 -j ACCEPT iptables -A INPUT -i eth1 -p udp --sport 68 --dport 67 -j ACCEPT # # For LDAP clients: # #iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 389 -syn -j ACCEPT #dga- worry about LDAP later (after I decode LDAP documentation (- # # DNS queries: # # Permit responses from our ISP's DNS server. When a client running on our # host makes a DNS query, the outgoing query is allowed since we permit all # outgoing packets. The reply will be a UDP connection back to the high # numbered client port from which the query was made. So we only need to # permit UDP packets from our ISP's DNS servers back to high numbered ports: # #iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT # # But since we trust our ISP DNS Server not not have been hacked and we may # not be sure what our client IP range is, we loosen this to: # iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 -j ACCEPT # # Running a caching DNS Server # # We need to permit querying a remote DNS server. Since I am running # a caching DNS server on x.y.z.d that makes requests for DNS lookups # to external DNS servers, those servers send back responses via UDP to # the high numbered client port on x.y.z.d where the caching server listens. # I could of course increase security by running the dns cache on its own # machine/IP and restricting to just that machine/IP. # iptables -A INPUT -p udp -s 0/0 --source-port 53 -d x.y.z.d/32 --destination-port 1024:65535 -j ACCEPT # # Running a DNS server (tinydns) # # When we run a DNS server, we have to accept UDP from anywhere to port 53 # iptables -A INPUT -p udp -s 0/0 -d 0/0 --destination-port 53 -j ACCEPT # # Running a Master DNS Server to update slave DNS servers # # You may have your server colocated at an ISP and may arrange to have your # ISP provide your primary and secondary DNS with the ISP DNS servers slaving # off of your master DNS server. This has the advantage of letting you be # in full control of the DNS zone files yet keeping the DNS servers exposed # to the public outside of your network. To achieve this, in addition to # permitting vanilla DNS responses from the ISP DNS serves, you also need # to allow TCP connections from the ISP Master DNS Server: # # Allow DNS zone transfers via TCP from ISP Master DNS server: # # iptables -A INPUT -p tcp -s <ISP Master DNS server IP>/32 -d 0/0 --destination-port 53 --syn -j ACCEPT # # For some other custom server running here listening on port <port number>: # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port <port number> --syn -j ACCEPT # # For FTP server, restricted to specific local hosts (and see /etc/xinetd.conf): # (for public file transfers we use scp, sftp, and related SSH file transfer tools) # iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 20 --syn -j ACCEPT iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 21 --syn -j ACCEPT iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 20 --syn -j ACCEPT iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 21 --syn -j ACCEPT # # For Samba (smbd and nmbd), restricted to specific local client hosts (x.y.z.c): # iptables -A INPUT -p tcp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 139 --syn -j ACCEPT iptables -A INPUT -p udp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 137 -j ACCEPT # #Special cable modem rules. I used to have a third ethernet card, #eth2, attached to a separate ISP via a cable modem and used the rules #shown below to cause a specific Windows machine on my internal network #(192.168.0.128) to send traffic out via DSL and get it back via cable. #This violates ingres filtering rules but seems to work. It was neat #since my cable modem had higher inbound bandwidth and it permitted #me to do downloads without impacting my DSL inbound bandwidth. #I no longer have that third interface, so no longer use this technique. # #iptables -A INPUT -i eth2 -s 68.65.209.39/32 -j DROP #iptables -A INPUT -i eth2 -s 127.0.0.0/8 -j DROP #iptables -t nat -A POSTROUTING -s 192.168.0.128/32 -d 0/0 -j SNAT --to-source 68.65.209.39 # # Finally, DENY all connection requests to any UDP port not yet provided # for and all SYN connection requests to any TCP port not yet provided # for. Using DENY instead of REJECT means that no 'ICMP port # unreachable' response is sent back to the client attempting to # connect. I.e., DENY just ignores connection attempts. Hence, use of # DENY causes UDP connection requests to time out and TCP connection # requests to hang. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # # Note that there is a fundamental difference between UDP and TCP # protocols. With UDP, there is no 'successful connection' response. # With TCP, there is. So an attacking client will be left in the dark # about whether or not the denied UDP packets arrived and will hang # waiting for a response from denied TCP ports. An attacker will not # be able to immediately tell if UDP connection requests are simply # taking a long time, if there is a problem with connectivity between # the attacking client and the server, or if the packets are being # ignored. This increases the amount of time it takes for an attacker # to scan all UDP ports. Similarly, TCP connection requests to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP port unreachable' response. iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP # end oceanpark.com firewall rules (using iptables) # -------------------------------------------------

ip chain # Red Hat 7.1 Linux firewall using ipchains # May, 2001 # configured by Dennis G. Allard and Don Cohen, http://oceanpark.com # # Permission to copy is granted provided that credit is given # to the author and whatever HOWTOs are used to understand this # stuff. # # No warrenty is implied. Use at your own risk!! # This web page documents my old ipchains firewall. I have # updated my firewall to use iptable and udpated the description # of my firewall at http://oceanpark.com/notes/firewall_example.html. # This file is /etc/sysconfig/ipchains, intended for # consumption by the script /etc/rc.d/init.d/ipchains, # which makes use of the script /sbin/ipchains-restore. # In Red Hat 7.1, the man page for ipchains and for # ipchains-restore does not document the syntax of this # file. I had to read the script to understand better # what is going on. # The firewall that the Red Hat 7.1 installer set up for me # in response to my request for a high level of security # was too restrictive. And, I couldn't find any GUI tool # in either GNOME or KDE to reconfigure the firewall. # For example, the KDE menu item for editing my firewall # showed an empty set of rules even though this file and # the above startup script existed. So I had no confidence # in the GUI firewall tools, resulting in my decision to edit # this file manually. # The network # ----------- # # This firewall was running on a gateway machine having two # ethernet interfaces, an external one, eth0, which is # my DSL connection to my ISP, and an internal one, eth1 # which is assigned to 198.211.65.1, an IP number on my # class C network. I run a web server, DNS server, and # sendmail on the firewall machine itself. # # Using this file in a more complex network would require # some modifications. Particular attention would need to # be given to using the right the IP numbers and interfaces, # among other things. :-) # Running this script # ------------------- # # Red Hat 7.1 runs /etc/rc.d/init.d/ipchains at system # startup, which uses this file as input. You can # turn ipchains on and off via chkconfig. See: # # chkconfig --list | grep ipchains # # You can restart the ipchains firewall via: # # /etc/rc.d/init.d/ipchains restart # # A good way to show your ipchains rules is with: # # ipchains -vnL # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # ACCEPT all UDP packets for certain UDP services # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # SYN packets are specified via the -y flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets (the default input chain policy.) # # In other words, we allow any TCP packet through that is part of an # established TCP connection, but we are very selective in just which # connections we permit to be made to start off with. IMPORTANT: # ipchains is less powerful than iptables since iptables, introduced # in linux kernel 2.4 provides for Stateful Packet Inspection. ipchains # will allow packets in that are not part of an existing TCP connection. # Although such packets will not normally be processed by an application, # they can be used as part of a denial of service attack. We recommend # that you use an iptables firewall, which is able to audit connections # more completely. See: # # IPTABLES Firewall Example # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. By stopping all other packets in their tracks, we limit # attempts to attack our internal network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html # # oceanpark.com firewall rules (using ipchains) # --------------------------------------------- # Tell ipchains-restore what default policies to use... :input ACCEPT :forward ACCEPT :output ACCEPT # The above will accept anything not prevented by the following rules. # Deny any packet coming in on the public internet interface eth0 # which has source address of our local network (attempt to spoof an # address which should never come from any place but eth1) or which # claims to be from the reserved local loop network 127.0.0.0. -A input -i eth0 -s 198.211.65.0/24 -j DENY -A input -i eth0 -s 127.0.0.0/8 -j DENY # Accept all tcp SYN packets for protocols SMTP, HTTP, and SSH # Note, SMTP connections are further audited by my SMTP server -A input -s 0/0 -d 198.211.65.1/32 25 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT # If you query remote DNS servers, permit UDP responses from it # -A input -s <remote DNS server IP> 53 -d 0/0 -p udp -j ACCEPT # I had to add the following line to make my DNS server honor requests # from the public internet. -A input -s 0/0 -d 0/0 53 -p udp -j ACCEPT # Open up IMAP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 143 -p tcp -y -j ACCEPT # Open up FTP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 20 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT # Allow all inputs from the internal and local interfaces -A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT -A input -s 0/0 -d 0/0 -i lo -j ACCEPT # If we wanted to use masqueading (can do even for legit internal IPs) # -A forward -s 198.211.65.78 -j MASQ # Finally, DENY all connection requests to any UDP port not yet provided # for and all SYN connection requests to any TCP port not yet provided # for. Using DENY instead of REJECT means that no 'ICMP port # unreachable' response is sent back to the client attempting to # connect. I.e., DENY just ignores connection attempts. Hence, use of # DENY causes UDP connection requests to time out and TCP connection # requests to hang. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # Note that there is a fundamental difference between UDP and TCP # protocols. With UDP, there is no 'successful connection' response. # With TCP, there is. So an attacking client will be left in the dark # about whether or not the denied UDP packets arrived and will hang # waiting for a response from denied TCP ports. An attacker will not # be able to immediately tell if UDP connection requests are simply # taking a long time, if there is a problem with connectivity between # the attacking client and the server, or if the packets are being # ignored. This increases the amount of time it takes for an attacker # to scan all UDP ports. Similarly, TCP connection requests to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP pot unreachable' response. -A input -s 0/0 -d 0/0 -p udp -j DENY -A input -s 0/0 -d 0/0 -p tcp -y -j DENY # end of firewall rules

ip chain # Red Hat 7.1 Linux firewall using ipchains # May, 2001 # configured by Dennis G. Allard and Don Cohen, http://oceanpark.com # # Permission to copy is granted provided that credit is given # to the author and whatever HOWTOs are used to understand this # stuff. # # No warrenty is implied. Use at your own risk!! # This web page documents my old ipchains firewall. I have # updated my firewall to use iptable and udpated the description # of my firewall at http://oceanpark.com/notes/firewall_example.html. # This file is /etc/sysconfig/ipchains, intended for # consumption by the script /etc/rc.d/init.d/ipchains, # which makes use of the script /sbin/ipchains-restore. # In Red Hat 7.1, the man page for ipchains and for # ipchains-restore does not document the syntax of this # file. I had to read the script to understand better # what is going on. # The firewall that the Red Hat 7.1 installer set up for me # in response to my request for a high level of security # was too restrictive. And, I couldn't find any GUI tool # in either GNOME or KDE to reconfigure the firewall. # For example, the KDE menu item for editing my firewall # showed an empty set of rules even though this file and # the above startup script existed. So I had no confidence # in the GUI firewall tools, resulting in my decision to edit # this file manually. # The network # ----------- # # This firewall was running on a gateway machine having two # ethernet interfaces, an external one, eth0, which is # my DSL connection to my ISP, and an internal one, eth1 # which is assigned to 198.211.65.1, an IP number on my # class C network. I run a web server, DNS server, and # sendmail on the firewall machine itself. # # Using this file in a more complex network would require # some modifications. Particular attention would need to # be given to using the right the IP numbers and interfaces, # among other things. :-) # Running this script # ------------------- # # Red Hat 7.1 runs /etc/rc.d/init.d/ipchains at system # startup, which uses this file as input. You can # turn ipchains on and off via chkconfig. See: # # chkconfig --list | grep ipchains # # You can restart the ipchains firewall via: # # /etc/rc.d/init.d/ipchains restart # # A good way to show your ipchains rules is with: # # ipchains -vnL # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # ACCEPT all UDP packets for certain UDP services # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # SYN packets are specified via the -y flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets (the default input chain policy.) # # In other words, we allow any TCP packet through that is part of an # established TCP connection, but we are very selective in just which # connections we permit to be made to start off with. IMPORTANT: # ipchains is less powerful than iptables since iptables, introduced # in linux kernel 2.4 provides for Stateful Packet Inspection. ipchains # will allow packets in that are not part of an existing TCP connection. # Although such packets will not normally be processed by an application, # they can be used as part of a denial of service attack. We recommend # that you use an iptables firewall, which is able to audit connections # more completely. See: # # IPTABLES Firewall Example # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. By stopping all other packets in their tracks, we limit # attempts to attack our internal network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html # # oceanpark.com firewall rules (using ipchains) # --------------------------------------------- # Tell ipchains-restore what default policies to use... :input ACCEPT :forward ACCEPT :output ACCEPT # The above will accept anything not prevented by the following rules. # Deny any packet coming in on the public internet interface eth0 # which has source address of our local network (attempt to spoof an # address which should never come from any place but eth1) or which # claims to be from the reserved local loop network 127.0.0.0. -A input -i eth0 -s 198.211.65.0/24 -j DENY -A input -i eth0 -s 127.0.0.0/8 -j DENY # Accept all tcp SYN packets for protocols SMTP, HTTP, and SSH # Note, SMTP connections are further audited by my SMTP server -A input -s 0/0 -d 198.211.65.1/32 25 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT # If you query remote DNS servers, permit UDP responses from it # -A input -s <remote DNS server IP> 53 -d 0/0 -p udp -j ACCEPT # I had to add the following line to make my DNS server honor requests # from the public internet. -A input -s 0/0 -d 0/0 53 -p udp -j ACCEPT # Open up IMAP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 143 -p tcp -y -j ACCEPT # Open up FTP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 20 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT # Allow all inputs from the internal and local interfaces -A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT -A input -s 0/0 -d 0/0 -i lo -j ACCEPT # If we wanted to use masqueading (can do even for legit internal IPs) # -A forward -s 198.211.65.78 -j MASQ # Finally, DENY all connection requests to any UDP port not yet provided # for and all SYN connection requests to any TCP port not yet provided # for. Using DENY instead of REJECT means that no 'ICMP port # unreachable' response is sent back to the client attempting to # connect. I.e., DENY just ignores connection attempts. Hence, use of # DENY causes UDP connection requests to time out and TCP connection # requests to hang. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # Note that there is a fundamental difference between UDP and TCP # protocols. With UDP, there is no 'successful connection' response. # With TCP, there is. So an attacking client will be left in the dark # about whether or not the denied UDP packets arrived and will hang # waiting for a response from denied TCP ports. An attacker will not # be able to immediately tell if UDP connection requests are simply # taking a long time, if there is a problem with connectivity between # the attacking client and the server, or if the packets are being # ignored. This increases the amount of time it takes for an attacker # to scan all UDP ports. Similarly, TCP connection requests to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP pot unreachable' response. -A input -s 0/0 -d 0/0 -p udp -j DENY -A input -s 0/0 -d 0/0 -p tcp -y -j DENY # end of firewall rules

ip tables # Red Hat Linux firewall using iptables # # Created: October 2002 # Last Revised: August 2006 # # Authors: Dennis G. Allard (allard@oceanpark.com) and Don Cohen (don@isis.cs3-inc.com) # # This script works on on servers running Red Hat 7.3, 8.0, 9.0, and # RHEL ES 3 and 4. Variants of this script are in active use on # many servers. # # No warranty is implied. Use at your own risk!! # Using this script # ----------------- # # I save this file as /etc/sysconfig/iptables-precursor # and then source it and run iptables-save to create # /etc/sysconfig/iptables, which is an input file # consumed by the script /etc/rc.d/init.d/iptables, # which in turn makes use of the script /sbin/iptables-restore. # # Before mucking with setting up iptables, you should # disconnect the machine from the internet. Examine # and understand the current set of iptables rules # before you reconnect to the internet. # # To configure the set of iptables rules: # # /etc/rc.d/init.d/iptables stop # source /etc/sysconfig/iptables-precursor # # To save the current set of iptables rules for use at next reboot: # # iptables-save > /etc/sysconfig/iptables # # To dynamically restart iptables after modifying /etc/sysconfig/iptables: # # /etc/rc.d/init.d/iptables restart # # Note that /etc/rc.d/init.d/iptables is a script. You can read it to # gain understanding of how iptables uses iptables-restore to restore # iptables firewall rules at reboot. # # To examine the current set of rules in effect: # # /etc/rc.d/init.d/iptables status # # However, I prefer to show the current set of rules via: # # iptables -nvL -t filter # iptables -nvL -t nat # # or # # iptables -vL -t filter # iptables -vL -t nat # # # To configure iptables to be used at next system reboot: # # chkconfig --add iptables # # To see if iptables is currently configured to start at boot, do: # # chkconfig --list iptables # # (You might have to do chkconfig --del ipchains to remove ipchains) # # The rest of this file is derived from my old ipchains script. # # A word about routing # -------------------- # # Note that this web page does not discuss routing decisions. Routing # (see the 'ifconfig' and 'route' commands) decides which interface an # incoming packet will be delivered to, i.e. if a given packet will be # 'input' to this machine or be 'forwarded' to some interface for # delivery to another machine, say on an internal network. You should # have your routing configured before you attempt to configure your # firewall. # # Caveat. DNAT and SNAT provide a way for the IPTABLES firewall to modify the # Destination or Source IP addresses of a packet and, in this way, interact # with routing decisions. See section below: 'More about NAT and routing'. # # The network # ----------- # # This firewall is running on a gateway machine having multiple ethernet # interfaces, a public one, eth0, which is a DSL connection to an ISP, # and one or more internal ones, including eth1, which is assigned to # 192.168.0.1, an IP number on my internal private network. My public # network has static IP numbers depicted below as x.y.z.... Actual # IP numbers would, of course, be a sequence of four octets. For this # script, I assume that the firewall is running on the same machine # having the interfaces configued with my public IPs. For this reason, # most of the rules below are INPUT rules. Were I to route some of my public # static IP numbers to interfaces on one or more machines inside the # firewall on the internal network, I would modify certain rules to be # FORWARD rules instead of INPUT rules. I show some examples below of # FORWARD rules. Finally, the script is just for a single server IP, # hence all of the "/32" network masks below. A more realistic situation # would involve using IP ranges and their corresponding network masks. # # The gateway at my ISP is x.y.z.1. I run a few web servers on # x.y.z.w, a DNS server on x.y.z.n, and qmail on x.y.z.m. # # Using this file in a more complex network would require some # modifications. Particular attention would need to be given to using # the right the IP numbers and interfaces, among other things. :-) # # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # ACCEPT all UDP packets for certain UDP services # # Currently the only UDP connections I accept are to my secure DNS # server, tinydns. For an explanation of why tinydns is secure, see: # http://www.faqts.com/knowledge_base/view.phtml/aid/8739/fid/699. # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # # SYN packets are specified via the -syn flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets that are part of existing connections # # DENY all other TCP packets. # # In other words, we allow any TCP packet through that is part of an # established TCP connection, but we are very selective in just which # connections we permit to be made to start off with. # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. This is done via 'Stateful Packet Inspection' provided by the # netfilter functionality added to linux as of kernel 2.4. By stopping all # other packets in their tracks, we limit attempts to attack our internal # network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html # # begin oceanpark.com firewall rules (using iptables) # --------------------------------------------------- # Here we go... # # Configure default policies (-P), meaning default rule to apply if no # more specific rule below is applicable. These rules apply if a more specific rule below # is not applicable. Defaults are to DROP anything sent to firewall or internal # network, permit anything going out. # iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # # Flush (-F) all specific rules # iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat # The rest of this file contains specific rules that are applied in the order # listed. If none applies, then the above policy rules are used. # # Forward all packets from eth1 (internal network) to eth0 (the internet). # iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT # # Forward packets that are part of existing and related connections from eth0 to eth1. # iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT # # Permit packets in to firewall itself that are part of existing and related connections. # iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # Note, in the above two rules, a connection becomes ESTABLISHED in the # iptables PREROUTING chain upon receipt of a SYNACK packet that is a # response to a previously sent SYN packet. The SYNACK packet itself is # considered to be part of the established connection, so no special # rule is needed to allow the SYNACK packet itself. # # Allow all inputs to firewall from the internal network and local interfaces # iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT # # Enable SNAT functionality on eth0 # # SNAT (Source NAT) is used to map private source IP numbers of # interfaces on the internal LAN to one of my public static IP numbers. # SNAT performs this mapping when a client running on one of the # internal hosts (x.y.z.c) initiates a TCP connection (SYN) through # eth0. # iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth0 -j SNAT --to-source x.y.z.c # # Alternative to SNAT -- MASQUERADE # # If your firewall has a dynamic IP number because it connects to the # internet itself via DHCP, then you probably cannot predict what the IP # number is of your firewall's interface connected to the internet. In # this case, you need a rule like the following that assigns the (an) IP # number associated with eth0 to outgoing connections without you needing # to know in advance (at time of writing this rule) what that IP number is: # # iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE # # Note that the above SNAT and MASQUERADE rules are applicable # independent of how a host on the internal network is assigned its own # internal IP number. The host could be assigned a static IP number on # an internal nonpublic network (e.g. 10. or 192.168.) or it could be # itself assigned a dynamic IP number from your own DHCP server running # on the firewall, or it could even have a public static IP number. # However, it seems unlikely that one would want to assign a public IP # number to a host and then proceed to hide that number from the public. # # # Deny any packet coming in on the public internet interface eth0 # which has a spoofed source address from our local networks: # iptables -A INPUT -i eth0 -s x.y.z.s/32 -j DROP iptables -A INPUT -i eth0 -s x.y.z.c/32 -j DROP iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP # # Accept all tcp SYN packets for protocols SMTP, HTTP, HTTPS, and SSH: # (SMTP connections are further audited by our SMTP server) # iptables -A INPUT -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 80 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 443 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # Notice that the above rules are all INPUT rules. My current network # does not require me to make use of FORWARD rules, since I run all # publicly accessible servers directly on my firewall machine. But I # promised above in the description of my network to give examples of # rules used when there are servers running on machines on the internal # network. Following are examples of FORWARD rules I would use if I ran # mail, web, and ssh servers on machines on the internal network inside # the firewall. # # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 80 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 443 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # # The first three of the above four rules would be used if my routing # delivered packets having destination IP x.y.z.m, port 25, or IP # x.y.z.w, port 80 or 443, to an interface connected to my internal # network (i.e. the packet was being FORWARDed). The fourth of the above # four rules is similar but operates on any destination IP, port 22. # # The difference between an INPUT rule and a FORWARD rule is that an # INPUT rule applies to packets that are 'input' to this machine (the # machine on which these iptables firewall rules are installed), whereas # a FORWARD rule applies to packets that are being 'fowarded', i.e. to # packets that are passing through this machine to some other machine, # such as a machine on my internal network. # # If I ran my mail server on an internal machine, I would no longer # need my previous INPUT rule for x.y.z.m and would use the above # FORWARD rule instead. # # # Begin Caveat, More about NAT and routing # # The above talk of routing is independent of the rules defined here. # I.e., routing is determined by ifconfig, route, et. al. I have not # yet seen any very good explanation of how to setup the static routing # table (what you see as output from the `route` command). I will not # attempt to remedy that lacuna at this time. If you know of some # good documenation that completely and accurately explains the # semantics of the ifconfig and route commands, i.e., explains what # affect each has such that I can reliably predict what the output # of `route` will be after executing a sequence of ifconfig and # route commands, then please do let me know. # # What *can* be done by IPTABLES rules that has the 'feel' of routing is # DNAT (Destintion NAT) and SNAT (Source NAT). DNAT and SNAT rules are, # respectively, mechnisms to map the incoming destination IP number and # outgoing source IP number to different IP numbers. For example, SNAT # can be used to map an internal source IP number to any one of your # external public IP numbers so that a workstation on your internal # network will appear to servers on the internet to which it connects to # have a source IP number equal to the mapped public IP number. # # DNAT goes the other way. It is a mechanism used typically to map # public destination IP numbers to internal private IP numbers. (In # fact, DNAT could also map public to public or private to private or # private to public, but that is left as an exercise for the reader). # So, for example, if you run a mail server on a machine configured with # an internal IP number but wish to expose that service to the external # world via a public IP number, DNAT is for you. # # Now, DNAT and SNAT are *not* routing but can *interact* with routing. # Routing decides whether a packet is going to be INPUT to this machine # or be FORWARDed to another machine. That decision is done by routing. # Once that decision is made, and only then, are the IPTABLES filtering # rules (FORWARD and INPUT rules) applied to a given packet. On the # other hand DNAT is applied by a PREROUTING rule and SNAT by a POSTROUTING # rule. It is now time for you to read the following Packet Filtering # HOWTO section: # # http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-9.html # # which states: # # It's common to want to do Network Address Translation (see the # NAT HOWTO) and packet filtering. The good news is that they mix # extremely well. [editor- The NAT HOWTO can be found at: # http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html] # # You design your packet filtering completely *ignoring* any NAT you # are doing. The sources and destinations seen by the packet filter # will be the `real' sources and destinations. For example, if you # are doing DNAT to send any connections to 1.2.3.4 port 80 through # to 10.1.1.1 port 8080, the packet filter would see packets going # to 10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80. # Similarly, you can ignore masquerading: packets will seem to come # from their real internal IP addresses (say 10.1.1.1), and replies # will seem to go back there. # # # Hence, INPUT/FORWARD rules would operate on destination IP numbers # *after* a DNAT rule is applied. But if you don't have any DNAT rules, # then INPUT/FORWARD would apply to the IP numbers as they are in the # incoming packet. # # INPUT or FORWARD would be needed purely depending on whether your # routing would cause the packet to stay on the machine where the # firewall is installed or be forwarded to another machine. THAT # decision is done by routing and *not* by DNAT or SNAT or anything # else in this firewall script. # # It is perfectly possible for the machine having the firewall to have # both public and internal IPs configured and/or for some packets to be # INPUT and others to be FORWARDed. # # DNAT is done by a PREROUTING rule, so you should think of things as # proceeding in the following order: # # 1. apply PREROUTING DNAT rules (if any) to map destination IP # 2. apply routing decisions (see ifconfig et. al.) # 3a. apply INPUT rules to packets having a destination IP on this machine # 3b. apply FORWARD rules to packets having a destination IP elsewhere # 4. apply POSTROUTING SNAT rules (if any) to map source IP # # (3a and 3b can be done in either order since they apply to a mutually # exclusive set of packets) # # I *think* that's correct. # # End Caveat, More about NAT and routing # # # Sometimes I run older versions of SSH on port 2200: # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 2200 --syn -j ACCEPT # # For imapd via stunnel (instead of xinetd-based imapd): # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 993 --syn -j ACCEPT # # For xinetd-based IMAP server (see /etc/xinetd.conf for who can use it): # #iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 143 --syn -j ACCEPT # # For DHCP server: # iptables -A INPUT -i eth1 -p tcp --sport 68 --dport 67 -j ACCEPT iptables -A INPUT -i eth1 -p udp --sport 68 --dport 67 -j ACCEPT # # For LDAP clients: # #iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 389 -syn -j ACCEPT #dga- worry about LDAP later (after I decode LDAP documentation (- # # DNS queries: # # Permit responses from our ISP's DNS server. When a client running on our # host makes a DNS query, the outgoing query is allowed since we permit all # outgoing packets. The reply will be a UDP connection back to the high # numbered client port from which the query was made. So we only need to # permit UDP packets from our ISP's DNS servers back to high numbered ports: # #iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT # # But since we trust our ISP DNS Server not not have been hacked and we may # not be sure what our client IP range is, we loosen this to: # iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 -j ACCEPT # # Running a caching DNS Server # # We need to permit querying a remote DNS server. Since I am running # a caching DNS server on x.y.z.d that makes requests for DNS lookups # to external DNS servers, those servers send back responses via UDP to # the high numbered client port on x.y.z.d where the caching server listens. # I could of course increase security by running the dns cache on its own # machine/IP and restricting to just that machine/IP. # iptables -A INPUT -p udp -s 0/0 --source-port 53 -d x.y.z.d/32 --destination-port 1024:65535 -j ACCEPT # # Running a DNS server (tinydns) # # When we run a DNS server, we have to accept UDP from anywhere to port 53 # iptables -A INPUT -p udp -s 0/0 -d 0/0 --destination-port 53 -j ACCEPT # # Running a Master DNS Server to update slave DNS servers # # You may have your server colocated at an ISP and may arrange to have your # ISP provide your primary and secondary DNS with the ISP DNS servers slaving # off of your master DNS server. This has the advantage of letting you be # in full control of the DNS zone files yet keeping the DNS servers exposed # to the public outside of your network. To achieve this, in addition to # permitting vanilla DNS responses from the ISP DNS serves, you also need # to allow TCP connections from the ISP Master DNS Server: # # Allow DNS zone transfers via TCP from ISP Master DNS server: # # iptables -A INPUT -p tcp -s <ISP Master DNS server IP>/32 -d 0/0 --destination-port 53 --syn -j ACCEPT # # For some other custom server running here listening on port <port number>: # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port <port number> --syn -j ACCEPT # # For FTP server, restricted to specific local hosts (and see /etc/xinetd.conf): # (for public file transfers we use scp, sftp, and related SSH file transfer tools) # iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 20 --syn -j ACCEPT iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 21 --syn -j ACCEPT iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 20 --syn -j ACCEPT iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 21 --syn -j ACCEPT # # For Samba (smbd and nmbd), restricted to specific local client hosts (x.y.z.c): # iptables -A INPUT -p tcp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 139 --syn -j ACCEPT iptables -A INPUT -p udp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 137 -j ACCEPT # #Special cable modem rules. I used to have a third ethernet card, #eth2, attached to a separate ISP via a cable modem and used the rules #shown below to cause a specific Windows machine on my internal network #(192.168.0.128) to send traffic out via DSL and get it back via cable. #This violates ingres filtering rules but seems to work. It was neat #since my cable modem had higher inbound bandwidth and it permitted #me to do downloads without impacting my DSL inbound bandwidth. #I no longer have that third interface, so no longer use this technique. # #iptables -A INPUT -i eth2 -s 68.65.209.39/32 -j DROP #iptables -A INPUT -i eth2 -s 127.0.0.0/8 -j DROP #iptables -t nat -A POSTROUTING -s 192.168.0.128/32 -d 0/0 -j SNAT --to-source 68.65.209.39 # # Finally, DENY all connection requests to any UDP port not yet provided # for and all SYN connection requests to any TCP port not yet provided # for. Using DENY instead of REJECT means that no 'ICMP port # unreachable' response is sent back to the client attempting to # connect. I.e., DENY just ignores connection attempts. Hence, use of # DENY causes UDP connection requests to time out and TCP connection # requests to hang. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # # Note that there is a fundamental difference between UDP and TCP # protocols. With UDP, there is no 'successful connection' response. # With TCP, there is. So an attacking client will be left in the dark # about whether or not the denied UDP packets arrived and will hang # waiting for a response from denied TCP ports. An attacker will not # be able to immediately tell if UDP connection requests are simply # taking a long time, if there is a problem with connectivity between # the attacking client and the server, or if the packets are being # ignored. This increases the amount of time it takes for an attacker # to scan all UDP ports. Similarly, TCP connection requests to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP port unreachable' response. iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP # end oceanpark.com firewall rules (using iptables) # -------------------------------------------------

An A-Z Index of the Linux BASH command line alias Create an alias apropos Search Help manual pages (man -k) awk Find and Replace text, database sort/validate/index break Exit from a loop builtin Run a shell builtin bzip2 Compress or decompress named file(s) cal Display a calendar case Conditionally perform a command cat Display the contents of a file cd Change Directory cfdisk Partition table manipulator for Linux chgrp Change group ownership chmod Change access permissions chown Change file owner and group chroot Run a command with a different root directory cksum Print CRC checksum and byte counts clear Clear terminal screen cmp Compare two files comm Compare two sorted files line by line command Run a command - ignoring shell functions continue Resume the next iteration of a loop cp Copy one or more files to another location cron Daemon to execute scheduled commands crontab Schedule a command to run at a later time csplit Split a file into context-determined pieces cut Divide a file into several parts date Display or change the date & time dc Desk Calculator dd Data Dump - Convert and copy a file ddrescue Data recovery tool declare Declare variables and give them attributes df Display free disk space diff Display the differences between two files diff3 Show differences among three files dig DNS lookup dir Briefly list directory contents dircolors Colour setup for `ls' dirname Convert a full pathname to just a path dirs Display list of remembered directories du Estimate file space usage echo Display message on screen egrep Search file(s) for lines that match an extended expression eject Eject removable media enable Enable and disable builtin shell commands env Environment variables ethtool Ethernet card settings eval Evaluate several commands/arguments exec Execute a command exit Exit the shell expand Convert tabs to spaces export Set an environment variable expr Evaluate expressions false Do nothing, unsuccessfully fdformat Low-level format a floppy disk fdisk Partition table manipulator for Linux fgrep Search file(s) for lines that match a fixed string file Determine file type find Search for files that meet a desired criteria fmt Reformat paragraph text fold Wrap text to fit a specified width. for Expand words, and execute commands format Format disks or tapes free Display memory usage fsck File system consistency check and repair ftp File Transfer Protocol function Define Function Macros gawk Find and Replace text within file(s) getopts Parse positional parameters grep Search file(s) for lines that match a given pattern groups Print group names a user is in gzip Compress or decompress named file(s) hash Remember the full pathname of a name argument head Output the first part of file(s) history Command History hostname Print or set system name id Print user and group id's if Conditionally perform a command ifconfig Configure a network interface import Capture an X server screen and save the image to file install Copy files and set attributes join Join lines on a common field kill Stop a process from running less Display output one screen at a time let Perform arithmetic on shell variables ln Make links between files local Create variables locate Find files logname Print current login name logout Exit a login shell look Display lines beginning with a given string lpc Line printer control program lpr Off line print lprint Print a file lprintd Abort a print job lprintq List the print queue lprm Remove jobs from the print queue ls List information about file(s) lsof List open files make Recompile a group of programs man Help manual mkdir Create new folder(s) mkfifo Make FIFOs (named pipes) mkisofs Create an hybrid ISO9660/JOLIET/HFS filesystem mknod Make block or character special files more Display output one screen at a time mount Mount a file system mtools Manipulate MS-DOS files mv Move or rename files or directories netstat Networking information nice Set the priority of a command or job nl Number lines and write files nohup Run a command immune to hangups nslookup Query Internet name servers interactively passwd Modify a user password paste Merge lines of files pathchk Check file name portability ping Test a network connection popd Restore the previous value of the current directory pr Prepare files for printing printcap Printer capability database printenv Print environment variables printf Format and print data ps Process status pushd Save and then change the current directory pwd Print Working Directory quota Display disk usage and limits quotacheck Scan a file system for disk usage quotactl Set disk quotas ram ram disk device rcp Copy files between two machines. read read a line from standard input readonly Mark variables/functions as readonly remsync Synchronize remote files via email return Exit a shell function rm Remove files rmdir Remove folder(s) rsync Remote file copy (Synchronize file trees) screen Terminal window manager scp Secure copy (remote file copy) sdiff Merge two files interactively sed Stream Editor select Accept keyboard input seq Print numeric sequences set Manipulate shell variables and functions sftp Secure File Transfer Program shift Shift positional parameters shopt Shell Options shutdown Shutdown or restart linux sleep Delay for a specified time sort Sort text files source Run commands from a file `.' split Split a file into fixed-size pieces ssh Secure Shell client (remote login program) strace Trace system calls and signals su Substitute user identity sum Print a checksum for a file symlink Make a new name for a file sync Synchronize data on disk with memory tail Output the last part of files tar Tape ARchiver tee Redirect output to multiple files test Evaluate a conditional expression time Measure Program running time times User and system times touch Change file timestamps top List processes running on the system traceroute Trace Route to Host trap Run a command when a signal is set(bourne) tr Translate, squeeze, and/or delete characters true Do nothing, successfully tsort Topological sort tty Print filename of terminal on stdin type Describe a command ulimit Limit user resources umask Users file creation mask umount Unmount a device unalias Remove an alias uname Print system information unexpand Convert spaces to tabs uniq Uniquify files units Convert units from one scale to another unset Remove variable or function names unshar Unpack shell archive scripts until Execute commands (until error) useradd Create new user account usermod Modify user account users List users currently logged in uuencode Encode a binary file uudecode Decode a file created by uuencode v Verbosely list directory contents (`ls -l -b') vdir Verbosely list directory contents (`ls -l -b') vi Text Editor watch Execute/display a program periodically wc Print byte, word, and line counts whereis Report all known instances of a command which Locate a program file in the user's path. while Execute commands who Print all usernames currently logged in whoami Print the current user id and name (`id -un') Wget Retrieve web pages or files via HTTP, HTTPS or FTP xargs Execute utility, passing constructed argument list(s) yes Print a string until interrupted .period Run commands from a file ### Comment / Remark SS64 Discussion forum Links to other Sites, full list of man pages, books etc... ________________________________________ Simon Sheppard SS64.com

ip tables # Red Hat Linux firewall using iptables # # Created: October 2002 # Last Revised: August 2006 # # Authors: Dennis G. Allard (allard@oceanpark.com) and Don Cohen (don@isis.cs3-inc.com) # # This script works on on servers running Red Hat 7.3, 8.0, 9.0, and # RHEL ES 3 and 4. Variants of this script are in active use on # many servers. # # No warranty is implied. Use at your own risk!! # Using this script # ----------------- # # I save this file as /etc/sysconfig/iptables-precursor # and then source it and run iptables-save to create # /etc/sysconfig/iptables, which is an input file # consumed by the script /etc/rc.d/init.d/iptables, # which in turn makes use of the script /sbin/iptables-restore. # # Before mucking with setting up iptables, you should # disconnect the machine from the internet. Examine # and understand the current set of iptables rules # before you reconnect to the internet. # # To configure the set of iptables rules: # # /etc/rc.d/init.d/iptables stop # source /etc/sysconfig/iptables-precursor # # To save the current set of iptables rules for use at next reboot: # # iptables-save > /etc/sysconfig/iptables # # To dynamically restart iptables after modifying /etc/sysconfig/iptables: # # /etc/rc.d/init.d/iptables restart # # Note that /etc/rc.d/init.d/iptables is a script. You can read it to # gain understanding of how iptables uses iptables-restore to restore # iptables firewall rules at reboot. # # To examine the current set of rules in effect: # # /etc/rc.d/init.d/iptables status # # However, I prefer to show the current set of rules via: # # iptables -nvL -t filter # iptables -nvL -t nat # # or # # iptables -vL -t filter # iptables -vL -t nat # # # To configure iptables to be used at next system reboot: # # chkconfig --add iptables # # To see if iptables is currently configured to start at boot, do: # # chkconfig --list iptables # # (You might have to do chkconfig --del ipchains to remove ipchains) # # The rest of this file is derived from my old ipchains script. # # A word about routing # -------------------- # # Note that this web page does not discuss routing decisions. Routing # (see the 'ifconfig' and 'route' commands) decides which interface an # incoming packet will be delivered to, i.e. if a given packet will be # 'input' to this machine or be 'forwarded' to some interface for # delivery to another machine, say on an internal network. You should # have your routing configured before you attempt to configure your # firewall. # # Caveat. DNAT and SNAT provide a way for the IPTABLES firewall to modify the # Destination or Source IP addresses of a packet and, in this way, interact # with routing decisions. See section below: 'More about NAT and routing'. # # The network # ----------- # # This firewall is running on a gateway machine having multiple ethernet # interfaces, a public one, eth0, which is a DSL connection to an ISP, # and one or more internal ones, including eth1, which is assigned to # 192.168.0.1, an IP number on my internal private network. My public # network has static IP numbers depicted below as x.y.z.... Actual # IP numbers would, of course, be a sequence of four octets. For this # script, I assume that the firewall is running on the same machine # having the interfaces configued with my public IPs. For this reason, # most of the rules below are INPUT rules. Were I to route some of my public # static IP numbers to interfaces on one or more machines inside the # firewall on the internal network, I would modify certain rules to be # FORWARD rules instead of INPUT rules. I show some examples below of # FORWARD rules. Finally, the script is just for a single server IP, # hence all of the "/32" network masks below. A more realistic situation # would involve using IP ranges and their corresponding network masks. # # The gateway at my ISP is x.y.z.1. I run a few web servers on # x.y.z.w, a DNS server on x.y.z.n, and qmail on x.y.z.m. # # Using this file in a more complex network would require some # modifications. Particular attention would need to be given to using # the right the IP numbers and interfaces, among other things. :-) # # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # ACCEPT all UDP packets for certain UDP services # # Currently the only UDP connections I accept are to my secure DNS # server, tinydns. For an explanation of why tinydns is secure, see: # http://www.faqts.com/knowledge_base/view.phtml/aid/8739/fid/699. # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # # SYN packets are specified via the -syn flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets that are part of existing connections # # DENY all other TCP packets. # # In other words, we allow any TCP packet through that is part of an # established TCP connection, but we are very selective in just which # connections we permit to be made to start off with. # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. This is done via 'Stateful Packet Inspection' provided by the # netfilter functionality added to linux as of kernel 2.4. By stopping all # other packets in their tracks, we limit attempts to attack our internal # network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html # # begin oceanpark.com firewall rules (using iptables) # --------------------------------------------------- # Here we go... # # Configure default policies (-P), meaning default rule to apply if no # more specific rule below is applicable. These rules apply if a more specific rule below # is not applicable. Defaults are to DROP anything sent to firewall or internal # network, permit anything going out. # iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # # Flush (-F) all specific rules # iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat # The rest of this file contains specific rules that are applied in the order # listed. If none applies, then the above policy rules are used. # # Forward all packets from eth1 (internal network) to eth0 (the internet). # iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT # # Forward packets that are part of existing and related connections from eth0 to eth1. # iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT # # Permit packets in to firewall itself that are part of existing and related connections. # iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # Note, in the above two rules, a connection becomes ESTABLISHED in the # iptables PREROUTING chain upon receipt of a SYNACK packet that is a # response to a previously sent SYN packet. The SYNACK packet itself is # considered to be part of the established connection, so no special # rule is needed to allow the SYNACK packet itself. # # Allow all inputs to firewall from the internal network and local interfaces # iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT # # Enable SNAT functionality on eth0 # # SNAT (Source NAT) is used to map private source IP numbers of # interfaces on the internal LAN to one of my public static IP numbers. # SNAT performs this mapping when a client running on one of the # internal hosts (x.y.z.c) initiates a TCP connection (SYN) through # eth0. # iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth0 -j SNAT --to-source x.y.z.c # # Alternative to SNAT -- MASQUERADE # # If your firewall has a dynamic IP number because it connects to the # internet itself via DHCP, then you probably cannot predict what the IP # number is of your firewall's interface connected to the internet. In # this case, you need a rule like the following that assigns the (an) IP # number associated with eth0 to outgoing connections without you needing # to know in advance (at time of writing this rule) what that IP number is: # # iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE # # Note that the above SNAT and MASQUERADE rules are applicable # independent of how a host on the internal network is assigned its own # internal IP number. The host could be assigned a static IP number on # an internal nonpublic network (e.g. 10. or 192.168.) or it could be # itself assigned a dynamic IP number from your own DHCP server running # on the firewall, or it could even have a public static IP number. # However, it seems unlikely that one would want to assign a public IP # number to a host and then proceed to hide that number from the public. # # # Deny any packet coming in on the public internet interface eth0 # which has a spoofed source address from our local networks: # iptables -A INPUT -i eth0 -s x.y.z.s/32 -j DROP iptables -A INPUT -i eth0 -s x.y.z.c/32 -j DROP iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP # # Accept all tcp SYN packets for protocols SMTP, HTTP, HTTPS, and SSH: # (SMTP connections are further audited by our SMTP server) # iptables -A INPUT -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 80 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 443 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # Notice that the above rules are all INPUT rules. My current network # does not require me to make use of FORWARD rules, since I run all # publicly accessible servers directly on my firewall machine. But I # promised above in the description of my network to give examples of # rules used when there are servers running on machines on the internal # network. Following are examples of FORWARD rules I would use if I ran # mail, web, and ssh servers on machines on the internal network inside # the firewall. # # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 80 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 443 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # # The first three of the above four rules would be used if my routing # delivered packets having destination IP x.y.z.m, port 25, or IP # x.y.z.w, port 80 or 443, to an interface connected to my internal # network (i.e. the packet was being FORWARDed). The fourth of the above # four rules is similar but operates on any destination IP, port 22. # # The difference between an INPUT rule and a FORWARD rule is that an # INPUT rule applies to packets that are 'input' to this machine (the # machine on which these iptables firewall rules are installed), whereas # a FORWARD rule applies to packets that are being 'fowarded', i.e. to # packets that are passing through this machine to some other machine, # such as a machine on my internal network. # # If I ran my mail server on an internal machine, I would no longer # need my previous INPUT rule for x.y.z.m and would use the above # FORWARD rule instead. # # # Begin Caveat, More about NAT and routing # # The above talk of routing is independent of the rules defined here. # I.e., routing is determined by ifconfig, route, et. al. I have not # yet seen any very good explanation of how to setup the static routing # table (what you see as output from the `route` command). I will not # attempt to remedy that lacuna at this time. If you know of some # good documenation that completely and accurately explains the # semantics of the ifconfig and route commands, i.e., explains what # affect each has such that I can reliably predict what the output # of `route` will be after executing a sequence of ifconfig and # route commands, then please do let me know. # # What *can* be done by IPTABLES rules that has the 'feel' of routing is # DNAT (Destintion NAT) and SNAT (Source NAT). DNAT and SNAT rules are, # respectively, mechnisms to map the incoming destination IP number and # outgoing source IP number to different IP numbers. For example, SNAT # can be used to map an internal source IP number to any one of your # external public IP numbers so that a workstation on your internal # network will appear to servers on the internet to which it connects to # have a source IP number equal to the mapped public IP number. # # DNAT goes the other way. It is a mechanism used typically to map # public destination IP numbers to internal private IP numbers. (In # fact, DNAT could also map public to public or private to private or # private to public, but that is left as an exercise for the reader). # So, for example, if you run a mail server on a machine configured with # an internal IP number but wish to expose that service to the external # world via a public IP number, DNAT is for you. # # Now, DNAT and SNAT are *not* routing but can *interact* with routing. # Routing decides whether a packet is going to be INPUT to this machine # or be FORWARDed to another machine. That decision is done by routing. # Once that decision is made, and only then, are the IPTABLES filtering # rules (FORWARD and INPUT rules) applied to a given packet. On the # other hand DNAT is applied by a PREROUTING rule and SNAT by a POSTROUTING # rule. It is now time for you to read the following Packet Filtering # HOWTO section: # # http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-9.html # # which states: # # It's common to want to do Network Address Translation (see the # NAT HOWTO) and packet filtering. The good news is that they mix # extremely well. [editor- The NAT HOWTO can be found at: # http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html] # # You design your packet filtering completely *ignoring* any NAT you # are doing. The sources and destinations seen by the packet filter # will be the `real' sources and destinations. For example, if you # are doing DNAT to send any connections to 1.2.3.4 port 80 through # to 10.1.1.1 port 8080, the packet filter would see packets going # to 10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80. # Similarly, you can ignore masquerading: packets will seem to come # from their real internal IP addresses (say 10.1.1.1), and replies # will seem to go back there. # # # Hence, INPUT/FORWARD rules would operate on destination IP numbers # *after* a DNAT rule is applied. But if you don't have any DNAT rules, # then INPUT/FORWARD would apply to the IP numbers as they are in the # incoming packet. # # INPUT or FORWARD would be needed purely depending on whether your # routing would cause the packet to stay on the machine where the # firewall is installed or be forwarded to another machine. THAT # decision is done by routing and *not* by DNAT or SNAT or anything # else in this firewall script. # # It is perfectly possible for the machine having the firewall to have # both public and internal IPs configured and/or for some packets to be # INPUT and others to be FORWARDed. # # DNAT is done by a PREROUTING rule, so you should think of things as # proceeding in the following order: # # 1. apply PREROUTING DNAT rules (if any) to map destination IP # 2. apply routing decisions (see ifconfig et. al.) # 3a. apply INPUT rules to packets having a destination IP on this machine # 3b. apply FORWARD rules to packets having a destination IP elsewhere # 4. apply POSTROUTING SNAT rules (if any) to map source IP # # (3a and 3b can be done in either order since they apply to a mutually # exclusive set of packets) # # I *think* that's correct. # # End Caveat, More about NAT and routing # # # Sometimes I run older versions of SSH on port 2200: # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 2200 --syn -j ACCEPT # # For imapd via stunnel (instead of xinetd-based imapd): # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 993 --syn -j ACCEPT # # For xinetd-based IMAP server (see /etc/xinetd.conf for who can use it): # #iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 143 --syn -j ACCEPT # # For DHCP server: # iptables -A INPUT -i eth1 -p tcp --sport 68 --dport 67 -j ACCEPT iptables -A INPUT -i eth1 -p udp --sport 68 --dport 67 -j ACCEPT # # For LDAP clients: # #iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 389 -syn -j ACCEPT #dga- worry about LDAP later (after I decode LDAP documentation (- # # DNS queries: # # Permit responses from our ISP's DNS server. When a client running on our # host makes a DNS query, the outgoing query is allowed since we permit all # outgoing packets. The reply will be a UDP connection back to the high # numbered client port from which the query was made. So we only need to # permit UDP packets from our ISP's DNS servers back to high numbered ports: # #iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT # # But since we trust our ISP DNS Server not not have been hacked and we may # not be sure what our client IP range is, we loosen this to: # iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 -j ACCEPT # # Running a caching DNS Server # # We need to permit querying a remote DNS server. Since I am running # a caching DNS server on x.y.z.d that makes requests for DNS lookups # to external DNS servers, those servers send back responses via UDP to # the high numbered client port on x.y.z.d where the caching server listens. # I could of course increase security by running the dns cache on its own # machine/IP and restricting to just that machine/IP. # iptables -A INPUT -p udp -s 0/0 --source-port 53 -d x.y.z.d/32 --destination-port 1024:65535 -j ACCEPT # # Running a DNS server (tinydns) # # When we run a DNS server, we have to accept UDP from anywhere to port 53 # iptables -A INPUT -p udp -s 0/0 -d 0/0 --destination-port 53 -j ACCEPT # # Running a Master DNS Server to update slave DNS servers # # You may have your server colocated at an ISP and may arrange to have your # ISP provide your primary and secondary DNS with the ISP DNS servers slaving # off of your master DNS server. This has the advantage of letting you be # in full control of the DNS zone files yet keeping the DNS servers exposed # to the public outside of your network. To achieve this, in addition to # permitting vanilla DNS responses from the ISP DNS serves, you also need # to allow TCP connections from the ISP Master DNS Server: # # Allow DNS zone transfers via TCP from ISP Master DNS server: # # iptables -A INPUT -p tcp -s <ISP Master DNS server IP>/32 -d 0/0 --destination-port 53 --syn -j ACCEPT # # For some other custom server running here listening on port <port number>: # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port <port number> --syn -j ACCEPT # # For FTP server, restricted to specific local hosts (and see /etc/xinetd.conf): # (for public file transfers we use scp, sftp, and related SSH file transfer tools) # iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 20 --syn -j ACCEPT iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 21 --syn -j ACCEPT iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 20 --syn -j ACCEPT iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 21 --syn -j ACCEPT # # For Samba (smbd and nmbd), restricted to specific local client hosts (x.y.z.c): # iptables -A INPUT -p tcp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 139 --syn -j ACCEPT iptables -A INPUT -p udp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 137 -j ACCEPT # #Special cable modem rules. I used to have a third ethernet card, #eth2, attached to a separate ISP via a cable modem and used the rules #shown below to cause a specific Windows machine on my internal network #(192.168.0.128) to send traffic out via DSL and get it back via cable. #This violates ingres filtering rules but seems to work. It was neat #since my cable modem had higher inbound bandwidth and it permitted #me to do downloads without impacting my DSL inbound bandwidth. #I no longer have that third interface, so no longer use this technique. # #iptables -A INPUT -i eth2 -s 68.65.209.39/32 -j DROP #iptables -A INPUT -i eth2 -s 127.0.0.0/8 -j DROP #iptables -t nat -A POSTROUTING -s 192.168.0.128/32 -d 0/0 -j SNAT --to-source 68.65.209.39 # # Finally, DENY all connection requests to any UDP port not yet provided # for and all SYN connection requests to any TCP port not yet provided # for. Using DENY instead of REJECT means that no 'ICMP port # unreachable' response is sent back to the client attempting to # connect. I.e., DENY just ignores connection attempts. Hence, use of # DENY causes UDP connection requests to time out and TCP connection # requests to hang. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # # Note that there is a fundamental difference between UDP and TCP # protocols. With UDP, there is no 'successful connection' response. # With TCP, there is. So an attacking client will be left in the dark # about whether or not the denied UDP packets arrived and will hang # waiting for a response from denied TCP ports. An attacker will not # be able to immediately tell if UDP connection requests are simply # taking a long time, if there is a problem with connectivity between # the attacking client and the server, or if the packets are being # ignored. This increases the amount of time it takes for an attacker # to scan all UDP ports. Similarly, TCP connection requests to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP port unreachable' response. iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP # end oceanpark.com firewall rules (using iptables) # -------------------------------------------------

ip chain # Red Hat 7.1 Linux firewall using ipchains # May, 2001 # configured by Dennis G. Allard and Don Cohen, http://oceanpark.com # # Permission to copy is granted provided that credit is given # to the author and whatever HOWTOs are used to understand this # stuff. # # No warrenty is implied. Use at your own risk!! # This web page documents my old ipchains firewall. I have # updated my firewall to use iptable and udpated the description # of my firewall at http://oceanpark.com/notes/firewall_example.html. # This file is /etc/sysconfig/ipchains, intended for # consumption by the script /etc/rc.d/init.d/ipchains, # which makes use of the script /sbin/ipchains-restore. # In Red Hat 7.1, the man page for ipchains and for # ipchains-restore does not document the syntax of this # file. I had to read the script to understand better # what is going on. # The firewall that the Red Hat 7.1 installer set up for me # in response to my request for a high level of security # was too restrictive. And, I couldn't find any GUI tool # in either GNOME or KDE to reconfigure the firewall. # For example, the KDE menu item for editing my firewall # showed an empty set of rules even though this file and # the above startup script existed. So I had no confidence # in the GUI firewall tools, resulting in my decision to edit # this file manually. # The network # ----------- # # This firewall was running on a gateway machine having two # ethernet interfaces, an external one, eth0, which is # my DSL connection to my ISP, and an internal one, eth1 # which is assigned to 198.211.65.1, an IP number on my # class C network. I run a web server, DNS server, and # sendmail on the firewall machine itself. # # Using this file in a more complex network would require # some modifications. Particular attention would need to # be given to using the right the IP numbers and interfaces, # among other things. :-) # Running this script # ------------------- # # Red Hat 7.1 runs /etc/rc.d/init.d/ipchains at system # startup, which uses this file as input. You can # turn ipchains on and off via chkconfig. See: # # chkconfig --list | grep ipchains # # You can restart the ipchains firewall via: # # /etc/rc.d/init.d/ipchains restart # # A good way to show your ipchains rules is with: # # ipchains -vnL # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # ACCEPT all UDP packets for certain UDP services # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # SYN packets are specified via the -y flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets (the default input chain policy.) # # In other words, we allow any TCP packet through that is part of an # established TCP connection, but we are very selective in just which # connections we permit to be made to start off with. IMPORTANT: # ipchains is less powerful than iptables since iptables, introduced # in linux kernel 2.4 provides for Stateful Packet Inspection. ipchains # will allow packets in that are not part of an existing TCP connection. # Although such packets will not normally be processed by an application, # they can be used as part of a denial of service attack. We recommend # that you use an iptables firewall, which is able to audit connections # more completely. See: # # IPTABLES Firewall Example # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. By stopping all other packets in their tracks, we limit # attempts to attack our internal network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html # # oceanpark.com firewall rules (using ipchains) # --------------------------------------------- # Tell ipchains-restore what default policies to use... :input ACCEPT :forward ACCEPT :output ACCEPT # The above will accept anything not prevented by the following rules. # Deny any packet coming in on the public internet interface eth0 # which has source address of our local network (attempt to spoof an # address which should never come from any place but eth1) or which # claims to be from the reserved local loop network 127.0.0.0. -A input -i eth0 -s 198.211.65.0/24 -j DENY -A input -i eth0 -s 127.0.0.0/8 -j DENY # Accept all tcp SYN packets for protocols SMTP, HTTP, and SSH # Note, SMTP connections are further audited by my SMTP server -A input -s 0/0 -d 198.211.65.1/32 25 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT # If you query remote DNS servers, permit UDP responses from it # -A input -s <remote DNS server IP> 53 -d 0/0 -p udp -j ACCEPT # I had to add the following line to make my DNS server honor requests # from the public internet. -A input -s 0/0 -d 0/0 53 -p udp -j ACCEPT # Open up IMAP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 143 -p tcp -y -j ACCEPT # Open up FTP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 20 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT # Allow all inputs from the internal and local interfaces -A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT -A input -s 0/0 -d 0/0 -i lo -j ACCEPT # If we wanted to use masqueading (can do even for legit internal IPs) # -A forward -s 198.211.65.78 -j MASQ # Finally, DENY all connection requests to any UDP port not yet provided # for and all SYN connection requests to any TCP port not yet provided # for. Using DENY instead of REJECT means that no 'ICMP port # unreachable' response is sent back to the client attempting to # connect. I.e., DENY just ignores connection attempts. Hence, use of # DENY causes UDP connection requests to time out and TCP connection # requests to hang. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # Note that there is a fundamental difference between UDP and TCP # protocols. With UDP, there is no 'successful connection' response. # With TCP, there is. So an attacking client will be left in the dark # about whether or not the denied UDP packets arrived and will hang # waiting for a response from denied TCP ports. An attacker will not # be able to immediately tell if UDP connection requests are simply # taking a long time, if there is a problem with connectivity between # the attacking client and the server, or if the packets are being # ignored. This increases the amount of time it takes for an attacker # to scan all UDP ports. Similarly, TCP connection requests to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP pot unreachable' response. -A input -s 0/0 -d 0/0 -p udp -j DENY -A input -s 0/0 -d 0/0 -p tcp -y -j DENY # end of firewall rules

ip chain # Red Hat 7.1 Linux firewall using ipchains # May, 2001 # configured by Dennis G. Allard and Don Cohen, http://oceanpark.com # # Permission to copy is granted provided that credit is given # to the author and whatever HOWTOs are used to understand this # stuff. # # No warrenty is implied. Use at your own risk!! # This web page documents my old ipchains firewall. I have # updated my firewall to use iptable and udpated the description # of my firewall at http://oceanpark.com/notes/firewall_example.html. # This file is /etc/sysconfig/ipchains, intended for # consumption by the script /etc/rc.d/init.d/ipchains, # which makes use of the script /sbin/ipchains-restore. # In Red Hat 7.1, the man page for ipchains and for # ipchains-restore does not document the syntax of this # file. I had to read the script to understand better # what is going on. # The firewall that the Red Hat 7.1 installer set up for me # in response to my request for a high level of security # was too restrictive. And, I couldn't find any GUI tool # in either GNOME or KDE to reconfigure the firewall. # For example, the KDE menu item for editing my firewall # showed an empty set of rules even though this file and # the above startup script existed. So I had no confidence # in the GUI firewall tools, resulting in my decision to edit # this file manually. # The network # ----------- # # This firewall was running on a gateway machine having two # ethernet interfaces, an external one, eth0, which is # my DSL connection to my ISP, and an internal one, eth1 # which is assigned to 198.211.65.1, an IP number on my # class C network. I run a web server, DNS server, and # sendmail on the firewall machine itself. # # Using this file in a more complex network would require # some modifications. Particular attention would need to # be given to using the right the IP numbers and interfaces, # among other things. :-) # Running this script # ------------------- # # Red Hat 7.1 runs /etc/rc.d/init.d/ipchains at system # startup, which uses this file as input. You can # turn ipchains on and off via chkconfig. See: # # chkconfig --list | grep ipchains # # You can restart the ipchains firewall via: # # /etc/rc.d/init.d/ipchains restart # # A good way to show your ipchains rules is with: # # ipchains -vnL # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # ACCEPT all UDP packets for certain UDP services # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # SYN packets are specified via the -y flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets (the default input chain policy.) # # In other words, we allow any TCP packet through that is part of an # established TCP connection, but we are very selective in just which # connections we permit to be made to start off with. IMPORTANT: # ipchains is less powerful than iptables since iptables, introduced # in linux kernel 2.4 provides for Stateful Packet Inspection. ipchains # will allow packets in that are not part of an existing TCP connection. # Although such packets will not normally be processed by an application, # they can be used as part of a denial of service attack. We recommend # that you use an iptables firewall, which is able to audit connections # more completely. See: # # IPTABLES Firewall Example # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. By stopping all other packets in their tracks, we limit # attempts to attack our internal network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html # # oceanpark.com firewall rules (using ipchains) # --------------------------------------------- # Tell ipchains-restore what default policies to use... :input ACCEPT :forward ACCEPT :output ACCEPT # The above will accept anything not prevented by the following rules. # Deny any packet coming in on the public internet interface eth0 # which has source address of our local network (attempt to spoof an # address which should never come from any place but eth1) or which # claims to be from the reserved local loop network 127.0.0.0. -A input -i eth0 -s 198.211.65.0/24 -j DENY -A input -i eth0 -s 127.0.0.0/8 -j DENY # Accept all tcp SYN packets for protocols SMTP, HTTP, and SSH # Note, SMTP connections are further audited by my SMTP server -A input -s 0/0 -d 198.211.65.1/32 25 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT # If you query remote DNS servers, permit UDP responses from it # -A input -s <remote DNS server IP> 53 -d 0/0 -p udp -j ACCEPT # I had to add the following line to make my DNS server honor requests # from the public internet. -A input -s 0/0 -d 0/0 53 -p udp -j ACCEPT # Open up IMAP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 143 -p tcp -y -j ACCEPT # Open up FTP server (see /etc/xinetd.conf for who can use it) -A input -s 0/0 -d 0/0 20 -p tcp -y -j ACCEPT -A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT # Allow all inputs from the internal and local interfaces -A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT -A input -s 0/0 -d 0/0 -i lo -j ACCEPT # If we wanted to use masqueading (can do even for legit internal IPs) # -A forward -s 198.211.65.78 -j MASQ # Finally, DENY all connection requests to any UDP port not yet provided # for and all SYN connection requests to any TCP port not yet provided # for. Using DENY instead of REJECT means that no 'ICMP port # unreachable' response is sent back to the client attempting to # connect. I.e., DENY just ignores connection attempts. Hence, use of # DENY causes UDP connection requests to time out and TCP connection # requests to hang. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # Note that there is a fundamental difference between UDP and TCP # protocols. With UDP, there is no 'successful connection' response. # With TCP, there is. So an attacking client will be left in the dark # about whether or not the denied UDP packets arrived and will hang # waiting for a response from denied TCP ports. An attacker will not # be able to immediately tell if UDP connection requests are simply # taking a long time, if there is a problem with connectivity between # the attacking client and the server, or if the packets are being # ignored. This increases the amount of time it takes for an attacker # to scan all UDP ports. Similarly, TCP connection requests to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP pot unreachable' response. -A input -s 0/0 -d 0/0 -p udp -j DENY -A input -s 0/0 -d 0/0 -p tcp -y -j DENY # end of firewall rules

ip tables # Red Hat Linux firewall using iptables # # Created: October 2002 # Last Revised: August 2006 # # Authors: Dennis G. Allard (allard@oceanpark.com) and Don Cohen (don@isis.cs3-inc.com) # # This script works on on servers running Red Hat 7.3, 8.0, 9.0, and # RHEL ES 3 and 4. Variants of this script are in active use on # many servers. # # No warranty is implied. Use at your own risk!! # Using this script # ----------------- # # I save this file as /etc/sysconfig/iptables-precursor # and then source it and run iptables-save to create # /etc/sysconfig/iptables, which is an input file # consumed by the script /etc/rc.d/init.d/iptables, # which in turn makes use of the script /sbin/iptables-restore. # # Before mucking with setting up iptables, you should # disconnect the machine from the internet. Examine # and understand the current set of iptables rules # before you reconnect to the internet. # # To configure the set of iptables rules: # # /etc/rc.d/init.d/iptables stop # source /etc/sysconfig/iptables-precursor # # To save the current set of iptables rules for use at next reboot: # # iptables-save > /etc/sysconfig/iptables # # To dynamically restart iptables after modifying /etc/sysconfig/iptables: # # /etc/rc.d/init.d/iptables restart # # Note that /etc/rc.d/init.d/iptables is a script. You can read it to # gain understanding of how iptables uses iptables-restore to restore # iptables firewall rules at reboot. # # To examine the current set of rules in effect: # # /etc/rc.d/init.d/iptables status # # However, I prefer to show the current set of rules via: # # iptables -nvL -t filter # iptables -nvL -t nat # # or # # iptables -vL -t filter # iptables -vL -t nat # # # To configure iptables to be used at next system reboot: # # chkconfig --add iptables # # To see if iptables is currently configured to start at boot, do: # # chkconfig --list iptables # # (You might have to do chkconfig --del ipchains to remove ipchains) # # The rest of this file is derived from my old ipchains script. # # A word about routing # -------------------- # # Note that this web page does not discuss routing decisions. Routing # (see the 'ifconfig' and 'route' commands) decides which interface an # incoming packet will be delivered to, i.e. if a given packet will be # 'input' to this machine or be 'forwarded' to some interface for # delivery to another machine, say on an internal network. You should # have your routing configured before you attempt to configure your # firewall. # # Caveat. DNAT and SNAT provide a way for the IPTABLES firewall to modify the # Destination or Source IP addresses of a packet and, in this way, interact # with routing decisions. See section below: 'More about NAT and routing'. # # The network # ----------- # # This firewall is running on a gateway machine having multiple ethernet # interfaces, a public one, eth0, which is a DSL connection to an ISP, # and one or more internal ones, including eth1, which is assigned to # 192.168.0.1, an IP number on my internal private network. My public # network has static IP numbers depicted below as x.y.z.... Actual # IP numbers would, of course, be a sequence of four octets. For this # script, I assume that the firewall is running on the same machine # having the interfaces configued with my public IPs. For this reason, # most of the rules below are INPUT rules. Were I to route some of my public # static IP numbers to interfaces on one or more machines inside the # firewall on the internal network, I would modify certain rules to be # FORWARD rules instead of INPUT rules. I show some examples below of # FORWARD rules. Finally, the script is just for a single server IP, # hence all of the "/32" network masks below. A more realistic situation # would involve using IP ranges and their corresponding network masks. # # The gateway at my ISP is x.y.z.1. I run a few web servers on # x.y.z.w, a DNS server on x.y.z.n, and qmail on x.y.z.m. # # Using this file in a more complex network would require some # modifications. Particular attention would need to be given to using # the right the IP numbers and interfaces, among other things. :-) # # Preliminaries # ------------- # # To permit machines internal to the network to be able to # send IP packets to the outside world, enable IP Forwarding: # # echo 1 > /proc/sys/net/ipv4/ip_forward # # Prevent SYN floods from consuming memory resources: # # echo 1 > /proc/sys/net/ipv4/tcp_syncookies # # I place the above echo commands into /etc/rc.d/rc.local # so that they will be executed at boot time. # # The basic idea of this firewall # ------------------------------- # # Provide rules that are applied in the following order: # # ACCEPT all UDP packets for certain UDP services # # Currently the only UDP connections I accept are to my secure DNS # server, tinydns. For an explanation of why tinydns is secure, see: # http://www.faqts.com/knowledge_base/view.phtml/aid/8739/fid/699. # # DENY all other UDP packets. # # ACCEPT SYN packets just for certain TCP services # # SYN packets are specified via the -syn flag in the input # rules defined below. Note that certain services can be # further filtered by xinetd. # # DENY all other TCP SYN packets. # # ACCEPT all other TCP packets that are part of existing connections # # DENY all other TCP packets. # # In other words, we allow any TCP packet through that is part of an # established TCP connection, but we are very selective in just which # connections we permit to be made to start off with. # # A brief explanation of SYN packets goes as follows. TCP connections # are initiated via a hand shaking protocol between the client and server # programs at either end of the connection. The very first TCP packet # is sent by the client to the server and is called a SYN packet, # because it has the SYN flag set to 1 in the TCP packet header. We # only allow SYN packets for the specific servers running on specific # ports of specific hosts. Subsequently, we only permit further TCP # packets in that are determined to be part of a connection whose # initial SYN packet was already accepted and responded to by one of our # servers. This is done via 'Stateful Packet Inspection' provided by the # netfilter functionality added to linux as of kernel 2.4. By stopping all # other packets in their tracks, we limit attempts to attack our internal # network. # # There are subtle ways that Denial of Service attacks can be performed # if an attacker is able to somehow gain access to a machine inside our # network or otherwise hijack a connection. However, even in such # cases, current research is leading to ways to greatly limit the effect # of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. # # For detailed background reading about iptables, please refer to: # http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html # # begin oceanpark.com firewall rules (using iptables) # --------------------------------------------------- # Here we go... # # Configure default policies (-P), meaning default rule to apply if no # more specific rule below is applicable. These rules apply if a more specific rule below # is not applicable. Defaults are to DROP anything sent to firewall or internal # network, permit anything going out. # iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # # Flush (-F) all specific rules # iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat # The rest of this file contains specific rules that are applied in the order # listed. If none applies, then the above policy rules are used. # # Forward all packets from eth1 (internal network) to eth0 (the internet). # iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT # # Forward packets that are part of existing and related connections from eth0 to eth1. # iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT # # Permit packets in to firewall itself that are part of existing and related connections. # iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # Note, in the above two rules, a connection becomes ESTABLISHED in the # iptables PREROUTING chain upon receipt of a SYNACK packet that is a # response to a previously sent SYN packet. The SYNACK packet itself is # considered to be part of the established connection, so no special # rule is needed to allow the SYNACK packet itself. # # Allow all inputs to firewall from the internal network and local interfaces # iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT # # Enable SNAT functionality on eth0 # # SNAT (Source NAT) is used to map private source IP numbers of # interfaces on the internal LAN to one of my public static IP numbers. # SNAT performs this mapping when a client running on one of the # internal hosts (x.y.z.c) initiates a TCP connection (SYN) through # eth0. # iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth0 -j SNAT --to-source x.y.z.c # # Alternative to SNAT -- MASQUERADE # # If your firewall has a dynamic IP number because it connects to the # internet itself via DHCP, then you probably cannot predict what the IP # number is of your firewall's interface connected to the internet. In # this case, you need a rule like the following that assigns the (an) IP # number associated with eth0 to outgoing connections without you needing # to know in advance (at time of writing this rule) what that IP number is: # # iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE # # Note that the above SNAT and MASQUERADE rules are applicable # independent of how a host on the internal network is assigned its own # internal IP number. The host could be assigned a static IP number on # an internal nonpublic network (e.g. 10. or 192.168.) or it could be # itself assigned a dynamic IP number from your own DHCP server running # on the firewall, or it could even have a public static IP number. # However, it seems unlikely that one would want to assign a public IP # number to a host and then proceed to hide that number from the public. # # # Deny any packet coming in on the public internet interface eth0 # which has a spoofed source address from our local networks: # iptables -A INPUT -i eth0 -s x.y.z.s/32 -j DROP iptables -A INPUT -i eth0 -s x.y.z.c/32 -j DROP iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP # # Accept all tcp SYN packets for protocols SMTP, HTTP, HTTPS, and SSH: # (SMTP connections are further audited by our SMTP server) # iptables -A INPUT -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 80 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 443 --syn -j ACCEPT iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # Notice that the above rules are all INPUT rules. My current network # does not require me to make use of FORWARD rules, since I run all # publicly accessible servers directly on my firewall machine. But I # promised above in the description of my network to give examples of # rules used when there are servers running on machines on the internal # network. Following are examples of FORWARD rules I would use if I ran # mail, web, and ssh servers on machines on the internal network inside # the firewall. # # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 80 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 443 --syn -j ACCEPT # iptables -A FORWARD -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT # # # The first three of the above four rules would be used if my routing # delivered packets having destination IP x.y.z.m, port 25, or IP # x.y.z.w, port 80 or 443, to an interface connected to my internal # network (i.e. the packet was being FORWARDed). The fourth of the above # four rules is similar but operates on any destination IP, port 22. # # The difference between an INPUT rule and a FORWARD rule is that an # INPUT rule applies to packets that are 'input' to this machine (the # machine on which these iptables firewall rules are installed), whereas # a FORWARD rule applies to packets that are being 'fowarded', i.e. to # packets that are passing through this machine to some other machine, # such as a machine on my internal network. # # If I ran my mail server on an internal machine, I would no longer # need my previous INPUT rule for x.y.z.m and would use the above # FORWARD rule instead. # # # Begin Caveat, More about NAT and routing # # The above talk of routing is independent of the rules defined here. # I.e., routing is determined by ifconfig, route, et. al. I have not # yet seen any very good explanation of how to setup the static routing # table (what you see as output from the `route` command). I will not # attempt to remedy that lacuna at this time. If you know of some # good documenation that completely and accurately explains the # semantics of the ifconfig and route commands, i.e., explains what # affect each has such that I can reliably predict what the output # of `route` will be after executing a sequence of ifconfig and # route commands, then please do let me know. # # What *can* be done by IPTABLES rules that has the 'feel' of routing is # DNAT (Destintion NAT) and SNAT (Source NAT). DNAT and SNAT rules are, # respectively, mechnisms to map the incoming destination IP number and # outgoing source IP number to different IP numbers. For example, SNAT # can be used to map an internal source IP number to any one of your # external public IP numbers so that a workstation on your internal # network will appear to servers on the internet to which it connects to # have a source IP number equal to the mapped public IP number. # # DNAT goes the other way. It is a mechanism used typically to map # public destination IP numbers to internal private IP numbers. (In # fact, DNAT could also map public to public or private to private or # private to public, but that is left as an exercise for the reader). # So, for example, if you run a mail server on a machine configured with # an internal IP number but wish to expose that service to the external # world via a public IP number, DNAT is for you. # # Now, DNAT and SNAT are *not* routing but can *interact* with routing. # Routing decides whether a packet is going to be INPUT to this machine # or be FORWARDed to another machine. That decision is done by routing. # Once that decision is made, and only then, are the IPTABLES filtering # rules (FORWARD and INPUT rules) applied to a given packet. On the # other hand DNAT is applied by a PREROUTING rule and SNAT by a POSTROUTING # rule. It is now time for you to read the following Packet Filtering # HOWTO section: # # http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-9.html # # which states: # # It's common to want to do Network Address Translation (see the # NAT HOWTO) and packet filtering. The good news is that they mix # extremely well. [editor- The NAT HOWTO can be found at: # http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html] # # You design your packet filtering completely *ignoring* any NAT you # are doing. The sources and destinations seen by the packet filter # will be the `real' sources and destinations. For example, if you # are doing DNAT to send any connections to 1.2.3.4 port 80 through # to 10.1.1.1 port 8080, the packet filter would see packets going # to 10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80. # Similarly, you can ignore masquerading: packets will seem to come # from their real internal IP addresses (say 10.1.1.1), and replies # will seem to go back there. # # # Hence, INPUT/FORWARD rules would operate on destination IP numbers # *after* a DNAT rule is applied. But if you don't have any DNAT rules, # then INPUT/FORWARD would apply to the IP numbers as they are in the # incoming packet. # # INPUT or FORWARD would be needed purely depending on whether your # routing would cause the packet to stay on the machine where the # firewall is installed or be forwarded to another machine. THAT # decision is done by routing and *not* by DNAT or SNAT or anything # else in this firewall script. # # It is perfectly possible for the machine having the firewall to have # both public and internal IPs configured and/or for some packets to be # INPUT and others to be FORWARDed. # # DNAT is done by a PREROUTING rule, so you should think of things as # proceeding in the following order: # # 1. apply PREROUTING DNAT rules (if any) to map destination IP # 2. apply routing decisions (see ifconfig et. al.) # 3a. apply INPUT rules to packets having a destination IP on this machine # 3b. apply FORWARD rules to packets having a destination IP elsewhere # 4. apply POSTROUTING SNAT rules (if any) to map source IP # # (3a and 3b can be done in either order since they apply to a mutually # exclusive set of packets) # # I *think* that's correct. # # End Caveat, More about NAT and routing # # # Sometimes I run older versions of SSH on port 2200: # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 2200 --syn -j ACCEPT # # For imapd via stunnel (instead of xinetd-based imapd): # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 993 --syn -j ACCEPT # # For xinetd-based IMAP server (see /etc/xinetd.conf for who can use it): # #iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 143 --syn -j ACCEPT # # For DHCP server: # iptables -A INPUT -i eth1 -p tcp --sport 68 --dport 67 -j ACCEPT iptables -A INPUT -i eth1 -p udp --sport 68 --dport 67 -j ACCEPT # # For LDAP clients: # #iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 389 -syn -j ACCEPT #dga- worry about LDAP later (after I decode LDAP documentation (- # # DNS queries: # # Permit responses from our ISP's DNS server. When a client running on our # host makes a DNS query, the outgoing query is allowed since we permit all # outgoing packets. The reply will be a UDP connection back to the high # numbered client port from which the query was made. So we only need to # permit UDP packets from our ISP's DNS servers back to high numbered ports: # #iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT # # But since we trust our ISP DNS Server not not have been hacked and we may # not be sure what our client IP range is, we loosen this to: # iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 -j ACCEPT # # Running a caching DNS Server # # We need to permit querying a remote DNS server. Since I am running # a caching DNS server on x.y.z.d that makes requests for DNS lookups # to external DNS servers, those servers send back responses via UDP to # the high numbered client port on x.y.z.d where the caching server listens. # I could of course increase security by running the dns cache on its own # machine/IP and restricting to just that machine/IP. # iptables -A INPUT -p udp -s 0/0 --source-port 53 -d x.y.z.d/32 --destination-port 1024:65535 -j ACCEPT # # Running a DNS server (tinydns) # # When we run a DNS server, we have to accept UDP from anywhere to port 53 # iptables -A INPUT -p udp -s 0/0 -d 0/0 --destination-port 53 -j ACCEPT # # Running a Master DNS Server to update slave DNS servers # # You may have your server colocated at an ISP and may arrange to have your # ISP provide your primary and secondary DNS with the ISP DNS servers slaving # off of your master DNS server. This has the advantage of letting you be # in full control of the DNS zone files yet keeping the DNS servers exposed # to the public outside of your network. To achieve this, in addition to # permitting vanilla DNS responses from the ISP DNS serves, you also need # to allow TCP connections from the ISP Master DNS Server: # # Allow DNS zone transfers via TCP from ISP Master DNS server: # # iptables -A INPUT -p tcp -s <ISP Master DNS server IP>/32 -d 0/0 --destination-port 53 --syn -j ACCEPT # # For some other custom server running here listening on port <port number>: # iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port <port number> --syn -j ACCEPT # # For FTP server, restricted to specific local hosts (and see /etc/xinetd.conf): # (for public file transfers we use scp, sftp, and related SSH file transfer tools) # iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 20 --syn -j ACCEPT iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 21 --syn -j ACCEPT iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 20 --syn -j ACCEPT iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 21 --syn -j ACCEPT # # For Samba (smbd and nmbd), restricted to specific local client hosts (x.y.z.c): # iptables -A INPUT -p tcp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 139 --syn -j ACCEPT iptables -A INPUT -p udp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 137 -j ACCEPT # #Special cable modem rules. I used to have a third ethernet card, #eth2, attached to a separate ISP via a cable modem and used the rules #shown below to cause a specific Windows machine on my internal network #(192.168.0.128) to send traffic out via DSL and get it back via cable. #This violates ingres filtering rules but seems to work. It was neat #since my cable modem had higher inbound bandwidth and it permitted #me to do downloads without impacting my DSL inbound bandwidth. #I no longer have that third interface, so no longer use this technique. # #iptables -A INPUT -i eth2 -s 68.65.209.39/32 -j DROP #iptables -A INPUT -i eth2 -s 127.0.0.0/8 -j DROP #iptables -t nat -A POSTROUTING -s 192.168.0.128/32 -d 0/0 -j SNAT --to-source 68.65.209.39 # # Finally, DENY all connection requests to any UDP port not yet provided # for and all SYN connection requests to any TCP port not yet provided # for. Using DENY instead of REJECT means that no 'ICMP port # unreachable' response is sent back to the client attempting to # connect. I.e., DENY just ignores connection attempts. Hence, use of # DENY causes UDP connection requests to time out and TCP connection # requests to hang. Hence, using DENY instead of REJECT may have # the effect of frustrating attackers due to increasing the amount of # time taken to probe ports. # # Note that there is a fundamental difference between UDP and TCP # protocols. With UDP, there is no 'successful connection' response. # With TCP, there is. So an attacking client will be left in the dark # about whether or not the denied UDP packets arrived and will hang # waiting for a response from denied TCP ports. An attacker will not # be able to immediately tell if UDP connection requests are simply # taking a long time, if there is a problem with connectivity between # the attacking client and the server, or if the packets are being # ignored. This increases the amount of time it takes for an attacker # to scan all UDP ports. Similarly, TCP connection requests to denied # ports will hang for a long time. By using REJECT instead of DENY, you # would prevent access to a port in a more 'polite' manner, but give out # more information to wannabe attackers, since the attacker can positively # detect that a port is not accessible in a small amount of time from # the 'ICMP port unreachable' response. iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP # end oceanpark.com firewall rules (using iptables) # -------------------------------------------------

Well, there is yet another way in which we can get root. In the first method, we typed ‘linuxconf’ in the bash shell prompt, however, we could type the following to create a new account with root privileges and without any password: echo “ankit::0:0:::” >> /etc/passwd This command will basically edit the /etc/passwd file which is the password file which stores the Passwords and Usernames of all accounts on the machine. One thing to remember here is that you can edit the /etc/passwd file only if you are logged in as root, however, in this case we are not logged in as root, but we have booted into linux single which gives us the root shell. Hence, we can still edit it. Anyway, to understand how exactly the above command works and how it is able to create a new account without a password, we need to learn the /etc/passwd file is structured.

try this is secret Well, there is yet another way in which we can get root. In the first method, we typed ‘linuxconf’ in the bash shell prompt, however, we could type the following to create a new account with root privileges and without any password: echo “ankit::0:0:::” >> /etc/passwd This command will basically edit the /etc/passwd file which is the password file which stores the Passwords and Usernames of all accounts on the machine. One thing to remember here is that you can edit the /etc/passwd file only if you are logged in as root, however, in this case we are not logged in as root, but we have booted into linux single which gives us the root shell. Hence, we can still edit it. Anyway, to understand how exactly the above command works and how it is able to create a new account without a password, we need to learn the /etc/passwd file is structured.

this is my squid configuration # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS acl FullAccess src <IP> http_access allow FullAccess acl DenyAds url_regex "/etc/squid/deny_ads" deny_info ERR_ADS DenyAds http_access deny DenyAds acl DenyFileType url_regex "/etc/squid/deny_type" #deny_info ERR_FileType DenyFileType http_access deny DenyFileType #-------------Default Sites Blocked----------------------------------- acl DenyAll url_regex "/etc/squid/denyall" http_access deny DenyAll #------------Block Flash Video---------------------------------------- acl deny_rep_mime_flashvideo rep_mime_type video/flv http_reply_access deny deny_rep_mime_flashvideo #------------Yahoo! Messenger----------------------------------------- acl ym dstdomain .messenger.yahoo.com .psq.yahoo.com acl ym dstdomain .us.il.yimg.com .msg.yahoo.com .pager.yahoo.com acl ym dstdomain .rareedge.com .ytunnelpro.com .chat.yahoo.com acl ym dstdomain .voice.yahoo.com acl ymregex url_regex yupdater.yim ymsgr myspaceim # Other protocols Yahoo!Messenger uses ?? acl ym dstdomain .skype.com .imvu.com http_access deny ym http_access deny ymregex #-----------------Deny You Tube Domain--------------------------------- acl youtube_domains dstdomain .youtube.com .googlevideo.com .ytimg.com http_access deny youtube_domains acl x-type req_mime_type -i ^application/octet-stream$ acl x-type req_mime_type -i application/octet-stream acl x-type req_mime_type -i ^application/x-mplayer2$ acl x-type req_mime_type -i application/x-mplayer2 acl x-type req_mime_type -i ^application/x-oleobject$ acl x-type req_mime_type -i application/x-oleobject acl x-type req_mime_type -i application/x-pncmd acl x-type req_mime_type -i ^video/x-ms-asf$ acl x-type req_mime_type -i application/x-shockwave-flash acl x-type2 rep_mime_type -i ^application/octet-stream$ acl x-type2 rep_mime_type -i application/octet-stream acl x-type2 rep_mime_type -i ^application/x-mplayer2$ acl x-type2 rep_mime_type -i application/x-mplayer2 acl x-type2 rep_mime_type -i ^application/x-oleobject$ acl x-type2 rep_mime_type -i application/x-oleobject acl x-type2 rep_mime_type -i application/x-pncmd acl x-type2 rep_mime_type -i ^video/x-ms-asf$ http_access deny x-type all http_reply_access deny x-type all http_access deny x-type2 all http_reply_access deny x-type2 all http_access deny x-type all http_reply_access deny x-type all acl FullAccRes src <IP> http_access allow FullAccRes #---------------------Allowed IP List----------------------------------------------- acl AllowIPList src "/etc/squid/allow-iplist" http_access deny !AllowIPList #---------------------BLUE DART SITES----------------------------------------------- acl AllowBlue url_regex "/etc/squid/allow-bluedart-url" acl AllowBlueIP src "/etc/squid/allow-bluedart-client" http_access allow AllowBlue AllowBlueIP #---------------------AFTS URL SITES----------------------------------------------- acl AllowAfts url_regex "/etc/squid/allow-Afts-url" acl AllowAftsIP src "/etc/squid/allow-Afts-client" http_access allow AllowAfts AllowAftsIP #---------------------Exception Sites with Spicific IP Address---------------------- acl AllowURL url_regex "/etc/squid/allow-url" deny_info http:///error_unblock_url.php AllowURL acl AllowClient src "/etc/squid/allow-client" http_access allow AllowURL AllowClient #-------------------Allow Exchange-------------------------------------------------- acl AllowExURL url_regex "/etc/squid/allow-exchange-url" acl AllowExClient src "/etc/squid/allow-exchange-iplist" http_access allow AllowExURL AllowExClient #########################Allow p2p############################################################################ acl Allowp2pURL url_regex "/etc/squid/allow-p2p-url" acl Allowp2pClient src "/etc/squid/allow-p2p-iplist" http_access allow Allowp2pURL Allowp2pClient #-----------------Remote Office----------------------------------------------- acl AllowCitiRem url_regex "/etc/squid/allow-citiremote-url" acl AllowCitiRemIP src "/etc/squid/allow-citiremote-ip" http_access allow AllowCitiRem AllowCitiRemIP # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed #http_access allow localnet http_access allow localhost # And finally deny all other access to this proxy http_access deny all