There are a number of reasons for the growing success of Linux in the computing environment today. Many users like the fact that the Linux operating system is easily accessible and inexpensive. Many Linux distributions are available for download from the web. Inexpensive media and documentation can be purchased from a wide variety of sources. Many argue that they get "more bang for the buck" than the traditional Unix sources (Sun, HP, IBM, etc.). Linux companies are expecting that the next generation of Intel processors will make the price/performance ratio even more appealing (especially given that Linux will likely support the processors before Microsoft Windows). Lastly, some just do not want to use Microsoft products.
Why choose Red Hat 7.0? While there are many very good Linux distributions ITS has chosen to support Red Hat for a number of reasons.
· Red Hat does a good job of securing their default installations
· Red Hat is readily available.
· Red Hat can be pre-installed on computers purchased on the University's Dell Computer contract.
· Red Hat Network provides access to patches that are both timely and accessible.
The key to securing Linux is solid system management. This is true for any operating system connected to a network. Out of the box, many Linux distributions install services that are not needed and are configured insecurely. However, concrete steps can be taken to secure a Linux system.
Consider the costs of not maintaining your system. Hours or days can be spent repairing a compromised system. Loss of data can cost time and have serious financial implications - the later being particularly true for research systems with corporate backing. Most importantly, your machine can cause harm to you, the University, or others on the Internet.
What this document is and is not. Our purpose is to provide you with guidelines and specific steps that you should take after installation of Red Hat 7.0. This document is neither an installation "how-to" nor a system administrator's handbook. If you need additional information about Linux or are not running Red Hat 7.0 please take some time to review these documents.
Linux Network
Administrations Guide
Linux Administrators Security Guide
Securing and Optimizing Linux Red Hat edition
·In addition to reviewing this document also take a look at Securing and Optimizing Linux Red Hat edition, The Red Hat 7.0 Getting Stated Guide and Reference Manual.
·Know how to use man pages
·Determine the system role and security requirements. Who will have access to the system, how will users be allowed to access the system, who will have access to data on the system, what are the password requirements, etc. If you are unsure, select the Workstation installation.
·Always ask is a network service really needed. The first task in securing any system is disable remote access.
·Develop backup and disaster recovery plan. If you do not have a backup plan, contract with UNIXOps for backups.
·If you are running a server develop an audit schedule that includes auditing logs, system, and vulnerability analysis.
·The more documentation you have about how the system is configured (BIOS settings, lilo.conf, what programs are SUID etc) and what changes are made to the system the better off you will be. If you are running a server provide documentation for your users detailing what the users can do and how to do it.
·Keep up-to-date with operating system patches. The University maintains a Red Hat mirror [where is this] that will have up-to-date patches. Subscribe to the Redhat.net service so that you will get e-mail notifications of patches. The service will even keep a record of what patches have been applied to your system. Consider subscribing to the mailing lists found at Security Focus - specifically bugtraq, focus-linux, linux-secnews.
Physical and hardware security provide a number of considerations. First, if the system is a server containing sensitive data ensure that only authorized persons have physical access to the console. Ensure that the console has a reasonably short lockout time period in case someone forgets to logoff. In the system BIOS disable booting from removable media after the operating system is installed.
It is prudent to disconnect the machine from the network during installation. The network interface is up during the installation and you will want to wait until the system is patched and configured to put the machine on the campus network.
Keep system role foremost in mind when choosing installation type and packages (i.e., don't install everything).
During installation you will be prompted to create a boot diskette. Create the diskette and store it in a safe and secure location. If you need to recreate this disk later you can use /sbin/mkbootdisk.
Require password to enter single user mode at boot by editing /etc/inittab. You must do this because no passwords are required to logon in single user mode. After "si::sysint...:" enter the following line:
~~:S:wait:/sbin/sulogin
Check that remote root logon are disabled for Telnet and FTP. TTY interfaces that allow root logon are listed in /etc/securetty. Comment out ttyx (where x is the interface number) to disable root remote logon. Accounts that should not be allowed to logon via FTP are listed in /etc/ftpusers. Root and system accounts should be listed in this file.
Configure accounts that can/cannot log into the system (apm for example). Account logon configuration is controlled in /etc/security/access.conf. The format is similar to TCP wrappers. For example, if you wanted to limit console logons to root, ownerjdoe you would include in /etc/security/access.conf
-:ALL EXCEPT root ownerjoe :console
Configure logging and configure log rotation. Edit /etc/syslog.conf to include the following
*.warn;*.err /var/log/syslog
*.kern /var/log/kernel
If you have a central log server you should instead enter the following (substitute loghost with the name of your server)
*.warn;*.err @loghost
*.kern @loghost
Next, create the log files and set permissions
[root@localhost /]# touch /var/log/syslog /var/log/kernel
[root@localhost /]# chmod 700 /var/log/syslog /var/log/kernel
Log rotation is managed by logrotate. You will need to edit /etc/logrotate.d/syslog with the following to enable rotation of the new logs you have created.
/var/log/kernel {
#compress
postrotate
/usr/bin/killall -9 klogd
/usr/sbin/klogd &
endscript
}
/var/log/syslog {
#compress
postrotate
/usr/bin/killall -HUP syslogd
endscript
}
Note that compress is commented. The default installation does not compress log files. You may want to consider compression.
The default configuration is to rotate logs weekly and keep 4 weeks of logs. These settings can be changed in /etc/logrotate.conf if you require a different configuration.
Synchronizing your system clock to an accurate time server is important so that you can prove your log files are accurately time stamped. Create a file in /etc/cron.hourly that contains the following:
/usr/sbin/ntpdate -bu -t 3 your-local-gateway
/sbin/hwclock --systohc
where “your-local-gateway” is the ipaddress of the gateway on your local network. If you are using DHCP you might consider using boulder.colorado.edu instead of the local gateway. Hourly this will first set the system clock to match the time on your local gateway that is synchronized with the network time protocol. Next, your system will update the computer hardware clock.
Applications that have the suid bit set can masquerade as one user, possibly a very powerful one such as root, and yet can be run by regular users. You should review what programs have suid bit set and decide if it is appropriate. The following command will provide a list of SUID/SGID programs.
[root@localhost xinetd.d]# find / -type f \( -perm -04000 -o -perm -02000 \) \-exec ls -l {} \;
The list will look something like
-rwsr-xr-x 1 root root 14184 Jul 12 18:47 /bin/su
-rwsr-xr-x 1 root root 55356 Aug 5 09:08 /bin/mount
-rwsr-xr-x 1 root root 25404 Aug 5 09:08 /bin/umount
-r-sr-xr-x 1 root root 15340 Aug 22 19:19 /sbin/unix_chkpwd
-r-xr-s--x 1 root games 40300 Aug 21 11:02 /usr/bin/gataxx
-r-xr-s--x 1 root games 20636 Aug 21 11:02 /usr/bin/glines
-r-xr-s--x 1 root games 69292 Aug 21 11:02 /usr/bin/gnibbles
-r-xr-s--x 1 root games 45452 Aug 21 11:02 /usr/bin/mahjongg
-r-xr-s--x 1 root games 21052 Aug 21 11:02 /usr/bin/same-gnome
-rwsr-xr-x 1 root root 6964 Aug 25 04:47 /usr/bin/kcheckpass
-rws--x--x 2 root root 793603 Aug 7 09:05 /usr/bin/suidperl
-rwxr-sr-x 1 root man 35260 Aug 23 09:56 /usr/bin/man
-rwxr-sr-x 1 root uucp 171452 Aug 24 08:09 /usr/bin/minicom
-rwsr-xr-x 1 root root 155436 Jul 17 13:24 /usr/bin/ssh
-r-s--x--x 1 root root 13536 Jul 12 05:56 /usr/bin/passwd
-rwsr-xr-x 1 root root 20392 Aug 24 21:49 /usr/sbin/userhelper
-rwxr-sr-x 1 root utmp 6584 Jul 12 22:46 /usr/sbin/utempter
You can use the command chmod to disable the suid bits on those programs that you do not want users to run. Take care as you can cause your system not to behave as desired. Also, keep a copy of the list in a secure location for auditing. The use of chmod to disable the suid bits is:
[root@localhost /]# chmod a-s /usr/bin/mahjongg
Red Hat 7.0 uses xinetd to control Internet services (xinetd is a secure replacement for the Internet service daemon inetd). A xinetd tutorial is available at http://www.macsecurity.org/resources/xinetd/tutorial.shtml. Another good resource is Raynal's xinetd article in Linux Focus found at http://www.linuxfocus.org/English/November2000/article175.shtml. More details on xinetd are covered in the server section.
Many UNIX system administrators are accustomed to using TCP wrappers to manage access to certain network services. Any network services managed by xinetd (as well as any program with built-in support for libwrap) can use TCP wrappers to manage access. xinetd can use the /etc/hosts.allow and /etc/hosts.deny files to configure access to system services.
The default policy (no access) is implemented with a simple /etc/hosts.deny:
ALL: ALL
This denies all service to all hosts, unless they are permitted access by entries in the allow file.
The explicitly authorized hosts are listed in the /etc/hosts.allow file. This example, allows access from the mymachine.Colorado.edu:
ALL: LOCAL mymachine.Colorado.edu
If you intend to provide network accessible services on your Linux system, then you should use TCP wrappers, see the hosts_access (5) man pages for more detailed information
Disable runtime services that you may not require. Disabling unneeded services will both give you some performance boost and limit your exposure to potential flaws in those services. Red Hat uses SYSV-style init (init calls runtime services). For more information review the init man page. The default Red Hat 7 workstation will run the following services using the default runlevel 5:
Be certain that you fully understand the consequences of removing a service before you take action. Some possibilities are: apmd if you do not require power management, pcmcia for desktops, isdn and pppoe if you do not use ISDN or ADSL, and sendmail. The easiest way to remove these services on the workstation is to use /usr/X11R6/bin/tksysv or /usr/sbin/ntsysv if you do not want a GUI.
Check what ports you now have open by issuing the following:
[root@localhost /etc]$ netstat -at
Active Internet connections (servers and established)
Proto
Recv-Q Send-Q Local Address
Foreign Address
State
tcp 0
0 localhost.localdom:7110 localhost.localdom:1028 ESTABLISHED
tcp 0
0 localhost.localdom:1028 localhost.localdom:7110 ESTABLISHED
tcp 0
0 localhost.localdom:7110 localhost.localdom:1027 ESTABLISHED
tcp 0
0 localhost.localdom:1027
localhost.localdom:7110 ESTABLISHED
tcp 0
0 *:7110
*:* LISTEN
tcp 0
0 *:X
*:* LISTEN
tcp 0
0 *:printer
*:*
LISTEN
tcp 0
0 *:auth
*:* LISTEN
tcp 0
0 *:1024
*:* LISTEN
tcp 0
0 *:sunrpc *:* LISTEN
Record this in a safe place and check your system against the list on a regular basis. If you see a new port listed your system may have been compromised.
SSH is a suite of tools that provide secure replacements for a number of network applications including telnet, rlogin, and ftp. SSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. Additionally, SSH provides a myriad of secure tunnelling or port-forwarding capabilities.
OpenSSH is an open source version of the SSH suite that is installed on RedHat systems. Additional information about OpenSSH features can be found at http://www.openssh.com/features.html
Red Hat 7.0 installs OpenSSH 2.1.1 and because there are compatibility issues with 2.1.1 and the 2.3 that ITS centrally managed servers run you will want to upgrade your ssh software to version 2.3. RPM packages can be downloaded from ftp://ftp3.usa.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm. Refer to the rpm man pages for upgrade instructions.
sudo allows a permitted user to execute a command as the superuser or another user, as specified in the sudoers file. The real and effective uid and gid are set to match those of the target user as specified in the passwd file. By default, sudo requires that users authenticate themselves with a password (NOTE: this is the user's password, not the root password). Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (five minutes by default). The –v flag can be used to update the time stamp without executing a command. sudo looks to /etc/sudoers to determine who is authorized and what that user can do. visudo provides a safe way to edit /etc/sudoers as it will check the file for errors prior to saving.
Review the man page sudoers (5) prior to making any changes so that you understand the format of /etc/sudoers. A couple of examples:
jdoe ALL = ALL
Joe can act as any user (the default will be root) and run all commands
jdoe ALL = (operator) /bin/ls, /bin/kill, /usr/bin/who
The user jdoe may run /bin/ls, /bin/kill, and /usr/bin/lprm -- but only as operator. For example, the user must enter:
sudo -u operator /bin/ls.
sudo is not installed by default, download and install the sudo rpm from ftp://ftp.freshmeat.net/pub/rpms/sudo/.
As with the default workstation installation, secure shell is installed and configured by default. This also includes the secure shell daemon and the configuration of the service. There is no good reason not to use ssh particularly for the administration of your server. Also part of the package is secure copy (scp) that you should use as a replacement for ftp.
Red Hat now uses pluggable authentication modules (PAM) to provide configurable authentication scheme. Using PAM systems can be tailored to meet specific security needs for authentication, logging, and session management. Before working with PAM take a look at the documentation on your system at /usr/share/doc/pam-0.72/html/pam.html.
In addition to using shadow passwords and MD5 the default installation uses pam_cracklib to check password strength. pam_cracklib will by default require that a password be of at least 6 characters, must not have fewer than 10 characters in the new password that are not in the old password, and the user will be given three attempts to create an acceptable password. More information on changing these settings can be found at /usr/share/doc/pam-0.72/html/pam-6.html#ss6.3. As an example, consider if you were to modify the line calling pam_cracklib in /etc/pam.d/system-auth to look like:
password required pam_cracklib.so difok=3 minlen=15
The result would be that you would require that passwords be a minimum of 15 characters and have no more than 3 characters in the new password that are in the old password.
Password protect the Linux Loader (LILO). This is important for systems where the physical security of the system cannot be adequately ensured. Edit /etc/lilo.conf and after the prompt line enter:
password = your-password-here
restricted
Note that /etc/lilo.conf and now your password are stored in clear text. Use the following to protect the file
[root@localhost /]# chmod 600 /etc/lilo.conf
[root@localhost /]# chattr +i /etc/lilo.conf
Enter /sbin/lilo to enable the changes you have made. With these changes in place, the system will boot as normally. However, if any extra commands are given to LILO a password will now be required.
First look at the xinetd configuration files in /etc/xinetd.d. The standard set that is likely to be installed is:
finger linuxconf-web ntalk rexec rlogin rsh talk telnet tftp wu-ftpd
For example, start with telnet. The file looks like:
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
}
Since we have decided to use ssh go ahead and disable telnet by replacing the line "flags = REUSE" with
disable = yes
Another example, look at wu-ftpd:
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l -a
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
}
If for some reason you have a users that must use ftp. You can limit access from a specific host by using the "only_from" tag. For example to limit ftp access from specific hosts on the network you would enter:
only_from = 128.138.113.0/24
In this example, hosts on the 128.138.113.0 network will be able to access the ftp server.
Lastly, you will want to make your changes effective. First, find out what process identifier (PID) xinetd is using:
[root@localhost /etc]# ps -aux | grep xinetd
root 514 0.0 0.4 2244 1032 ? S 10:40 0:00 xinetd -reuse -pi
root 938 0.0 0.2 1520 584 pts/0 S 11:30 0:00 grep xinetd
xinetd is using PID 514. Now, issue the following command for force xinetd to reread the configuration files and restart
[root@localhost /etc]# kill -USR2 514
E-mail -use campus mail servers or use the sendmail kit available from UNIXops at ftp://boulder.colorado.edu/pub/sendmail/. The kit has been compiled on Linux. You will need to have both hesiod and Berkeley newdb support. Be sure to read and understand the README file.
Redhat installs LPRng for print spooling. You will need to take a look at the documentation at http://www.astart.com/lprng/start.htm to get started. /usr/bin/printtool provides a graphical interface for configuring printers but you will also want to familiarize yourself with the line printer spooler daemon lpd, lpr that submits jobs to lpd, and the printer configuration file /etc/printcap.
You can edit /etc/lpd.perms to limit access to your print server. The standard configuration is to allow only root to control jobs, allow anyone to get job status information, allow the job owner to remove jobs, and allow any connections. If you want to limit access to a specific network you could add before the line "DEFAULT ACCEPT":
REJECT SERVICE=X NOT REMOTEIP=128.138.113.0/255.255.255.0
A few more examples:
REJECT NOT REMOTEHOST=localhost
The IP based equivalent of the localhost example above looks like this:
REJECT NOT REMOTEIP=127.0.0.1
This will specify a list of hosts to allow.
REJECT NOT
REMOTEHOST=localhost,spot.colorado.edu,ucsu.colorado.edu
REJECT NOT REMOTEIP=127.0.0.1,128.138.129.2,128.138.129.83
And similarly, a list of IPs...
REJECT NOT
REMOTEIP=127.0.0.1,128.138.129.2,128.138.129.83
You do not need to specify SERVICE=X in the
REJECT statements and they will cover any type of connection.
Many recommend that you avoid running NFS if at all possible, as it can be a security risk. If you are exporting file systems using NFS service, be sure to configure the /etc/exports file with the most restrictive access possible. This means not using wildcards, not allowing root write access, and mounting read-only wherever possible. For specific configuration information refer to the man page exports(5)
As an example edit the exports file /etc/exports and add:
/var/ftp (ro,insecure,all_squash)
/pub 128.138.113.0/255.255.255.0(ro,root_squash)
/home/jdoe hostjdoe.colorado.edu (rw, root_swash)
The first line enables read only access to the directory /var/ftp to all network accessible hosts (i.e., the Internet). The insecure option allows for clients that do not use a reserved port for NFS. all_squash maps all uids and gids to the anonymous user. The second line exports the directory pub to all hosts on the 128.138.113.0 network as read-only. root_squash maps any uid/gud 0 to anonymous user. The third line exports the jdoe home directories to Jdoe's host for read and write access.
When ever you change /etc/exports you will need to run the following command on your terminal:
[root@localhost]# /usr/sbin/exportfs -a
NFS is registered and controlled though the portmap deamon. You should further limit access to NFS by editing hosts.allow or hosts.deny files.
.
For example, to allow NFS access to 206.54.109.200, and the entire 128.138.113 network, put this in /etc/hosts.allow:
portmap: 206.54.109.200 128.138.113.0/255.255.255.0
The SMB protocol is the core of the Common Internet File System developed by Microsoft for file and printer sharing. Samba provides services for Microsoft file and print clients. A few things to consider when running Samba.
Limit access to specific hosts
Edit the file /etc/smb.conf in the [global] section to set up the list of hosts that are allowed access to the Samba server and the interfaces that the Samba server will listen on:
hosts allow = 128.138.
interfaces 128.138.113.20/24 127.0.0.1/32
bind interfaces only = true
You should use encrypted passwords read /usr/doc/samba-2.0.5a/docs/textdocs/ENCRYPTION.txt to lean more about this.
Red Hat Linux 7.0 defaults to looking for Samba passwords in /etc/samba/smbpasswd. The path is set in the configuration file /etc/smb.conf. You can create a template /etc/smbpasswd with the following command:
[root@localhost]# mksmbpasswd.sh < /etc/passwd >/etc/smbpasswd
[root@localhost]# chmod 600 /etc/smbpasswd
Edit the template to remove entries for system accounts like bin, daemon, and ftp.
Do not use "guest" or anonymous shares
Consider using secure copy (scp) for any uploads and only use FTP for anonymous downloads. Also, edit /etc/xinetd.d/wu.ftpd to limit access from only the required hosts (see the discussion on xinetd).
Red Hat installs Apache 1.3 web server software. Most settings are in the main configuration files found in /etc/httpd/conf in Red Hat Linux. The file httpd.conf sets up basic operating parameters for the HTTP daemon; access.conf sets up basic access rules; and srm.conf sets up basic server configuration parameters like the document root, aliased directories, CGI script directories, and icons for indexes.
The Apache manual is available from the Apache Web site at http://www.apache.org/docs/ A valuable discussion on secure web servers is located in the Red Hat Reference Guide (http://www.redhat.com/support/manuals/RHL-7-Manual/ref-guide/p6817.html). Also, be sure to understand the University of Colorado Web policy [where is this posted] before installing a new web server on the campus network.
First, so that clients can not walk though the entire file system, lock down the server by editing access.conf to set the root directory access and options to:
<Directory />
Options None
AllowOverride None
order deny,allow
deny from all
</Directory>
Now, open access to the directories required in access.conf, by specifing only the access and options absolutely necessary. In the example below access is granted to IP addresses on the 128.138.113:
<Directory /home/httpd/html>
Options None
AllowOverride None
order deny,allow
deny from all
allow from 128.138.113.
</Directory>
Alternatively, if your data is public, you could use the following:
<Directory /home/httpd/html>
Options None
AllowOverride None
order deny,allow
allow from all
</Directory>
Consider the implications of allowing any of the following before you set them in the<Directory> directive:
·ExecCGI Should only be allowed for CGI directories
·FollowSymLinks If users have write access to the HTML directories, they can set symbolic links to areas that contain sensitive data Includes Server side includes can be used to bypass default file access restrictions
·IncludesNOEXEC Safer version of Includes that disables the #exec statement and #include of CGI scripts
·Indexes The daemon will print a directory listing for any directory without an index file
·(index.html). This may expose the names of data files ordinarily hidden
If you have need for secure web server (i.e.,https) you should refer to discussion on the topic in the RedHat reference guide (http://www.redhat.com/support/manuals/RHL-7-Manual/ref-guide/p6817.html).
Firewall rules + Portsentry using PMFirewall as a firewall setup script.
You can get pmfirewall at
http://www.pointman.org/PMFirewall/download/pmfirewall-1.1.4.tar.gz
You can get portsentry for redhat 7 at
ftp://rpmfind.net/linux/powertools/7.0/i386/RedHat/RPMS/portsentry-1.0-8.i386.rpm
download pmfirewall
tar xfvz pmfirewall-1.1.4.tar.gz
cd pmfirewall-1.1.4
sh install.sh
Follow the instructions on the screen. For most users you can use the following as a guide:
For the first question on where to install hit enter.
For external interface it defaults to eth0 which is your first ethernet
interface. Most users can hit yes for this.
Are there any IP ranges which require unrestricted access? N
Are there any IP ranges which should be blocked completely? N
Is your IP address assigned via DHCP? say yes or no depending of if your ip is dynamically assigned
Are you running a FTP Server on ports: 20/21 N Unless you need to run an ftp server the best answer is no
Are you running a SSH Server on port: 22 Say yes if you want to connect to your machine remotely and install ssh it works like telnet but is far more secure.
Are you running a Telnet Server on port: 23 N
Are you running a SMTP Server on port: 25 N
Are you running a DNS Server on port: 53 N
Are you running a Finger Server on port: 79 N
Are you running a Web Server on port: 80 y or n depending on if you want to run a web server most users will say no.
Are you running a POP Server on port: 110 n
Allow IDENT connections on port: 113 y This allows computers to identify where a connection came from irc and some other services require this so it is a good idea to leave it on.
Are you running a NNTP Server port: 119 N
Are you using NTP, it requires port: 123 N
Do you wish to open NetBIOS/SAMBA ports 137-139 (not recommended)? N
Are you running an IMAP Server on port: 143 N
Are you running a SSL Web Server on port: 443 say Y if you are running a ssl secure web server otherwise say N most users will say N
Are you running Routed (RIP) on port: 520 N
Do you wish to open NFS port 2049 (not recommended)? N
Do you wish to open X-Server ports 5999-6003 (not recommended)? N (It is better to do this through ssh since it will secure the connection)
Are there any other ports you wish to open to the outside? N
Start PMFirewall on bootup? Y
Do you want pmfirewall to autodetect your IP address? Y
Will this box Masquerade connections for other PC's N
Start PMFirewall by typing
sh /etc/rc.d/init.d/pmfirewall start
During the installation PMFirewall will be configured to load under at least run-level 5 (see discussion on SYSV earlier).
As root type
rpm -ivh portsentry-1.0-8.i386.rpm
Then edit the file /etc/portsentry.conf with your favorite editor. Uncomment the line (i.e., remove the “#”the line:
#KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY –l”
Next, make a file called /etc/restart_firewall.sh. The file should contain:
#!/bin/sh
#The purpose of this script is to reset the firewall to prevent
#portsentry from permanently blocking a host without hurting security.
#On a PPro200 it takes about 2 seconds to reset the firewall. On most
#Modern machines it can do it in under a second.
#Kill all copies of portsentry
killall -9 portsentry
#Stop the firewall
/etc/rc.d/init.d/pmfirewall stop
#Flush the firewall
/sbin/ipchains -F
#Resart the firewall
/etc/rc.d/init.d/pmfirewall start
#Restart Portsentry
/usr/sbin/portsentry -atcp
/usr/sbin/portsentry -audp
To make the file owned by root and not readable, writeble, or executable by anyone else as root enter:
chown root.root /etc/restart_firewall.sh
chmod 700 /etc/restart_firewall.sh
Then run
crontab -u root -e
Then add an entry that looks like this.
*/5 * * * * /etc/restart_firewall.sh
This will restart the firewall every 5 minutes to keep people who accidentally connect on the wrong port on your computer from being blocked forever. However it does stop the immediate scan just fine.