January 2007
Monthly Archive
Mon 29 Jan 2007
Posted by sales under
redhatNo Comments
Network Services connection should be allowed, then starts the appropriate server (if required) to handle the connection. In this section, we’ll take a brief look at some of the configuration options xinetd has that relate to system security. xinetd’s main configuration file is /etc/xinetd.conf. Let’s have a look at that now: This file simply sets up some sensible default values that apply to all services managed by xinetd (by placing them inside defaults {} ), then tells xinetd to read configuration information from all the files in /etc/xinetd.d. The default values have the following meanings: instances = 60 No more than 60 instances of each sub-server will be started logtype = SYSLOG authpriv Service log output is sent to syslogd using the authpriv facility (so that the output is logged to a file that can only be read by privileged users) log_on_success = HOST PID Logs remote host address and process id (if there is one) when a service is started or exits log_on_failure = HOST Logs remote host address when a service failed to start (with the reason for the failure) cps = 25 30 Allows maximum connection rate of 25 connections per second (first number) and disable service for 30 seconds (second number) if this rate is exceeded Monitoring Services It is useful to be able to check what services are running on our Red Hat Linux 9 system, and especially what ports they are listening on. This is because before a remote machine can make a connection to our local machine, some process on our local machine has to be ready to receive network packets (listening) sent to its port number. There are a couple of tools that we can use to identify what ports are listening on our machine: netstat and nmap. netstat Netstat is a multipurpose utility for reporting on all things relating to networks. We’ll invoke it with the following flags: Flag Meaning -t TCP 419
Hint: This post is supported by Gama web hosting php services
Mon 29 Jan 2007
Posted by sales under
redhatNo Comments
Network Services In the Service Configuration window, there are a few important things to note. First, the status line immediately below the toolbar icons shows us that the system is running in Runlevel 5, and that this is the runlevel that is being edited. (A runlevel is a particular state of the operating system, characterized by a set of processes that are started. If we haven’t changed the system runlevel, then we’ll be editing the default, which is just what we want. For more information on runlevels, see the man pages for inittab and telinit. Be careful if you experiment with these, as mistakes could render your system unbootable, forcing you to boot from CD-ROM to correct the problem.) 4. If you click on the name of a service, the information panels on the right of the window will show a brief description of what the service is for, together with its status. Note Not all services represented here represent external services, some are internal daemons vital for the smooth running of your computer. It’s a good idea to take a moment to read through all the descriptions here and start to familiarize yourself with what’s available. 5. Now scroll through the list of services, and clear the check boxes next to lpd and portmapper, as these are two services that do allow remote connections to our system and that are enabled by default but probably aren’t needed in the majority of cases. When we make a change to any of the services, the Save button is no longer grayed out. So, when you’re happy with the changes you’ve made, click on save to update the configuration files. Note that this does not actually start or stop any services; all it does is update configuration files so that next time the runlevel that is being edited is entered, the right services are started, and when it is being left, the right services are stopped. If you want to make the change effective immediately, highlight the service and click the Start, Stop or Restart buttons on the toolbar according to what you want to do. xinetd You may have noticed in the table of services and their daemons presented earlier that several services (such as echo, daytime, and chargen) appear to be provided by the same service, namely xinetd. This isn’t a typo - xinetd does provide these, and it also looks after a whole lot more. xinetd is an enhanced version of the standard Unix inetd (internet daemon) program, which manages incoming connections to many different services (hence it is sometimes called a “super server”). It is a long-running service (usually started when the system boots) that listens for incoming TCP/IP connections on ports that it has been told about in its configuration file. When a connection request arrives, xinetd checks that the 418
Hint: This post is supported by Gama web hosting php services
Sun 28 Jan 2007
Posted by sales under
redhatNo Comments
Network Services 139 system to access Red Hat Linux filesystems as network shares. Passwords may be encrypted, but algorithm is weak. is not sensitive. https 443 Secure Web server. Httpd Depends on server configuration. Only if Web server needs to run on system. Ipd 515 Print Daemon. Allows remote machines to send print jobs to our printers. LPRng or cups Weak. Information passed over network without encryption. Only run if your system has printers you want to share. rsh/rlogin 514 Allows remote system to access command line shell on local machine without supplying a password. rsh-server Weak. Relies on DNS (Domain Name Service) to identify remote system, so vulnerable if DNS compromised. No. nfs 2049 (requires portmapper to be listening on port 111) Network File System. Allows other systems to access file systems remotely. nfs-utils Weak. Information passed over network without encryption. Only use to access information that is not sensitive. Having decided which services are required, we need to make sure they are started, and make sure that any of the undesirable services are stopped. This is done through the Red Hat Service Configuration application. As an example, we’ll use the Red Hat Service Configuration application to turn off the lpd and portmapper services since our theoretical demonstration machine doesn’t have any printers attached to it (so there’s no point in running lpd), and we’re not using NFS or NIS (so there’s no point in running portmapper). Try it Out: Running the Service Configuration Application 1. Start the Service Configuration application by choosing Main Menu | System Settings | Server Settings | Services, or typing redhat-config-services at the command prompt. 2. If you’re not logged on as root (and you shouldn’t be!), you’ll be prompted for the root password in this dialog: 3. Now the services configuration menu appears: 417
Quick Hint: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting plans
Sun 28 Jan 2007
Posted by sales under
redhatNo Comments
Network Services access command line shell on local machine. connections can be authenticated to ensure remote system is the right one and not an imposter. command line required. telnet 23 Allows remote system to access command line shell on local machine. telnet-server Weak. User names and passwords sent in plain text. No. Use ssh instead. SMTP 25 Simple Mail Transfer Protocol. Used to transfer mail between systems. sendmail Weak. Mail tranferred in plain text. Only if mail needs to be handled locally. Encrypt sensitive mail before sending. time 37 Sends current time (in seconds since 00:00 1st Jan 1900) back to sender. xinetd None. No. Use NTP for time synchronisation. It is more accurate and has better security features. finger 79 Gives information about local system or users to remote machine. finger-server None. No. http 80 Web server. Httpd Depends on server configuration. Only if Web server needs to run on system. auth (ident) 113 Indentification protocol. Allows remote system to determine indentity of a user of a particular TCP/IP connection. pident Supports DES encryption of returned information. Only if needed to access some public services (e.g. some ftp sites and IRC). sftp 115 Secure File Tranfer Protocol. FTP-like data transfers over secure SSH connection. openssh Good. Only if file transfer required. nntp 119 Network News Transfer Protocol. Used to transfer USENET news groups. inn Depends on server configuration. Only if newsgroup server needs to be run on system. smb 137 138 Server Message Block. Allows Microsoft Windows Samba Weak. Information passed over network without encryption. Only use to access information that 416
Quick Hint: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting plans
Sun 28 Jan 2007
Posted by sales under
redhatNo Comments
Network Services Unless we are connected to an isolated network where every machine is secure and trusted, we must assume that all the information we send and receive across the network can be intercepted by a third party (i.e. someone other than us and the intended recipient of the data). Network Services One way a hacker may try to gain unauthorized access to our system is by exploiting weaknesses in the network services that we are running on our Red Hat Linux system. These are programs - often run in the background with no controlling terminal (called “daemons” in Unix, and “services” in Microsoft Windows) - that provide services to other computers. Examples include file transfer protocol (ftp), Web, Network File System (NFS), and print servers. Enabling and disabling services The first and easiest way of reducing our vulnerability is to disable all the services that we don’t need. In particular, we need to be very careful about older services that send sensitive information (such as user names and passwords) across the network without any form of encryption (in plain text). Also, services that gratuitously hand out information about our system should be avoided where possible. The following tables will help you to decide which services you need to run. Service TCP/UDP Port number Description Red Hat Package Security Level Run it? echo 7 Sends received characters back to sender. xinetd None. No. (Unless you really need to debug remote terminal problems) daytime 13 Sends current date and time as ASCII string back to sender. xinetd None. No. Use NTP for time synchronisation. It is more accurate and has better security features. chargen 19 Generates continuous stream of ASCII characters for testing terminals. xinetd None. No. (Unless you really need to debug remote terminal problems) chargen 20 (data) 21 (control) Random ports >1023 File Transfer Protocol. Allows transfer of files to and from remote systems. vsftp or wu-ftpd Weak. user names and passwords sent in plain text. “Anonymous FTP” allows access with no password. No. Use FTP instead. ssh 22 Secure shell. Allows remote system to Openssh Good. Data is encrypted and Only if remote access to 415
Note: If you are looking for good and quality webspace to host and run your java application check professional java hosting services
Sun 28 Jan 2007
Posted by sales under
redhatNo Comments
System Integrity Setting up Tripwire to Run Automatically We’ve already seen how logwatch is set up to run automatically every day at 04:02. We can very easily set up Tripwire to run at the same time. Create a two-line script called /etc/cron. daily/run-tripwire containing the following lines: #!/bin/sh /usr/sbin/tripwire –check Make sure the script is owned by root and has permissions of 500 (r-x——) so it is executable only by root. This script invokes Tripwire and gets it to check the system’s integrity according to the rules in the policy file, and using the database we just created as its baseline. When cron runs this script at 04:02 every day its output is sent to root (or whoever is configured in the MAILTO variable in /etc/crontab). Updating the Tripwire Database We’ll test the script by running it now. Type /etc/cron.daily/run-tripwire on the command line as root, and check that Tripwire runs successfully. Examine the output produced carefully, and we should see that Tripwire has spotted the addition of the run-tripwire script to /etc/cron.daily and flagged it as a critical change. To stop Tripwire from reporting this change, which we made and know is OK, as a policy violation every time it runs, we need to update Tripwire’s database. We do this by running tripwire –update, specifying a Tripwire report file that we wish to use for the update. To see what files are available, run ls-ltr/var/lib/tripwire/report; choose the last report listed as this will be the most recent one. The command to run (all on one line) is then: # tripwire –update –twrfile /var/lib/tripwire/report/rh9-20030209- 040304.twr replacing the report filename with the most recent .twr file on your system. This will produce a text file and start vi for us so we can edit the file. Each proposed database update is tagged with [x], and if we don’t want the update to be made, we simply delete the ‘x’. If we don’t want to use vi, then add –visual gedit to the command and Tripwire will start the graphical editor instead. When we exit the editor, we’re asked for the local passphrase, and then updates are applied to the database. Subsequent Tripwire integrity checks should no longer warn us about the change to /etc/cron.daily. Network Security Virtually all Red Hat Linux 9 systems will be connected to other computers via a network at some time. This may be a permanent connection through a network adapter to a LAN (Local Area Network), an “always on” connection to the Internet, or a dial-up connection to an Internet Service Provider that is active only when required. Whatever the connection, we need to make sure that a hacker cannot use it to gain access to our system, or mount a “denial of service” attack that prevents legitimate use of our computing resources. In this section, we’ll look at some of the techniques that we can use to secure our system and make life hard for the potential hacker. 414
Note: If you are looking for good and quality webspace to host and run your java application check professional java hosting services
Sat 27 Jan 2007
Posted by sales under
redhatNo Comments
System Integrity and contain both letters and numbers. See the Tripwire manual for more information. ——————————————— Creating key files… (When selecting a passphrase, keep in mind that good passphrases typically have upper and lower case letters, digits and punctuation marks, and are at least 8 characters in length.) Enter the site keyfile passphrase: Verify the site keyfile passphrase: Generating key (this may take several minutes)…Key generation complete. (When selecting a passphrase, keep in mind that good passphrases typically have upper and lower case letters, digits and punctuation marks, and are at least 8 characters in length.) Enter the local keyfile passphrase: Verify the local keyfile passphrase: Generating key (this may take several minutes)…Key generation complete. ———————————————– Signing configuration file… Please enter your site passphrase: Wrote configuration file: /etc/tripwire/tw.cfg A clear-text version of the Tripwire configuration file /etc/tripwire/twcfg.txt has been preserved for your inspection. It is recommended that you delete this file manually after you have examined it. ———————————————- Signing policy file… Please enter your site passphrase: Wrote policy file: /etc/tripwire/tw.pol A clear-text version of the Tripwire policy file /etc/tripwire/twpol.txt has been preserved for your inspection. This implements a minimal policy, intended only to test essential Tripwire functionality. You should edit the policy file to describe your system, and then use twadmin to generate a new signed copy of the Tripwire policy. 11. The final step in initialization is to run the command tripwire — init. We are prompted for the local passphrase, then Tripwire scans all the files listed in the configuration file and gathers baseline data against which all future scans are run. This may take several minutes, so be patient: Note It is vital that we are confident the system is in a sound state before initializing the database, otherwise there’s little point in using Tripwire. After the database is initialized, it’s a good idea to put a copy on write-once media (e.g. CD-ROM) so that it cannot be altered: # tripwire –init Please enter your local passphrase: Parsing policy file: /etc/tripwire/tw.pol Generating the database… *** Processing Unix File System *** Wrote database file: /var/lib/tripwire/rh9.twd The database was successfully generated. 413
Hint: If you are looking for very good and affordable webspace to host and run your tomcat hosting application check Sandzak.com tomcat web hosting provider
Sat 27 Jan 2007
Posted by sales under
redhatNo Comments
System Integrity 7. 8. 9. 10. print $line; } # Print the statistics on STDERR, so they won’t get redirected by > print STDERR “Number of additions: $Additionsn”; print STDERR “Number of removals: $Removalsn”; Create a text file containing this script and call it /usr/local/bin/cleanpol.pl, and make it executable by running the following command: Note Depending on the examples you’ve followed earlier in the book, you may need to acquire root privileges at this point. # chmod +x /usr/local/bin/cleanpol.pl Now we can use this Perl script to produce a customized Tripwire policy file: # cd /etc/tripwire # mv twpol.txt twpol.txt.orig # /usr/local/bin/cleanpol.pl twpol.txt … Number of additions: 38 Number of removals: 125 This little script saved us from making 163 manual changes to the Tripwire policy file! (The number of changes made on your system will vary depending on which packages you have installed.) You can review the changes that were made with the diff command: diff twpol.txt.orig twpol.txt Now, use gedit, or your favorite text editor, to review the contents of the updated /etc/tripwire/twpol.txt file. In particular, there may be a problem with the line defining the policy for /sbin/e2fsadm. If the cleanpol.pl script uncommented this line, then the note tune2fs? at the end of the line is treated by Tripwire as a relative path to a file, and the policy file is rejected. Simply delete this note. In other words: /sbin/e2fsadm -> $(SEC_CRIT) ; tune2fs? becomes: /sbin/e2fsadm -> $(SEC_CRIT) ; Now we have set up the Tripwire policy file, the next step is to initialize the Tripwire database. This is done by running the twinstall.sh script in /etc/tripwire: # ./twinstall.sh This script asks us to enter site and local passphrases (a term used to describe a long “password”), generates encryption keys and cryptographically secures the configuration and policy files to prevent unauthorized changes: [root@rh9 tripwire]# ./twinstall.sh ——————————————— The Tripwire site and local passphrases are used to sign a variety of files, such as the configuration, policy, and database files. Passphrases should be at least 8 characters in length 412
Hint: If you are looking for very good and affordable webspace to host and run your tomcat hosting application check Sandzak.com tomcat web hosting provider
Sat 27 Jan 2007
Posted by sales under
redhatNo Comments
System Integrity Tripwire to check a file or directory (optional whitespace, string beginning with /), then we should check that the file or directory exists. If not, we should comment out the line to prevent Tripwire from generating an error. Similarly, if we find a line in the policy file that looks like a commented out file (optional whitespace, #, optional whitespace, string beginning with /), then we should check if the file or directory exists. If it does, then we’ll remove the comment to reinstate the file. 6. We’ll write the script as a filter, so it reads configuration lines from STDIN and writes to STDOUT. Any lines that don’t look like either of the types of line we’re interested in are passed through unmodified. It would be nice to know how much work we’ve saved ourselves by counting up the number of lines that the script modifies. Here’s the script (hopefully your new knowledge of Perl will give you an idea of the structure that we’ve employed, even if the details are still a bit beyond you - they’ll come with practice): #! /usr/bin/perl -w # Filter for Tripwire policy file. Looks for lines that # start with optional whitespace and a filename, and # comments them out if the file does not exist. Also # looks for commented out lines containing filename and # removes comment if they do exist. $Additions = 0; $Removals = 0; # Read each line from stdin into the $line variable while ($line = ) { # Look for lines that match a pattern (the Perl # pattern matching characters are enclosed in []) # start with optional white space [ ^s* ] # then a ‘#’ [ # ] # then more optional white space [ s* ] # then a string starting with ‘/’ that doesn’t # contain white space [ /S+ ] # # The last part of the pattern is enclosed in () # so that if the pattern matches, we can access # this part through the $1 variable. # # This pattern matches a commented out entry/ if ( $line =~ /^s*#s*(/S+)/ ) { # Found commented out entry. If the file exists, # strip off the comment character. if ( -e $1 ) { $line =~ s/^s*#//; $Additions++; } # Now look for a line that’s like the above but # without the ‘#’ comment character. } elsif ( $line =~ /^s*(/S+)/ ) { # Found entry that starts with ” /”. If file # does not exist, then comment out entry. if ( ! -e $1 ) { $line = “# ” . $line; $Removals++; } } # Output the line (whether modified or not) 411
Note: If you are looking for reliable and quality webspace company to host and run your servlet application check professional servlet hosting services
Sat 27 Jan 2007
Posted by sales under
redhatNo Comments
System Integrity Try it Out: Downloading, Configuring, and Running Tripwire 1. 2. 3. 4. Tripwire is available in RPM format for Red Hat Linux, which makes installation very straightforward. It’s available on the Red Hat Linux 9 CD-ROMs, but as an interesting exercise, we’ll try using the rpm command’s built-in FTP and HTTP client. We’ll use the rpm command to download and install the Tripwire RPM with a single command! Open a terminal window and switch to the root user and type in the following command (all on one line): Note You’ll need to change the httpproxy IP address and httpport port number to suit your Internet connection (omit them if you don’t need to go through a proxy server to access the Internet). # rpm -iv –httpproxy 10.4.65.2 –httpport 3128 http://ftp.redhat.com/pub/redhat/linux/9/en/os/i386/RedHat/RPMS/tripwire- 2.3.1-17.i386.rpm The command also assumes that you’re running on an Intel architecture machine. If not, replace the occurrences of i386 with your machine’s architecture. After a few minutes (depending on the speed of your Internet connection), you should see the message Preparing packages for installation… followed by tripwire-2.3.1-17, and be returned to the command prompt. You can confirm that the Tripwire package was installed by running the following command: # rpm -q tripwire If all is well, you’ll get the package version information back; if not, you’ll get a message saying that package tripwire is not installed (in which case, just download the RPM in the conventional way, and try again). Now we’ve got tripwire installed, we can go on to configure its policies and complete the setup. Before diving in to the configuration, we should take time to read the README file in /usr/share/doc/tripwire-2.3.1, and the twintro and twpolicy man pages to familiarize ourselves with the required configuration tasks. These can be divided into three distinct steps: Setting up the policy file Initializing the Tripwire database Configuring Tripwire to run periodically and report system integrity violations Let’s begin with the policy file. Tripwire’s policy file defines which files and directories tripwire should monitor for changes, and what sort of changes are significant. For some files, e.g. /bin/login, any change in file contents, modification date, or ownership is suspicious, but we’d expect them to be accessed frequently. Other files, such as log files, are expected to grow in size, but not change ownership. The policy file that is installed with the RPM in /etc/tripwire/twpol. txt tells Tripwire to monitor many files that probably don’t exist on our system, so we’ll get lots of spurious error messages when we run an integrity check. What we really need to do is edit the policy file so that files and directories that don’t exist aren’t monitored, and conversely, if there are files and directories that do exist but are commented out in the policy file are reinstated. It would be tedious to do this by hand, so let’s use our new-found knowledge of Perl to write a script to do it for us. 5. The algorithm we need to employ is straightforward. If we find a line that looks like an instruction to 410
Note: If you are looking for reliable and quality webspace company to host and run your servlet application check professional servlet hosting services
« Previous Page — Next Page »