Beginning Red Hat Linux 9 phần 10 pps

here is the default contents (it's seems quite long, doesn't it?): ######################################################## # This was written and is maintained by: # Kirk Bauer <kirk@kaybee.org> # # Please send all comments, suggestions, bug reports, # etc, to kirk@kaybee.org. # ######################################################## # NOTE: # All these options are the defaults if you run logwatch with no # command−line arguments. You can override all of these on the # command−line. # You can put comments anywhere you want to. They are effective for the # rest of the line. # this is in the format of <name> = <value>. Whitespace at the beginning # and end of the lines is removed. Whitespace before and after the = sign # is removed. Everything is case *insensitive*. # Yes = True = On = 1 # No = False = Off = 0 # Default Log Directory # All log−files are assumed to be given relative to this directory. # This should be /var/log on just about all systems LogDir = /var/log # Default person to mail reports to. Can be a local account or a # complete email address. MailTo = root # If set to 'Yes', the report will be sent to stdout instead of being # mailed to above person. Print = No # if set, the results will be saved in <filename> instead of mailed # or displayed. #Save = /tmp/logwatch # Use archives? If set to 'Yes', the archives of logfiles # (i.e. /var/log/messages.1 or /var/log/messages.1.gz) will # be searched in addition to the /var/log/messages file. # This usually will not do much if your range is set to just # 'Yesterday' or 'Today' it is probably best used with # Archives = Yes # Range = All # The default time range for the report # The current choices are All, Today, Yesterday Range = yesterday # The default detail level for the report. # This can either be Low, Med, High or a number. # Low = 0 # Med = 5 # High = 10 Detail = Low Monitoring Security 407 # The 'Service' option expects either the name of a filter # (in /etc/log.d/scripts/services/*) or 'All'. # The default service(s) to report on. This should be left as All for # most people. Service = All # If you only cared about FTP messages, you could use these 2 lines # instead of the above: #Service = ftpd−messages # Processes ftpd messages in /var/log/messages #Service = ftpd−xferlog # Processes ftpd messages in /var/log/xferlog # Maybe you only wanted reports on PAM messages, then you would use: #Service = pam_pwdb # PAM_pwdb messages − usually quite a bit #Service = pam # General PAM messages usually not many # You can also choose to use the 'LogFile' option. This will cause # logwatch to only analyze that one logfile for example: #LogFile = messages # will process /var/log/messages. This will run all the filters that # process that logfile. This option is probably not too useful to # most people. Setting 'Service' to 'All' above analyizes all LogFiles # anyways As we read through the file, we see that most of the lines are comments (since they start with the # sign, and that's a widely used way of introducing comments in most script and configuration files). So, out of all those lines, the only entries that are in effect are: LogDir = /var/log MailTo = root Print = No Range = yesterday Detail = Low These are highlighted in bold in the example. If we consult the man page for logwatch (run the command man logwatch), we can see that logwatch will check the log files in /var/log, looking for entries from the previous day, and e−mail a report containing a low level of detail to root. If we've run our system for a few days and checked root mail, we'll have seen messages from logwatch, so how is this happening? Scheduling of unattended jobs on Red Hat Linux 9, and most other Unix flavors, is handled by the cron daemon. This daemon looks for files containing information about what to run and when to run it in the directories /var/spool/cron and /etc/cron.d, and in the file /etc/crontab. On Red Hat Linux 9, the /etc/crontab file is the one that is configured by default. If we examine the contents of this file, we see that there are a few lines of environment information, and some other lines starting with numbers: SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run−parts 01 * * * * root run−parts /etc/cron.hourly 02 4 * * * root run−parts /etc/cron.daily 22 4 * * 0 root run−parts /etc/cron.weekly 42 4 1 * * root run−parts /etc/cron.monthly Monitoring Security 408 The numbers specify when cron should run the command described by the rest of the line. There are five fields which are, from left to right, minute, hour, day of month, month, and day of week. Where an asterisk is used, this means "I don't care". So the four scheduled jobs in the default Red Hat Linux 9 crontab are run at the following times: Scheduled Time Interpretation 01 * * * * 01 minutes past each hour 02 4 * * * 04:02 every day 22 4 * * 0 04:22 every Sunday (1=Monday, 2=Tuesday, etc., Sunday=0 or 7) 42 4 1 * * 04:42 on the 1 st day of every month The jobs are essentially similar; run the run−parts script as root and pass the name of a directory (e.g. /etc/cron. hourly for the job run at 1 minute past each hour). The run−parts script simply runs every executable file it finds in the directory that it is given (except files ending in the characters ~ or ,, and a few other exceptions). If we look in the /etc/cron. daily directory, we'll see a file called 00−logwatch, which is a symbolic link to the logwatch command. All this means that, at 04:02 every day, the root user will be mailed a message containing summaries of important information entered into various log files in /var/log the previous day. This is all set up for us when Red Hat Linux is installed, but now we know how it works, we can adjust the configuration to suit. If, for example, we'd like more information in the messages, we can simply edit /etc/log.d/logwatch.conf and change the Detail = Low line to Detail = High. Maybe we'd like the message to be sent at a different time, say 00:15. Easy −just delete the file 00−logwatch from /etc/cron.daily (so the 04:02 daily cron job no longer runs) and add the following line to /etc/crontab: 15 00 * * * root /usr/sbin/logwatch It's as simple as that. System Integrity Once a hacker has gained access to a system, they will often want to install modified versions of system files to ensure their continued access and to gather more information that will help them achieve their objectives. If our security analysis has identified this threat as one we need to consider, we need to have some means of identifying when our system may have been compromised in this way, so we can take remedial action (restore the compromised file from a trusted backup). But if we're checking the system for modified files, we'll not only identify files modified by intruders, we'll also identify files that may have been inadvertently modified by authorized individuals, or that have become corrupt due to hardware problems (e.g. bad blocks appearing on disk drives). Enter tripwire Tripwire Tripwire is an Open Source system integrity checker that is available for Red Hat Linux. It is a useful weapon in the system administrator's armory, so this section will take you through obtaining it and setting it up. Note that when Tripwire scans the system to detect changes, it's doing a lot of work and will hit the processor(s) and file I/O hard. System Integrity 409 Try it Out: Downloading, Configuring, and Running Tripwire 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. 1. 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). 2. 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♦ 3. 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. 4. The algorithm we need to employ is straightforward. If we find a line that looks like an instruction to5. System Integrity 410 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. 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 = <STDIN>) { # 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) 6. System Integrity 411 print $line; } # Print the statistics on STDERR, so they won't get redirected by > print STDERR "Number of additions: $Additions\n"; print STDERR "Number of removals: $Removals\n"; 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 7. 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.orig \ >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 8. 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) ; 9. 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 10. System Integrity 412 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. 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. 11. System Integrity 413 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. System Integrity 414 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 Network Services 415 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 Network Services 416 [...]... 0x0000 4500 00 29 4c7b 4000 8006 18 49 0a04 0x0 010 0a04 4102 0d07 0017 24e6 746f f267 0x0020 5018 21a8 97 36 0000 7220 2020 2020 12:12:03.423232 bob.telnet > fred.3335: tcp 0x0000 4 510 0028 9d53 4000 4006 0762 0a04 0x0 010 0a04 4101 0017 0d07 f267 5606 24e6 0x0020 5 010 16d0 1417 0000 6465 6420 4861 12:12:03.555 199 fred.3335 > bob.telnet: tcp 0x0000 4500 00 29 4d7b 4000 8006 17 49 0a04 0x0 010 0a04 4102 0d07 0017... 0x0020 5 010 21a8 094 1 0000 2020 2020 2020 12:12:03.18 091 9 fred.3335 > bob.telnet: tcp 0x0000 4500 00 29 4b7b 4000 8006 194 9 0a04 0x0 010 0a04 4102 0d07 0017 24e6 746e f267 0x0020 5018 21a8 a337 0000 6620 2020 2020 12:12:03.218203 bob.telnet > fred.3335: tcp 0x0000 4 510 0028 9d52 4000 4006 0763 0a04 0x0 010 0a04 4101 0017 0d07 f267 5606 24e6 0x0020 5 010 16d0 1418 0000 65fd 01ff fb05 12:12:03.423073 fred.3335... bob.telnet > fred.3335: tcp 0x0000 4 510 0028 9d54 4000 4006 0761 0a04 0x0 010 0a04 4101 0017 0d07 f267 5606 24e6 422 10 (DF) [tos 0x10] 4102 E 2.Q@.@ Z A 746e A gU.$.tn 7264 P ,H Password 0 (DF) 4101 E (J{@ J A 5606 A $.tn.gV P.! A 1 (DF) 4101 E )K{@ I A 5606 A $.tn.gV P.! 7 f 0 (DF) [tos 0x10] 4102 E (.R@.@ c A 746f A gV.$.to P .e 1 (DF) 4101 E )L{@ I A 5606 A $.to.gV P.! 6 r 0 (DF) [tos 0x10] 4102 E... .ded.Ha 1 (DF) 4101 E )M{@ I A 5606 A $.tp.gV P.! 5 e 0 (DF) [tos 0x10] 4102 E (.T@.@ a A 7471 A gV.$.tq Network Services 0x0020 5 010 16d0 1416 0000 0d0a 08 69 6e3a P in: 12:12:03. 699 442 fred.3335 > bob.telnet: tcp 1 (DF) 0x0000 4500 00 29 4e7b 4000 8006 16 49 0a04 4101 E )N{@ I A 0x0 010 0a04 4102 0d07 0017 24e6 7471 f267 5606 A $.tq.gV 0x0020 5018 21a8 a534 0000 6420 2020 2020 P.! 4 d This is what we mean... an update to a Red Hat supplied RPM that you've just installed As well as the Red Hat Network, there are many Web sites offering useful security information Here are just a few of them Red Hat Errata Web Site Red Hat provides another Web site that you can use to check out security related fixes for the packages that you have installed The URL for this site is http://www.redhat.com/apps/support/errata/... that you don't own!) Our theoretical test setup is this There are three machines, all connected to a 10/ 100 Ethernet hub, and all on a private subnet 192 .168.1/24 (that's shorthand for a subnet 192 .168.1.0 with a netmask of 255.255.255.0, i.e 24 bits) Fred ( 192 .168.1.l) is a Windows machine that we'll use as a telnet client, Bob ( 192 .168.1.2) is a Linux server we'll be telnetting in to, and Kate ( 192 .168.1.3)... don't need that much help − they'll probably use an automated password sniffer that'll decode the packets for them: 12:12:02.265222 bob.telnet > fred.3335: tcp 0x0000 4 510 0032 9d51 4000 4006 075a 0a04 0x0 010 0a04 4101 0017 0d07 f267 55fc 24e6 0x0020 5018 16d0 2c48 0000 5061 7373 776f 0x0030 3a20 12:12:02.465557 fred.3335 > bob.telnet: tcp 0x0000 4500 0028 4a7b 4000 8006 1a4a 0a04 0x0 010 0a04 4102 0d07... 0x0 010 0a04 4102 0d07 0017 24e6 74 19 0000 0000 A $.t 0x0020 7002 2000 26f7 0000 0204 05b4 0101 0402 p & 12:11:51.070826 bob.telnet > fred.3335: tcp 0 (DF) 0x0000 4500 0030 0000 4000 4006 a4bd 0a04 4102 E 0 @.@ A 0x0 010 0a04 4101 0017 0d07 f267 5575 24e6 741a A gUu$.t 0x0020 7012 16d0 e838 0000 0204 05b4 0101 0402 p 8 If we look carefully at the packet log, we can find the Password prompt and see what... questions on how to connect your Linux box to cable modem or cable Internet provider Diskless Describes how to set up a diskless Linux box Infrared Provides an introduction to Linux and infrared devices, and how to use the software provided by the Linux/ IrDA project KickStart Briefly describes how to use the RedHat Linux KickStart system to rapidly install large numbers of identical Linux boxes Software−RAID... issues surrounding their Red Hat Linux systems There are also lots of good Linux HOWTOs that cover security related topics Check out the Security−HOWTO and Firewall−HOWTO, for starters Summary Security is largely a matter of common sense Different people value different things, so there is no one security configuration that will be exactly suited to everyone However, Red Hat Linux does a pretty good . 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. 0000 2020 2020 2020 P.! A 12:12:03.18 091 9 fred.3335 > bob.telnet: tcp 1 (DF) 0x0000 4500 00 29 4b7b 4000 8006 194 9 0a04 4101 E )K{@ I A. 0x0 010 0a04 4102 0d07 0017 24e6 746e f267 5606 A $.tn.gV. . 5 010 16d0 1416 0000 0d0a 08 69 6e3a P in: 12:12:03. 699 442 fred.3335 > bob.telnet: tcp 1 (DF) 0x0000 4500 00 29 4e7b 4000 8006 16 49 0a04 4101 E )N{@ I A. 0x0 010 0a04 4102 0d07 0017 24e6 7471 f267