Web And Email Hosting, Jsp, Tomcat, J2Ee, Hibernate Programming Blog

recently discovered security vulnerabilities and tell you how to combat them. CERT The CERT Coordination Center is part of the Survivable Systems Initiative at the Software Engineering Institute, a federally funded research and development center at Carnegie-Mellon University. CERT stands for Computer Emergency Response Team. It was founded in 1988 by DARPA (the Defense Applied Research Projects Agency) in response to the now infamous Internet Worm Incident. Initially, CERT was intended to be the central place where one could report all computer security incidents. Since 1988, CERT has broadened its purpose to include: Assisting in the creation of new incident response teams. Coordinating the efforts of teams when responding to large-scale incidents. Providing training to incident response professionals. Researching the causes of security vulnerabilities, prevention of vulnerabilities, system security improvement, and survivability of large-scale networks. As part of these efforts, CERT issues advisories that warn of newly discovered security problems and explain how to protect against them. These advisories are available at the CERT Web site at http://www.cert.org/. You can also have CERT advisories e-mailed to you by subscribing to the CERT Advisory Mailing List. To subscribe to the CERT advisory mailing list, send email to majordomo@cert.org. In the body of the message, type: subscribe cert-advisory To remove your name from the CERT mailing list, send email to majordomo@cert.org. In the body of the message, type: unsubscribe cert-advisory After you have subscribed to the mailing list, you will eventually begin to receive CERT Advisory e-mail messages. In an average month, you can expect several messages from the CERT mailing list. CERT issues warnings on a wide variety of computer security topics encompassing many operating systems and applications, so not every message will apply to your situation. Nevertheless, it is a good idea to read each message carefully to become familiar with the broader security risks of the Internet. A typical CERT Advisory is divided into several sections: Topic A one-line description of the vulnerability. Effected Systems Who is vulnerable. For example, it may say, This vulnerability affects Red Hat Linux systems versions 5.0 and older. Overview A very brief description of the vulnerability.
Note: In case you are looking for affordable webhost to host and run your servlet application check Vision mysql5 web hosting services

portsentry[]: attackalert: Host: 10.0.0.40 is already blocked. Ignoring portsentry[]: attackalert: Connect from host: 10.0.0.4/10.0.0.4 to TCP port: 15 portsentry[]: attackalert: Host: 10.0.0.40 is already blocked. Ignoring . . . portsentry[13371]: securityalert: Psionic PortSentry is shutting down portsentry[13371]: adminalert: Psionic PortSentry is shutting down The first part of the previous example of PortSentry log output shows PortSentry starting up. As PortSentry begins listening to each port, that port is noted in a separate log message. The next set of messages shows the local computer being scanned. Someone from host 10.0.0.4 ran the nmap command to scan the ports on the computer being protected by PortSentry. PortSentry caught the scan of port 31337 and blocked all subsequent attempts to scan other ports. Finally, the last set of messages shows PortSentry being shut down. This is noted as a security alert because someone that wasn’t you could be shutting down PortSentry to hide the fact that they had broken into your system. Note If you have been running the Logcheck package (described earlier in this chapter), these messages show up in the e-mail messages you receive each hour from Logcheck. In particular, the attack alerts would appear under the “Active System Attack Alerts” heading. Also, the words “ACTIVE SYSTEM ATTACK!” would appear in the e-mail’s message line. Restoring access If access was cut off to a computer that you wanted to have access, there are several things you can check to correct that problem: /etc/hosts.deny: See if the computer’s IP address was mistakenly added to this file. This would cause network services to be denied to the host at that IP address. /var/portsentry/portsentry.blocked: Check that an entry for the computer’s IP address wasn’t added to the portsentry.blocked.udp or portsentry.blocked.tcp files. route: Run the /sbin/route command to see if messages from the computer are being rerouted to a dead host (probably the localhost). ipchains: Run the ipchains -L command to see if a new firewall was created to block access from the computer. Tip To make sure that access isn’t cut off again, you can add the IP address of the remote computer to the /etc/portsentry/portsentry.ignore file. Future improper scans or requests for services won’t cause the remote computer to be blocked. Where to Get More Information about Security This chapter should be a useful ally in your battle against security problems. Unfortunately, no chapter or book can win the war for you; computer security is an endless conflict fought on an ever-changing battlefield. Each new operating system upgrade brings with it the potential for new security holes. Each new application can have its own hidden perils. Even if you change nothing on your network, crackers may discover some new exploit that had previously remained hidden. Fortunately, resources on the Internet can alert you to the most
Note: In case you are looking for affordable and reliable webhost to host and run your j2ee application check Vision best web hosting services

If there are any services that you don’t want open, you should turn off those services by using chkconfig service off (replacing service with the service name) or by editing the configuration file in the /etc/xinetd.d directory that represents the service and changing disable = no to disable = yes. 4. If there are services that you want to be available from your computer, make sure that the port numbers representing those services are not being monitored by PortSentry. Remove the port number from the TCP_PORTS and/or UDP_PORTS options in the /etc/portsentry/portsentry.conf file, or PortSentry will report that there is a possible stealth scan on the port. 5. Restart PortSentry as follows: # /etc/init.d/portsentry start 6. Run nmap again, as described previously. The ports offering legitimate services, as well as the ports being monitored by PortSentry, should all appear to be open. 7. Check the /var/log/messages file to make sure that PortSentry is not trying to monitor any ports on which you are offering services. When you have determined that PortSentry is set up the way you would like it to be, run the nmap command from another computer on your network. This time, replace 127.0.0.1 with the name or IP address of the PortSentry computer. If everything is working properly, the first port that the remote computer scans on your PortSentry computer should cause all subsequent requests to scan ports to be denied. Tip Another way to set off PortSentry from another computer is with the telnet command. If, for example, PortSentry is monitoring port number 11 on your computer named jake, you could run the following command from the remote computer: $ telnet jake 11 Telnet would then try to talk to a service on port 11. The attempt will be logged, and further attempts from the remote computer to access jake should be denied. Tracking PortSentry intrusions Besides blocking access to your system or performing some other action you assign, the activities of PortSentry are logged using your Red Hat Linux system’s syslog utility. As a result, PortSentry’s start-up, shutdown, and scan-detection activities are logged to your /var/log/messages file. The following are some examples of output from PortSentry in your /var/log/messages file. portsentry[13259]: adminalert: Psionic PortSentry 1.0 is starting. portsentry[13260]: adminalert: Going into listen mode on TCP port: 1 portsentry[13260]: adminalert: Going into listen mode on TCP port: 11 portsentry[13260]: adminalert: Going into listen mode on TCP port: 15 portsentry[13260]: adminalert: Going into listen mode on TCP port: 79 portsentry[13260]: adminalert: Going into listen mode on TCP port: 111 . . . portsentry[13260]: adminalert: PortSentry is now active and listening. portsentry[]: attackalert:Connect from host:10.0.0.4/10.0.0.4 to TCP port: 31337 portsentry[]: attackalert: Connect from host: 10.0.0.4/10.0.0.4 to TCP port: 11
Note: If you are looking for cheap and reliable webhost to host and run your mysql application check Vision professional web hosting services

Changing the portsentry.modes file The /etc/portsentry/portsentry.modes file defines the modes in which the PortSentry command is run at boot time. Here is how that file appears by default: tcp udp #stcp #sudp #atcp #audp The tcp and udp options are the basic PortSentry modes for the TCP and UDP services, respectively. Your other choices of options include stealth TCP (stcp) and advanced stealth TCP (atcp) and stealth UDP (sudp) and advanced stealth UDP (audp). Only run one TCP service and one UDP service. So, if you uncomment a stealth or advanced stealth service, be sure to add a comment in front of the appropriate basic service. To activate the new services, you would then execute the following command: # /etc/init.d/portsentry restart The new PortSentry modes will take effect immediately. Those new modes will also be in effect when your computer reboots. Testing PortSentry You can test that your ports are properly protected in different ways. What you want to do is run a program that a potential intruder would run and see if it trips the appropriate response from Portsentry. For example, you could use a port scanner to see how your ports appear to the outside world. You could also use a command, such as telnet, to try and set off a particular port to see if PortSentry catches it. nmap is a popular software package for scanning TCP and UDP ports. You can give the nmap command a host name or IP address, and it will scan about 1500 ports on computer to see which ports are open (and presumably offering services that could potentially be cracked). You can download the nmap package from the following Web site: www.insecure.org/nmap. An RPM of nmap is also available. You can download the nmap-frontend package, which contains a simple graphical interface to nmap called xnmap. I suggest that you install the packages on the system running PortSentry as well as on another system on your LAN (if one is available). Then run the following procedure on the PortSentry system to test it: 1. If PortSentry is running, shut it down by typing the following: # /etc/init.d/portsentry stop 2. Type the following nmap commands to see which ports are open on the local system: # nmap -sS -O 127.0.0.1 # nmap -sU -O 127.0.0.1 The output shows you which ports are currently offering services on your computer for TCP and UDP protocols, respectively. 3.
Note: In case you are looking for affordable webhost to host and run your servlet application check Vision servlet hosting services

This ipchains rule would deny (in other words, drop) all packets from the remote computer. To make this action permanent, you could add the ipchains options (from the -I to the end of the line) to the /etc/sysconfig/ipchains file, replacing the $TARGET$ with the actual IP address of the computer you want to deny access to. KILL_HOSTS_DENY: This option is used to deny requests for any network services that are protected by TCP wrappers. This option is set by default as follows: KILL_HOSTS_DENY=”ALL: $TARGET$” With the preceding option set, $TARGET$ is replaced by the IP address of the intruding remote computer and the line in quotes is added to the /etc/hosts.deny file. For example, if the remote computer’s IP address were 10.0.0.59, the line that appears in /etc/hosts.deny would be: ALL: 10.0.0.59 KILL_RUN_CMD: Instead of using firewalls, rerouting, or TCP wrappers to deny an intruding computer from accessing your computer, you can choose any command you like in response. With the BLOCK_TCP and BLOCK_UDP options set to “2″, the value of KILL_RUN_CMD is run in response to a scan of your monitored ports. The value of KILL_RUN_CMD should be the full path to the script you want to run, plus any options. To include the IP address of the remote computer or the port number that was scanned, you could include the $TARGET$ or $PORT$ variables, respectively. Here is how the example appears that you would want to modify: KILL_RUN_CMD=”/some/path/here/script $TARGET$ $PORT$” Caution It is recommended that you not use any KILL_RUN_CMD to retaliate against the intruding remote computer. Firstly, it is quite possible that the computer that is scanning your ports has itself been cracked and is thus not a valid target for retaliations, and secondly, retaliation may simply incite the cracker into further attacks on you. PORT_BANNER: You can send a message to the person who sets off the PortSentry monitor by setting the PORT_BANNER option. By default, no message is defined. However, you can uncomment the following line to use that message. (An abusive message is not recommended.) PORT_BANNER=”** UNAUTHORIZED ACCESS PROHIBITED *** YOUR CONNECTION ATTEMPT HAS BEEN LOGGED. GO AWAY.” The number of scans from an intruding computer that PortSentry will accept before setting off the responses described above can be set by using the SCAN_TRIGGER option. By default, that option is set as follows: SCAN_TRIGGER=”0″ The 0 value means that you won’t accept any scans from an intruding system. In other words, the first scan will trip the PortSentry monitor. You can increase this value to be tolerant of one or more errant scans (though you probably won’t want to).
Note: In case you are looking for affordable and reliable webhost to host and run your business application check Vision php5 hosting services

The portsentry.blocked. files contain a list of computers that have been blocked from accessing your computer during the current session. The portsentry.blocked.tcp file contains IP addresses of computers that have improperly scanned TCP ports on your computer. Addresses of computers that have been blocked after scanning UDP ports are contained in the portsentry.blocked.udp file. Access to ports on your computer is only blocked during the current session (that is, until the next reboot or restart of PortSentry). So, to more permanently exclude remote computers, you should impose other restrictions (such as by using the /etc/hosts.deny file, a firewall command, or a reroute to a dead host). These methods are described later in this chapter. Choosing responses Someone scanning a port is like them checking a door in your house to see if it is locked. In most cases, it indicates that someone is checking your system for weaknesses. That is why, when another computer scans your ports, the default response from PortSentry is to block further access from the other computer to your computer for the duration of the current session. No action is taken to permanently block access from that computer. The BLOCK_UDP and BLOCK_TCP options in the portsentry.conf file set which type of automatic response is taken when ports are scanned. Here is how these options are set by default: BLOCK_UDP=”2″ BLOCK_TCP=”2″ The value in quotation marks determines how PortSentry reacts to a scan of your ports by another computer. The following list describes each of these values. A value of “2″ (the default value) causes access to be temporarily blocked to services for the scanned protocol (TCP or UDP) and for the action to be logged. Also, if any commands were defined to be run by a KILL_RUN_CMD option, that command is then run. (This option is not configured by default.) A value of “0″ causes port scans to be logged, but not blocked. A value of “1″ causes the KILL_ROUTE and KILL_HOSTS_DENY options to be run. (See the following list for descriptions of these options.) By default, further requests from the remote computer will be rerouted to a dead host, and the remote host’s IP address will be added to the /etc/hosts.deny file, thereby denying access to network services. Following are some suggestions on options you can use to can change the responses to your ports being scanned: KILL_ROUTE: This option runs the /sbin/route command to reroute requests from the remote computer to a dead host. By default, this option is set to the following value, which effectively drops the request from the remote computer: KILL_ROUTE=”/sbin/route add -host $TARGET$ gw 127.0.0.1″ Note Instead of rerouting IP packets from the remote computer, you could use firewall rules to deny access. For example, if your computer uses ipchains firewalls (which Red Hat Linux uses by default), you can uncomment the following line to deny access from the remote computer to your computer: KILL_ROUTE=”/sbin/ipchains -I input -s $TARGET$ -j DENY -l”
Note: If you are looking for reliable webhost to maintain and run your java application check Vision java hosting services

ports. If the scanner is blocked after accessing port 1, it won’t be able to get information about any other ports that may be open on your computer. Another criterion is to include ports that are often checked specifically by intruders because those services may be vulnerable to attack. These include the systat (port 11) and netstat (port 15) services. You will want to remove ports from the list in the portsentry.conf file if you are actually running the service assigned to that port. On the other hand, you may want to add ports to the list if you are paranoid about attacks and you want a bit more coverage. The portsentry.conf file contains some examples that you can uncomment (remove the # sign) so that more ports are monitored. If you change from basic to stealth scans (as described in the “Changing the portsentry.modes file” section, later in this chapter), the ports that are monitored are those defined by the ADVANCED_PORTS_TCP and ADVANCED_PORTS_UDP options. Here is how those two options are set by default: ADVANCED_PORTS_TCP=”1023″ ADVANCED_PORTS_UDP=”1023″ The two preceding entries indicate that all ports from 1 to 1023 are monitored. Monitoring higher port numbers can result in many more false alarms, so this practice is not recommended. If you find that PortSentry is being tripped accidentally, you may want to exclude the ports being tripped by using the ADVANCED_EXCLUDE_TCP and ADVANCED_EXCLUDE_UDP options. The following example shows how these two values are set by default: ADVANCED_EXCLUDE_TCP=”111,113,139″ ADVANCED_EXCLUDE_UDP=”520,138,137,67″ By default, ident and NetBIOS services for TCP (ports 111, 113, and 139) and route, NetBIOS, and Bootp broadcasts for UDP (ports 520, 138, 127, and 67) are excluded from the advanced scan. (The exclusion is because a remote computer may hit these ports without representing any misuse.) If you are running in stealth mode, you should likewise exclude any services that you are running on your system by adding their port numbers to this list. Identifying configuration files Besides the portsentry.conf file, there are several other configuration files used by PortSentry. You can identify the locations of these other files within the portsentry.conf file. Here are how those files are defined:# Hosts to ignore IGNORE_FILE=”/etc/portsentry/portsentry.ignore” # Hosts that have been denied (running history) HISTORY_FILE=”/var/portsentry/portsentry.history” # Hosts that have been denied this session only (temporary until next restart) BLOCKED_FILE=”/var/portsentry/portsentry.blocked” Chances are that you will not want to move the location of these configuration files. Here are some descriptions of what these files are used for: The portsentry.ignore file contains a list of all IP addresses that you do not want blocked (even if they improperly try to access ports on your computer). By default, all IP addresses assigned to the local computer are added to this file. You can add IP addresses of trusted computers, if you like. The portsentry.history file contains a list of IP addresses for computers that have been blocked from accessing your computer.
Note: If you are looking for cheap webhost to host and run your apache application check Vision apache web hosting services

In response to attacks (represented by scans of the ports being monitored), all further attempts to connect to any services for the protocol (TCP or UDP) will be blocked. The computers that are blocked from accessing your system are listed in either the portsentry.blocked.tcp or portsentry.blocked.udp files (in the /var/portsentry directory), depending on which protocol was scanned (TCP or UPD). If you decide to run with just the default configuration, any computers that have access blocked by mistake can have access restored to them by removing entries created for those computers in these files. Configuring PortSentry Chances are that you will want to make some changes to the way that PortSentry runs. To change how PortSentry behaves, you can modify the /etc/portsentry/portsentry.conf file. In that file, you can choose which ports to monitor, the mode in which to monitor, and the responses to take when a scan is detected. The responses can include: Blocking access by the remote computer Rerouting messages from the remote computer to a dead host Adding a firewall rule to drop packets from the remote computer The only other file you may want to change is the /etc/portsentry/portsentry.modes. The portsentry.modes file simply contains the modes that PortSentry can be run in. Changing the portsentry.conf file To edit the portsentry.conf file, as root user, open the /etc/portsentry/portsentry.conf file using any text editor. The following sections describe the information that can be changed in that file. Selecting ports The portsentry.conf file defines which ports are monitored in basic and stealth modes. By default, only basic TCP and UDP modes are active, so only those ports are monitored (unless you change to one of the stealth modes). The TCP_PORTS and UDP_PORTS options define which ports are monitored. Here is how they appear in the portsentry.conf file: TCP_PORTS=”1,11,15,143,540,635,1080,1524,2000,5742,6667,12345,12346,20034,31337, 32771,32772,32773,32774,40421,49724,54320″ UDP_PORTS=”1,513,635,640,641,700,32770,32771,32772,32773,32774,31337,54321″ Unless you are a TCP/IP expert, you’re probably wondering what services these ports represent. The Internet Assigned Numbers Authority (IANA) assigns services to UDP and TCP ports. You can see these assignments at the following Web address: www.iana.org/assignments/port-numbers Network services in Red Hat Linux (as well as other Linux/UNIX systems) obtain port number assignments from the /etc/services file. So, in general, you can simply check the /etc/services file to find out most of the services that are assigned to ports being scanned. The ports being assigned for monitoring are chosen based on a couple of different criteria. Lower port numbers (1, 11, 15, etc.) are chosen to catch port scanners that begin at port 1 and scan through a few hundred
Note: If you are looking for best quality webspace to host and run your tomcat application check Vision shared web hosting services

Advanced Stealth: This mode offers the same detection method as the regular stealth mode, but instead of monitoring only the selected ports, it monitors all ports below a selected number (port number 1023, by default). You can then exclude monitoring of particular ports. This mode is even more sensitive than Stealth mode and is, therefore, more likely to cause false alarms than regular stealth mode. Note When a port is “bound” by PortSentry or any other network service daemon process, all requests that come to that port from the network are handled by the binding process. For example, when the httpd daemon binds to port 80, requests for Web services from the network are processed by httpd. Besides selecting the PortSentry mode and the ports that are monitored, you can also choose the response to your computer being scanned. By default, PortSentry can log intrusion attempts and block access to the intruder. However, PortSentry also offers ways of using other tools to respond to intrusions, including firewall rules, route changes, and host denial configuration. These methods of response are described later in this chapter. Downloading and installing PortSentry The portsentry package is not included in the Red Hat Linux distribution. You can download the package from any Red Hat Linux FTP mirror site. For example, you could use the following command to find a PortSentry package from an available FTP site: # rpmfind portsentry After PortSentry is downloaded, run the following command from the directory you downloaded it to: # rpm -i portsentry* The installed portsentry package consists of several configuration files (in the /etc/portsentry directory), the portsentry start-up script (/etc/init.d/portsentry), and the portsentry command (in /usr/sbin). There are also several README files of interest in the /usr/share/doc/portsentry* directory. Note The PortSentry package used in this example is portsentry-1.0.11.i386.rpm. Procedures described in this section may not work completely if you are using a different version of PortSentry. This version was included with the Red Hat Linux 7.1 PowerTools. The PowerTools CD is no longer being produced. Using PortSentry as-is As with Logcheck, you don’t need to do anything to get PortSentry to work after it is installed. By default, here is what PortSentry does when you install the portsentry package: The /etc/init.d/portsentry start-up script runs automatically when you boot to run levels 3, 4, or 5 (levels 3 and 5 are most commonly used). The following port numbers are configured to be monitored by PortSentry in basic mode: TCP: 1, 11, 15, 143, 540, 635, 1080, 1524, 2000, 5742, 6667, 12345, 12346, 20034, 31337, 32771, 32772, 32773, 32774, 40421, 49724, 54320 UDP: 1, 513, 635, 640, 641, 700, 32770, 32771, 32772, 32773, 32774, 31337, 54321
Note: In case you are looking for affordable and reliable webhost to host and run your j2ee application check Vision web and email hosting services

Services on your Red Hat Linux system produce messages of different levels. Message levels, from most critical to least critical, are as listed in Table 14-9. Table 14-9: Message Levels Level What It Means Level What It Means alert immediate action needed err error condition crit critical info purely informational debug detailed processing information notice important, but not an error emerg system unusable warning potential error The line shown in the example indicates that all messages from the info level (*.info) and above are logged to the /var/log/messages file. However, messages of types mail, news, authpriv, and cron are excluded because they are sent to other log files. All authpriv (authpriv.*) messages are logged to the /var/log/secure file. mail messages (mail.*) are all logged to the /var/log/maillog file. With this default configuration of syslog, Logcheck should catch all major security related activities. There are a few situations, however, where you may want to modify the /etc/syslog.conf file. For example, if you are receiving a lot of log messages for a particular type of service (such as ppp if you are having trouble with a dial-up connection), you may consider directing messages for that service to its own log file. Then, if Logcheck uncovers a problem, it’s easier to go through only that log file for those messages relating to the problem service. Another temporary change you may want to consider is if you need to debug a problem with your system. Changing *.info to *.debug temporarily can give you more details about a problem. (Just make sure you change it back later, or syslog will chew up too much of your system resources.) Guarding Your Computer with PortSentry While Logcheck gathers and sorts log messages that may represent attempts to break into your computer system, the PortSentry takes a more active approach to protecting your system from network intrusions. PortSentry can be installed and configured on a Red Hat Linux system to monitor selected TCP and UDP ports, and can then react to attempts to access these ports (presumably by people trying to break in) in ways that you choose. Like Logcheck, PortSentry is another software package from Psionic Software, Inc., (www.psionic.com/abacus/portsentry). PortSentry acts as a nice compliment to Logcheck by actively looking for intrusion behavior on network ports. When PortSentry perceives an attack, it reacts to the attack (in ways that you choose) and produces log messages about the activity that can be forwarded to the system administrator by Logcheck. PortSentry operates in several different modes. Each of these modes can be applied to monitoring of TCP and UDP ports. The PortSentry modes include: Basic: This is the mode PortSentry uses by default. Selected UDP and TCP ports in this mode are bound by PortSentry, giving the monitored ports the appearance of offering a service to the network. Stealth: In this mode, PortSentry listens to the ports at the socket level instead of binding the ports. This mode can detect a variety of scan techniques (strobe-style, SYN, FIN, NULL, XMAS and UDP scans), but because it is more sensitive than basic mode, it is likely to produce more false alarms.
Note: In case you are looking for affordable webhost to host and run your web application check Vision cheap hosting services