Below is the press release from RedHat
F13 Alpha release announcement
From FedoraProject
Jump to: navigation, search
The Fedora 13 "Goddard" Alpha release is available! What's next for the free operating system that shows off the best new technology of tomorrow? You can see the future now at:
http://fedoraproject.org/get-prerelease
What is the Alpha release?
The Alpha release contains all the features of Fedora 13 in a form that anyone can help test. This testing, guided by the Fedora QA team, helps us target and identify bugs. When these bugs are fixed, we make a Beta release available. A Beta release is code-complete, and bears a very strong resemblance to the third and final release. The final release of Fedora 13 is due in May.
We need your help to make Fedora 13 the best release yet, so please take a moment of your time to download and try out the Alpha and make sure the things that are important to you are working. If you find a bug, please report it -- every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora a rock-solid distribution. (Read down to the end of the announcement for more information on how to help.)
Features
Among the top features for end users, we have:
* Automatic print driver installation. We're using RPM and PackageKit for automatic installation of printer drivers, so when you plug in a USB printer, Fedora will automatically offer to install drivers for it if needed.
* Automatic installation of language packs. Yum language packs plugin support makes software installation smarter and easier for everyone worldwide, by automatically downloading language support for large suites of Fedora software when the user's environment requires it.
* Redesigned user management interface. The user account tool has been completely redesigned, and the accountsdialog and accountsservice test packages are available to make it easy to configure personal information, make a personal profile picture or icon, generate a strong passphrase, and set up login options for your Fedora system.
* Color management. Color Management allows you to better set and control your colors for displays, printers, and scanners, through the gnome-color-manager package.
* NetworkManager improvements include CLI. NetworkManager is now a one stop shop for all of your networking needs in Fedora, be it dial-up, broadband, wifi, or even Bluetooth. And now it can all be done in the command line, if you're into that sort of thing.
* Experimental 3D extended to free Nouveau driver for NVidia cards. In this release we are one step closer to having 3D supported on completely free and open source software (FOSS) drivers. In Fedora 12 we got a lot of ATI chips working, and this time we've added a wide range of NVidia cards. You can install the mesa-dri-drivers-experimental package to try out the work in progress.
For developers there are all sorts of additional goodies:
* SystemTap static probes. SystemTap now has expanded capabilities to monitor higher-level language runtimes like Java, Python and Tcl, and also user space applications starting with PostgreSQL. In the future Fedora will add support for even more user space applications, greatly increasing the scope and power of monitoring for application developers.
* Easier Python debugging. We've added new support that allows developers working with mixed libraries (Python and C/C++) in Fedora to get more complete information when debugging with gdb, making Fedora an exceptional platform for powerful, rapid application development.
* Parallel-installable Python 3 stack. The parallel-installable Python 3 stack will will help programmers write and test code for use in both Python 2.6 and Python 3 environments, so you can future-proof your applications now using Fedora.
* NetBeans 6.8 first IDE to support entire Java 6 EE spec. NetBeans IDE 6.8 is the first IDE to offer complete support for the entire Java EE 6 specification.
And don't think we forgot the system administrators:
* boot.fedoraproject.org. (BFO) allows users to download a single, tiny image (could fit on a floppy) and install current and future versions of Fedora without having to download additional images.
* System Security Services Daemon (SSSD). SSSD provides expanded features for logging into managed domains, including caching for offline authentication. This means that, for example, users on laptops can still login when disconnected from the company's managed network. The authentication configuration tool in Fedora has already been updated to support SSSD, and work is underway to make it even more attractive and functional.
* Pioneering NFS features. Fedora offers the latest version 4 of the NFS protocol for better performance, and in conjunction with recent kernel modifications includes IPv6 support for NFS as well.
* Zarafa Groupware. Zarafa now makes available a complete Open Source groupware suite that can be used as a drop-in Exchange replacement for Web-based mail, calendaring, collaboration and tasks. Features include IMAP/POP and iCal/CalDAV capabilities, native mobile phone support, the ability to integrate with existing Linux mail servers, a full set of programming interfaces, and a comfortable look and feel using modern Ajax technologies.
* Btrfs snapshots integration. Btrfs is capable of creating lightweight filesystem snapshots that can be mounted (and booted into) selectively. The created snapshots are copy-on-write snapshots, so there is no file duplication overhead involved for files that do not change between snapshots. It allows developers to feel comfortable experimenting with new software without fear of an unusable install, since automated snapshots allow them to easily revert to the previous day's filesystem.
And that's only the beginning. A more complete list and details of each new cited feature is available here:
http://fedoraproject.org/wiki/Releases/13/FeatureList
We have nightly composes of alternate spins available here:
http://alt.fedoraproject.org/pub/alt/nightly-composes/
Friday, March 12, 2010
Tutorial - Disable unused Daemons
The article below is a tutorial from "Linux Tutorial Blog" on speeding up your boot sequence by disabling unused daemons however the same methodology can improve your security footing by removing potential security vulnerabilities that just don't need to run in the first place.
Full Article Here
Full Article Here
Thursday, March 11, 2010
Backtrack 4 is out
I've been using this for 3 weeks now and entirely forgot to mention it here.
Backtrack 4 shipped in late January - Get the download here
BackTrack is intended for all audiences from the most savvy security professionals to early newcomers to the information security field. BackTrack promotes a quick and easy way to find and update the largest database of security tool collection to-date.
Our community of users range from skilled penetration testers in the information security field, government entities, information technology, security enthusiasts, and individuals new to the security community. Feedback from all industries and skill levels allows us to truly develop a solution that is tailored towards everyone and far exceeds anything ever developed both commercially and freely available.
Whether you’re hacking wireless, exploiting servers, performing a web application assessment, learning, or social-engineering a client, BackTrack is the one-stop-shop for all of your security needs.
Backtrack 4 shipped in late January - Get the download here
BackTrack is intended for all audiences from the most savvy security professionals to early newcomers to the information security field. BackTrack promotes a quick and easy way to find and update the largest database of security tool collection to-date.
Our community of users range from skilled penetration testers in the information security field, government entities, information technology, security enthusiasts, and individuals new to the security community. Feedback from all industries and skill levels allows us to truly develop a solution that is tailored towards everyone and far exceeds anything ever developed both commercially and freely available.
Whether you’re hacking wireless, exploiting servers, performing a web application assessment, learning, or social-engineering a client, BackTrack is the one-stop-shop for all of your security needs.
OpenSuSE 11.3 milestone 3 released
OpenSUSE 11.3 milestone 3 release is the first distro compiled entirely with the GNU Compiler Collection (GCC) version 4.5. The update caused a couple of problems with the openSUSE Build Service and packages that wouldn't compile. The openSUSE project management decided to release nevertheless, specifically to test and make improvements to the new GCC 4.5 upgrade. Milestone 3, therefore, is an actual alpha release to be addressed only by experienced Linux users.
Among the new features are Kernel 2.6.33, the Nouveau drivers for NVIDIA graphics cards and the current GNOME developer version 2.29, including the GNOME shell.
The following bugs are in a known state:
* YaST log files are truncated.
* Network installations choke on the wrong SHA1sum for cracklib-dict-full.
* VirtualBox is uninstallable.
* With the LXDE desktop, rcxdm fails to stop the lxdm login manager.
A glance at the Most Annoying Bugs site might be appropriate before installing 11.3. The list may indeed get longer in the next few days. Download here
Among the new features are Kernel 2.6.33, the Nouveau drivers for NVIDIA graphics cards and the current GNOME developer version 2.29, including the GNOME shell.
The following bugs are in a known state:
* YaST log files are truncated.
* Network installations choke on the wrong SHA1sum for cracklib-dict-full.
* VirtualBox is uninstallable.
* With the LXDE desktop, rcxdm fails to stop the lxdm login manager.
A glance at the Most Annoying Bugs site might be appropriate before installing 11.3. The list may indeed get longer in the next few days. Download here
SCO v. Novell Trial
For those interested in following the developments in the SCO vs. Novell trial you can find detailed observers notes at the links below. Note that this summary comes mostly from the excellent trial coverage from GROKLAW.NET
Day 1 - Monday March 8, 2010 Day 1 is mostly just the seating of the Jury.
Day 2 - Tuesday March 9, 2010 Day 2 included the opening arguments of both sides and the testimony of Bob Frankenberg, Former CEO of Novell.
Day 3 - Wednesday March 10, 2010 Testimony of Duff Thompson and Ed Chatlos
Day 4 - Thursday March 11, 2010 Most of the day was filled with video depositions by Jack Messman; Former CEO of Novell, Burt Levine a lawyer that came from USL, then worked for Novell and later Santa Cruz. Jim Wilt's depostion which was not heard by the jury; Alek Mohan; CEO of SCO from 1995-1998; and finally live deposition by Bill Broderick, another lawyer that worked for USL and then Novell;
Motion Filed by Novell - Friday March 12, 2010 This motion is to allow Novell to introduce into evidence the prior findings of the court that declares that Novell is in fact the owner of the copyrights and that they did not transfer with the sale. That motion is based on SCO's lawyers making the claim (at least 4 times) that Novell continued to slander SCO's title "to this very day".
Day 5 - Friday March 12, 2010 Continuation of testimony of Bill Broderick and Testimony of Ty Mattingly; Mattingly described himself as the "High Level Business Negotiator" for Novell during the sale of Unix/Unixware to Santa Cruz.
Novell Files a "Petition for Writ of Certiorari" - Review of Ruling to Supreme Court over the 10th Circuit that handed over copyrights to SCO that were not specifically transferred as part of the sale of Unix/Unixware. See the filing here
DAY 6 -
Motion for mistrial; Testimony of Kim Madsen, Steve Sabbath and Darl McBride
Judge Denies 2 Novell Motions, 1 for mistrial and the other to allow evidence on prior judicial opinions in the case.
Novell has filed a Notice of Filing of Offer of Proof Regarding Prior Inconsistent Declaration of Steven Sabbath. It is making a record that SCO was allowed to present testimony in direct examination that Novell knew was contradicted by deposition testimony, but then Novell couldn't tell the jury about it, because of rulings by the judge.
Day 7 -
Testimony of Darl McBride and Christine Botosan
Novell anticipates objections to SCO's Experts' testimony regarding the 'TK-7 v Estate of Barbouti' case -
SCO's motion to allow testimony regardi8ng a previous case and a letter from Brent Hatch. -
Day 8 -
Continued testimony of Darl McBride - McBride admits on stand that SCO did not need the copyrights to run their Unix business and that they only needed them for SCOSource. Also admitted into evidence was an exhibit showing that HP did not take a SCOSource license in part because they equated it with "supporting terrorism"
New Proposed Jury Instructions and Novell Tries again to get prior court rulings admitted as evidence -
Day 9 -
Jury hears about Kimball's Rulings and Botosan
Day 10 -
Testimony of Chris Stone, O'Gara, Maciaszek, Nagle -
APA's "Included Assets" did not list SVR4.2 - Research Project -
Novell says "elliott Offer" "Inadequate".. -
Day 1 - Monday March 8, 2010 Day 1 is mostly just the seating of the Jury.
Day 2 - Tuesday March 9, 2010 Day 2 included the opening arguments of both sides and the testimony of Bob Frankenberg, Former CEO of Novell.
Day 3 - Wednesday March 10, 2010 Testimony of Duff Thompson and Ed Chatlos
Day 4 - Thursday March 11, 2010 Most of the day was filled with video depositions by Jack Messman; Former CEO of Novell, Burt Levine a lawyer that came from USL, then worked for Novell and later Santa Cruz. Jim Wilt's depostion which was not heard by the jury; Alek Mohan; CEO of SCO from 1995-1998; and finally live deposition by Bill Broderick, another lawyer that worked for USL and then Novell;
Motion Filed by Novell - Friday March 12, 2010 This motion is to allow Novell to introduce into evidence the prior findings of the court that declares that Novell is in fact the owner of the copyrights and that they did not transfer with the sale. That motion is based on SCO's lawyers making the claim (at least 4 times) that Novell continued to slander SCO's title "to this very day".
Day 5 - Friday March 12, 2010 Continuation of testimony of Bill Broderick and Testimony of Ty Mattingly; Mattingly described himself as the "High Level Business Negotiator" for Novell during the sale of Unix/Unixware to Santa Cruz.
Novell Files a "Petition for Writ of Certiorari" - Review of Ruling to Supreme Court over the 10th Circuit that handed over copyrights to SCO that were not specifically transferred as part of the sale of Unix/Unixware. See the filing here
DAY 6 -
Motion for mistrial; Testimony of Kim Madsen, Steve Sabbath and Darl McBride
Judge Denies 2 Novell Motions, 1 for mistrial and the other to allow evidence on prior judicial opinions in the case.
Novell has filed a Notice of Filing of Offer of Proof Regarding Prior Inconsistent Declaration of Steven Sabbath. It is making a record that SCO was allowed to present testimony in direct examination that Novell knew was contradicted by deposition testimony, but then Novell couldn't tell the jury about it, because of rulings by the judge.
Day 7 -
Testimony of Darl McBride and Christine Botosan
Novell anticipates objections to SCO's Experts' testimony regarding the 'TK-7 v Estate of Barbouti' case -
SCO's motion to allow testimony regardi8ng a previous case and a letter from Brent Hatch. -
Day 8 -
Continued testimony of Darl McBride - McBride admits on stand that SCO did not need the copyrights to run their Unix business and that they only needed them for SCOSource. Also admitted into evidence was an exhibit showing that HP did not take a SCOSource license in part because they equated it with "supporting terrorism"
New Proposed Jury Instructions and Novell Tries again to get prior court rulings admitted as evidence -
Day 9 -
Jury hears about Kimball's Rulings and Botosan
Day 10 -
Testimony of Chris Stone, O'Gara, Maciaszek, Nagle -
APA's "Included Assets" did not list SVR4.2 - Research Project -
Novell says "elliott Offer" "Inadequate".. -
Auditing Linux Servers Checklist
This checklist is to be used to audit a Linux environment. This checklist attempts to provide a generic set of controls to consider when auditing a Linux environment. It does not account for the differences between the different Linux distributions on the market (e.g. Red Hat, Caldera, Mandrake, etc.).
Some of the elements to consider prior to using this checklist:
· Utilities: While every attempt has been made to include the security implications of using various utilities, it is not possible to list all of them and their security implications in this checklist. Thus, the auditor should ascertain what utilities are being used on the intended Linux server to be reviewed and determine their security implications. A good source to ascertain security implications of using certain utilities is to review the website of the vendor supplying the utility, whether it be freeware, shareware, or commercial products. Another source is the supporting documentation that accompanies the utilities.
· Practicality of the checklist: This checklist lists controls to be checked for a very secure configuration. These may not be appropriate for all Linux servers in an organization due to the risk assigned to particular data and applications. Also, some of the controls may be cost prohibitive to implement and management may have during the accreditation process decided to accept the risk of not being totally secure. The cost may relate to monetary and non-monetary elements. Non-monetary elements include items such as response times and availability.
· Interoperability with other products: This checklist does not provide the security issues to be considered when another system performs certain operations (e.g. Windows NT providing the network authentication service). However, it is quite important that the auditor take this into consideration as certain systems coupled with a Linux server may introduce new vulnerabilities e.g. Netware is unsecure when mounting file systems. Also, this may aid the auditor in tailoring the checklist to suit the organizations environment (e.g. more focus on the Samba server/SMB and less attention to Linux authentication if NT provides the network authentication service).
· Mitigating controls: The auditor needs to be aware of other controls provided by applications or databases. It may be that a weakness identified in the operating system is mitigated by a strong control found in the application or the database e.g. weak access control for the Linux operating system may be mitigated by very granular access control for the application.
· Significance of findings: To produce a good report that will receive management attention the auditor needs to perform a mini risk analysis. The risk analysis would ascertain if the finding is so significant as to affect the organization adversely. The first step in the risk analysis is to determine how sensitive the data stored on the server is and how critical the server is in the business operations. The second step is to determine how the finding would affect the organization’s ability to maintain confidentiality, integrity and availability. Once this has been done, a report indicating the priority and the potential effect on the organization if the weakness is not corrected in a timely manner needs to be issued to management.
· Applications and Database interfaces with Linux: A further consideration is the security provided for application and database files by the Linux server. The auditor needs to ascertain what applications and databases are loaded on the Linux server and ascertain the appropriateness of the permissions assigned to these files. This would also apply to sensitive data files.
An important consideration prior to auditing a Linux server is to determine the Linux server’s function in the organization. This is paramount to determining how the checklist below may be tailored. Since it is outside the scope of this checklist to list the security considerations in all the different functional instances that a Linux server may be used (e.g. as an HTTP server); it is important for the auditor to determine the security elements to be considered for a function as well as the associated applications that may be run for a specific function (e.g. running Apache on an HTTP server).
1 Installation:
Ensure that the software is downloaded from secure sites. Ascertain if the PGP or MD- 5 signatures are verified.
Ensure that a process exists to ascertain the function of the server and thus to install only those packages that are of relevance to the function.
Ensure that the partition sizes are based on the function of the server (e.g. A news server requires sufficient space on the /var/spool/news partition.)
Ensure that the partition scheme is documented to allow recovery later.
2 Ensure that there is a process to update the system with the latest patches.
If the patches are downloaded, ensure that they are downloaded from secure sites.
Ensure that the patches are tested in a test environment prior to being rolled-out to the live environment.
If RPM is being used to automatically download the related packages, ensure that the sites listed in /etc/autorpm.d/pools/redhat-updates are secure, trusted sites.
3 Ensure that SSH is in use.
Ensure that during the installation of SSH, the SSH daemon has been configured to support TCP Wrappers and disable support for rsh as a fallback option.
Ensure that the SSH daemon is started at boot time by reviewing the /etc/rc.d/rc.local file for the following entry: /usr/local/sbin/sshd.
Ensure that the /etc/hosts.allow file is set up for SSh access.
Ensure that the .ssh/identity file has 600 permissions and is owned by root.
Ensure that the r programs are commented out of /etc/inetd.conf and have been removed.
4 Ensure that the inetd.conf file has been secured with the removal of unnecessary services. This is dependant on the function of the Linux server in the environment.
sadmind
login
finger
chargen
echo
time
daytime
discard
The following should be commented out:
ftp
tftp ftp
tftp
systat
rexd
ypupdated
netstat
rstatd
sadmind
login
finger
chargen
echo
time
daytime
discard
rusersd
sprayd
walld
exec
talk
comsat
rquotad
name
uucp
Ensure that the r programs have been commented out from the inetd.conf file due to the numerous vulnerabilities in these programs.
Ensure that there are no /etc/hosts.equiv file and that no user account has a .rhosts file in its home directory.
5 Ensure that Tripwire (or some other method of monitoring for modification of critical system files) is in use.
Ensure that one copy of the Tripwire database is copied onto a write protected floppy or CD.
Ascertain how often a Tripwire compare is done. Determine what corrective actions are taken if there are variances (i.e. changed files).
Ensure that Tripwire sends alerts to the appropriate system administrator if a modification has occurred.
If selective monitoring is enabled ascertain that the files being monitored are those that maintain sensitive information.
6 Vulnerability scans:
Ascertain how often vulnerability scans are run and what corrective action is taken if security weaknesses are detected.
If using Tiger, review /usr/local/tiger/systems/Linux/2 to ascertain whether the base information used for comparison is plausible.
If using TARA, review the tigerrc file to ensure that suitable system checks are enabled.
Other tools that can be used for vulnerability scans are SATAN, SARA, SAINT. Ensure that the latest versions of these scanners are being used.
Commercial products like ISS system scanner or internet scanner as well as Cybercop may be used as vulnerability scanners.
7 Ensure that Shadow passwords with MD5 hashing are enabled.
8 Ensure that a boot disk has been created to recover from emergencies.
Ensure that appropriate baselines are created for directory structures, file permissions, filenames and sizes. These files should be stored on CD’s.
9 Review the /etc/lilo.conf file to ensure that the LILO prompt has been password protected and that permissions have been changed to 600.
10 Logging:
Review the /etc/syslog.comf file to ascertain if warnings and errors on all facilities are being logged and that all priorities on the kernel facility are being logged.
Ensure that the permissions on the syslog files are 700.
Review the /etc/logrotate.conf file to ascertain if the logs are rotated in compliance with security policy.
Review the crontab file to ascertain if the logrotate is scheduled daily.
If remote logging is enabled ensure that the correct host is included in the /etc/syslog.conf file and that the system clock is synchronised with the logserver. To check the synchronization of the system clock review the /etc/cron.hourly/set-ntp file and ensure that the hardware clock CMOS value is set to the current system time.
Ensure that the log entries are reviewed regularly either manually or using tools like Swatch or Logcheck.
If Swatch is used, review the /urs/doc/swatch-2.2/config_files/swatchrc.personal control file to ensure that all different log files are being monitored (mail logs, samba logs, etc) and that the expressions to ignore are plausible.
If using Logcheck, review the logcheck.ignore files to ensure that the patterns to ignore are plausible.
11 Review /etc/inittab file to ascertain if:
Rebooting from the console with Ctrl+Alt+Del key sequence is disabled
Root password is required to enter single user mode
12 Review the /etc/ftpusers file to ensure that root and system accounts are included.
13 Review the /etc/security/access.conf file to ensure that all console logins except for root and administrator are disabled.
14 TCP Wrappers
Ensure that the default access rule is set to deny all in the /etc/hosts.allow file.
Determine if a procedure exists to run tcpdchk after rule changes.
Run tcpdchk to ensure that the syntax of /etc/inetd.conf file are consistent and that there are no errors.
Review the /etc/banners file to ensure that the appropriate legal notice has been included in the banner.
Review the /etc/hosts.allow file to ensure that the banners have been activated.
15 Startup/shutdown scripts
Ascertain if there is a process to ascertain which process is listening on which port (either lsof or nertstat command) and whether any unnecessary services are eliminated.
Review the /etc/rc.d/init.d file to ensure that only the necessary services based on the function of the server are being run.
The services to be stopped are as follows (this is dependant on the server function):
automounter /etc/rc2.d/S74autofs
Sendmail /etc/rc2.d/S88sendmail and /etc/rc1.d/K57sendamil
RPC /etc/rc2.d/ S71rpc
SNMP /etc/rc2.d/S76snmpdx
NFS server /etc/rc3.d/S15nfs.server
NFS client /etc/rc2/S73nfs.client
16 Domain Name Service
For the master server ensure that zone transfers are restricted by reviewing the /etc/named.conf file. The IP address of the masters should appear next to the allow-transfer option.
For slave/secondary servers ensure that the no zone information is transferred to any other server – review the /etc/named.conf file for the slaves. None should appear next to the allow-transfer option.
Ensure that named is run in chroot jail.
Ensure that syslogd is set to listen to named logging by reviewing the /etc/rc.d/init.d/syslog to ensure that the line referring to the syslog daemon has been edited to read as follows:
daemon syslog –a /home/dns/dev/log.
17 E-Mail
Ensure that the SMTP vrfy and expn have been turned off by reviewing the /etc/sendmail.cf file. (PrivacyOptions = goaway).
Review the /etc/mail/access file to ensure that it includes only the fully qualified hostname, subdomain, domain or network names/addresses that are authorized to relay mail.
Ensure that domain name masquerading has been set by reviewing the /etc/sendmail.cf file. The masquerade name should be appended to the DM line.
Ensure that the latest patches of POP/IMAP are installed on the mail server.
Review the /etc/hosts.allow file to ensure that mail is only delivered to the authorized network and domain. The network and domain name should appear after the ipop3d and imapd lines.
Ensure that SSL wrap1er has been installed for secure POP/IMAP connections.
18 Printing Services
Review the /etc/hosts.lpd file to ensure that only authorized hosts are allowed to use the print server.
If LPRng is used, review the /etc/lpd.perms file to ensure that only authorized hosts or networks are allowed access to the print server and to perform specific operations.
19 NFS
Ensure that only authorized hosts are allowed access to RPC services by reviewing the /etc/hosts.allow file for entries after portmap.
Review the /etc/exports file and ascertain that directories are only exported to authorized hosts with read only option.
20 Server Message Block SMB/SAMBA server
Ensure that the latest version of SAMBA is being run.
Review the /etc/smb.conf file to ensure that only authorized hosts are allowed SAMBA server access.
Ensure that encrypted passwords are used.
Ensure that the permissions on the /etc/smbpasswd file is 600.
Review the /etc/smbpasswd file to ensure that system accounts have been removed (bin, daemon, ftp).
Review the /etc/smb.conf file to ensure that unnecessary shares are disabled.
Review the /etc/smb.conf file to ensure that write permissions have been restricted to authorized users.
Review the /etc/smb.conf file to ensure that the files are not created world readable. The create mask should have a permission bit of 770 and the directory mask should have a permission bit of 750.
21 Review the /etc/securetty file to ensure that remote users are not included (i.e. the file only contains tty1 to tty8, inclusive).
22 FTP:
Review /home/ftp, to ensure that the bin, etc and pub directories are owned by root.
Review the /etc/hosts.allow file to ensure that only authorized hosts are allowed access to the ftp server. Authorized hosts and networks should be found after the in.ftpd.
Review the /etc/ftpaccess file to ensure that anonymous users are prevented from modifying writable directories. The entries should be as follows:
chmod no guest,anonymous
delete no guest,anonymous
overwrite no guest,anonymous
rename no guest,anonymous
Review the /etc/ftpaccess file to ensure that files uploaded to the incoming directory has root as owner and the user is not allowed to create sub-directories. Ensure that downloads are denied from the incoming directory.
The lines should read as follows:
upload /home/ftp /incoming yes root nodirs
noretrieve /home/ftp/incoming/
Ensure that the incoming directory is reviewed daily and the files moved out of the anonymous directory tree.
23 Intrusion Detection:
Ensure that PortSentry is in use.
Review the portsentry.conf file and ensure that the KILL_ROUTE option is configured to either:
add an entry to in the routing table to send responses to the attacking host to a fictitious destination
add firewall filter rules to drop all packets from the attacking host
Ensure that LIDS (Linux Intrusion Detection/Defense System) is in use. Review lidsadm to ascertain what directories are being protected and the other security options that are enabled.
24 Ensure PAM is enabled.
25 HTTP Server
Ensure that the basic access is set to default deny by reviewing access.conf. The options should be set as follows:
Options None
AllowOverride None
Order deny,allow
Deny from all
Ensure that further entries to access.conf only allow access and specific options to authorized hosts based on their function.
Ensure that directories don’t have any of the following options set:
ExecCGI
FollowSymlINKS
Includes
Indexes
Ensure that password protection is used for sensitive data. However, the auditor must be aware that this security control is inadequate on its own since the userid and password are passed over the network in the clear.
Ensure that SSL is used for secure HTTP communications.
Some of the elements to consider prior to using this checklist:
· Utilities: While every attempt has been made to include the security implications of using various utilities, it is not possible to list all of them and their security implications in this checklist. Thus, the auditor should ascertain what utilities are being used on the intended Linux server to be reviewed and determine their security implications. A good source to ascertain security implications of using certain utilities is to review the website of the vendor supplying the utility, whether it be freeware, shareware, or commercial products. Another source is the supporting documentation that accompanies the utilities.
· Practicality of the checklist: This checklist lists controls to be checked for a very secure configuration. These may not be appropriate for all Linux servers in an organization due to the risk assigned to particular data and applications. Also, some of the controls may be cost prohibitive to implement and management may have during the accreditation process decided to accept the risk of not being totally secure. The cost may relate to monetary and non-monetary elements. Non-monetary elements include items such as response times and availability.
· Interoperability with other products: This checklist does not provide the security issues to be considered when another system performs certain operations (e.g. Windows NT providing the network authentication service). However, it is quite important that the auditor take this into consideration as certain systems coupled with a Linux server may introduce new vulnerabilities e.g. Netware is unsecure when mounting file systems. Also, this may aid the auditor in tailoring the checklist to suit the organizations environment (e.g. more focus on the Samba server/SMB and less attention to Linux authentication if NT provides the network authentication service).
· Mitigating controls: The auditor needs to be aware of other controls provided by applications or databases. It may be that a weakness identified in the operating system is mitigated by a strong control found in the application or the database e.g. weak access control for the Linux operating system may be mitigated by very granular access control for the application.
· Significance of findings: To produce a good report that will receive management attention the auditor needs to perform a mini risk analysis. The risk analysis would ascertain if the finding is so significant as to affect the organization adversely. The first step in the risk analysis is to determine how sensitive the data stored on the server is and how critical the server is in the business operations. The second step is to determine how the finding would affect the organization’s ability to maintain confidentiality, integrity and availability. Once this has been done, a report indicating the priority and the potential effect on the organization if the weakness is not corrected in a timely manner needs to be issued to management.
· Applications and Database interfaces with Linux: A further consideration is the security provided for application and database files by the Linux server. The auditor needs to ascertain what applications and databases are loaded on the Linux server and ascertain the appropriateness of the permissions assigned to these files. This would also apply to sensitive data files.
An important consideration prior to auditing a Linux server is to determine the Linux server’s function in the organization. This is paramount to determining how the checklist below may be tailored. Since it is outside the scope of this checklist to list the security considerations in all the different functional instances that a Linux server may be used (e.g. as an HTTP server); it is important for the auditor to determine the security elements to be considered for a function as well as the associated applications that may be run for a specific function (e.g. running Apache on an HTTP server).
1 Installation:
Ensure that the software is downloaded from secure sites. Ascertain if the PGP or MD- 5 signatures are verified.
Ensure that a process exists to ascertain the function of the server and thus to install only those packages that are of relevance to the function.
Ensure that the partition sizes are based on the function of the server (e.g. A news server requires sufficient space on the /var/spool/news partition.)
Ensure that the partition scheme is documented to allow recovery later.
2 Ensure that there is a process to update the system with the latest patches.
If the patches are downloaded, ensure that they are downloaded from secure sites.
Ensure that the patches are tested in a test environment prior to being rolled-out to the live environment.
If RPM is being used to automatically download the related packages, ensure that the sites listed in /etc/autorpm.d/pools/redhat-updates are secure, trusted sites.
3 Ensure that SSH is in use.
Ensure that during the installation of SSH, the SSH daemon has been configured to support TCP Wrappers and disable support for rsh as a fallback option.
Ensure that the SSH daemon is started at boot time by reviewing the /etc/rc.d/rc.local file for the following entry: /usr/local/sbin/sshd.
Ensure that the /etc/hosts.allow file is set up for SSh access.
Ensure that the .ssh/identity file has 600 permissions and is owned by root.
Ensure that the r programs are commented out of /etc/inetd.conf and have been removed.
4 Ensure that the inetd.conf file has been secured with the removal of unnecessary services. This is dependant on the function of the Linux server in the environment.
sadmind
login
finger
chargen
echo
time
daytime
discard
The following should be commented out:
ftp
tftp ftp
tftp
systat
rexd
ypupdated
netstat
rstatd
sadmind
login
finger
chargen
echo
time
daytime
discard
rusersd
sprayd
walld
exec
talk
comsat
rquotad
name
uucp
Ensure that the r programs have been commented out from the inetd.conf file due to the numerous vulnerabilities in these programs.
Ensure that there are no /etc/hosts.equiv file and that no user account has a .rhosts file in its home directory.
5 Ensure that Tripwire (or some other method of monitoring for modification of critical system files) is in use.
Ensure that one copy of the Tripwire database is copied onto a write protected floppy or CD.
Ascertain how often a Tripwire compare is done. Determine what corrective actions are taken if there are variances (i.e. changed files).
Ensure that Tripwire sends alerts to the appropriate system administrator if a modification has occurred.
If selective monitoring is enabled ascertain that the files being monitored are those that maintain sensitive information.
6 Vulnerability scans:
Ascertain how often vulnerability scans are run and what corrective action is taken if security weaknesses are detected.
If using Tiger, review /usr/local/tiger/systems/Linux/2 to ascertain whether the base information used for comparison is plausible.
If using TARA, review the tigerrc file to ensure that suitable system checks are enabled.
Other tools that can be used for vulnerability scans are SATAN, SARA, SAINT. Ensure that the latest versions of these scanners are being used.
Commercial products like ISS system scanner or internet scanner as well as Cybercop may be used as vulnerability scanners.
7 Ensure that Shadow passwords with MD5 hashing are enabled.
8 Ensure that a boot disk has been created to recover from emergencies.
Ensure that appropriate baselines are created for directory structures, file permissions, filenames and sizes. These files should be stored on CD’s.
9 Review the /etc/lilo.conf file to ensure that the LILO prompt has been password protected and that permissions have been changed to 600.
10 Logging:
Review the /etc/syslog.comf file to ascertain if warnings and errors on all facilities are being logged and that all priorities on the kernel facility are being logged.
Ensure that the permissions on the syslog files are 700.
Review the /etc/logrotate.conf file to ascertain if the logs are rotated in compliance with security policy.
Review the crontab file to ascertain if the logrotate is scheduled daily.
If remote logging is enabled ensure that the correct host is included in the /etc/syslog.conf file and that the system clock is synchronised with the logserver. To check the synchronization of the system clock review the /etc/cron.hourly/set-ntp file and ensure that the hardware clock CMOS value is set to the current system time.
Ensure that the log entries are reviewed regularly either manually or using tools like Swatch or Logcheck.
If Swatch is used, review the /urs/doc/swatch-2.2/config_files/swatchrc.personal control file to ensure that all different log files are being monitored (mail logs, samba logs, etc) and that the expressions to ignore are plausible.
If using Logcheck, review the logcheck.ignore files to ensure that the patterns to ignore are plausible.
11 Review /etc/inittab file to ascertain if:
Rebooting from the console with Ctrl+Alt+Del key sequence is disabled
Root password is required to enter single user mode
12 Review the /etc/ftpusers file to ensure that root and system accounts are included.
13 Review the /etc/security/access.conf file to ensure that all console logins except for root and administrator are disabled.
14 TCP Wrappers
Ensure that the default access rule is set to deny all in the /etc/hosts.allow file.
Determine if a procedure exists to run tcpdchk after rule changes.
Run tcpdchk to ensure that the syntax of /etc/inetd.conf file are consistent and that there are no errors.
Review the /etc/banners file to ensure that the appropriate legal notice has been included in the banner.
Review the /etc/hosts.allow file to ensure that the banners have been activated.
15 Startup/shutdown scripts
Ascertain if there is a process to ascertain which process is listening on which port (either lsof or nertstat command) and whether any unnecessary services are eliminated.
Review the /etc/rc.d/init.d file to ensure that only the necessary services based on the function of the server are being run.
The services to be stopped are as follows (this is dependant on the server function):
automounter /etc/rc2.d/S74autofs
Sendmail /etc/rc2.d/S88sendmail and /etc/rc1.d/K57sendamil
RPC /etc/rc2.d/ S71rpc
SNMP /etc/rc2.d/S76snmpdx
NFS server /etc/rc3.d/S15nfs.server
NFS client /etc/rc2/S73nfs.client
16 Domain Name Service
For the master server ensure that zone transfers are restricted by reviewing the /etc/named.conf file. The IP address of the masters should appear next to the allow-transfer option.
For slave/secondary servers ensure that the no zone information is transferred to any other server – review the /etc/named.conf file for the slaves. None should appear next to the allow-transfer option.
Ensure that named is run in chroot jail.
Ensure that syslogd is set to listen to named logging by reviewing the /etc/rc.d/init.d/syslog to ensure that the line referring to the syslog daemon has been edited to read as follows:
daemon syslog –a /home/dns/dev/log.
17 E-Mail
Ensure that the SMTP vrfy and expn have been turned off by reviewing the /etc/sendmail.cf file. (PrivacyOptions = goaway).
Review the /etc/mail/access file to ensure that it includes only the fully qualified hostname, subdomain, domain or network names/addresses that are authorized to relay mail.
Ensure that domain name masquerading has been set by reviewing the /etc/sendmail.cf file. The masquerade name should be appended to the DM line.
Ensure that the latest patches of POP/IMAP are installed on the mail server.
Review the /etc/hosts.allow file to ensure that mail is only delivered to the authorized network and domain. The network and domain name should appear after the ipop3d and imapd lines.
Ensure that SSL wrap1er has been installed for secure POP/IMAP connections.
18 Printing Services
Review the /etc/hosts.lpd file to ensure that only authorized hosts are allowed to use the print server.
If LPRng is used, review the /etc/lpd.perms file to ensure that only authorized hosts or networks are allowed access to the print server and to perform specific operations.
19 NFS
Ensure that only authorized hosts are allowed access to RPC services by reviewing the /etc/hosts.allow file for entries after portmap.
Review the /etc/exports file and ascertain that directories are only exported to authorized hosts with read only option.
20 Server Message Block SMB/SAMBA server
Ensure that the latest version of SAMBA is being run.
Review the /etc/smb.conf file to ensure that only authorized hosts are allowed SAMBA server access.
Ensure that encrypted passwords are used.
Ensure that the permissions on the /etc/smbpasswd file is 600.
Review the /etc/smbpasswd file to ensure that system accounts have been removed (bin, daemon, ftp).
Review the /etc/smb.conf file to ensure that unnecessary shares are disabled.
Review the /etc/smb.conf file to ensure that write permissions have been restricted to authorized users.
Review the /etc/smb.conf file to ensure that the files are not created world readable. The create mask should have a permission bit of 770 and the directory mask should have a permission bit of 750.
21 Review the /etc/securetty file to ensure that remote users are not included (i.e. the file only contains tty1 to tty8, inclusive).
22 FTP:
Review /home/ftp, to ensure that the bin, etc and pub directories are owned by root.
Review the /etc/hosts.allow file to ensure that only authorized hosts are allowed access to the ftp server. Authorized hosts and networks should be found after the in.ftpd.
Review the /etc/ftpaccess file to ensure that anonymous users are prevented from modifying writable directories. The entries should be as follows:
chmod no guest,anonymous
delete no guest,anonymous
overwrite no guest,anonymous
rename no guest,anonymous
Review the /etc/ftpaccess file to ensure that files uploaded to the incoming directory has root as owner and the user is not allowed to create sub-directories. Ensure that downloads are denied from the incoming directory.
The lines should read as follows:
upload /home/ftp /incoming yes root nodirs
noretrieve /home/ftp/incoming/
Ensure that the incoming directory is reviewed daily and the files moved out of the anonymous directory tree.
23 Intrusion Detection:
Ensure that PortSentry is in use.
Review the portsentry.conf file and ensure that the KILL_ROUTE option is configured to either:
add an entry to in the routing table to send responses to the attacking host to a fictitious destination
add firewall filter rules to drop all packets from the attacking host
Ensure that LIDS (Linux Intrusion Detection/Defense System) is in use. Review lidsadm to ascertain what directories are being protected and the other security options that are enabled.
24 Ensure PAM is enabled.
25 HTTP Server
Ensure that the basic access is set to default deny by reviewing access.conf. The options should be set as follows:
Options None
AllowOverride None
Order deny,allow
Deny from all
Ensure that further entries to access.conf only allow access and specific options to authorized hosts based on their function.
Ensure that directories don’t have any of the following options set:
ExecCGI
FollowSymlINKS
Includes
Indexes
Ensure that password protection is used for sensitive data. However, the auditor must be aware that this security control is inadequate on its own since the userid and password are passed over the network in the clear.
Ensure that SSL is used for secure HTTP communications.
Subscribe to:
Posts (Atom)