Security
  Home arrow Security arrow Page 10 - Unix Host Security: Hacks 11-20
Dev Shed Forums  
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Smartphone Development  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Mobile Linux  
App Generation ROI  
IBM® developerWorks  
Forums Sitemap  
E-Commerce Hosting  
Linux Web Hosting  
Managed Hosting  
Small Business Hosting  
VPS Hosting  
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid  
Request Media Kit
Contact Us  
Site Map  
Privacy Policy  
Support  
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
SECURITY

Unix Host Security: Hacks 11-20
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: starstarstarstarstar / 31
    2004-05-10


    Table of Contents:
  • Unix Host Security: Hacks 11-20
  • Prevent Stack-Smashing AttacksHack #12
  • Lock Down Your Kernel with grsecurity Hack #13
  • Restrict Applications with grsecurity Hack #14
  • Restrict System Calls with Systrace Hack #15
  • Automated Systrace Policy Creation Hack #16
  • Control Login Access with PAM Hack #17
  • Restricted Shell Environments Hack #18
  • Enforce User and Group Resource Limits Hack #19
  • Automate System Updates Hack #20

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      error-file:tidyout.log Del.ici.ous error-file:tidyout.log Digg
      error-file:tidyout.log Blink error-file:tidyout.log Simpy
      error-file:tidyout.log Google error-file:tidyout.log Spurl
      error-file:tidyout.log Y! MyWeb error-file:tidyout.log Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article

     
     
    ADVERTISEMENT


    Unix Host Security: Hacks 11-20 - Automate System Updates Hack #20
    ( Page 10 of 10 )

    Patch security holes in a timely manner to prevent intrusions.

    Updating and patching a system in a timely manner is one of the most important things you can do to help protect your systems from the deluge of newly discovered security vulnerabilities. Unfortunately, this task often gets pushed to the wayside in favor of “more pressing” issues, such as performance tuning, hardware maintenance, and software debugging. In some circles, it’s viewed as a waste of time and overhead that doesn’t contribute to the primary function of a system. Coupled with management demands to maximize production, keeping a system up-to-date is often pushed even further down on the to-do list.

    Updating a system can be very repetitive and time consuming if you’re not using scripting to automate it. Fortunately, most Linux distributions make their updated packages available for download from a standard online location. We can monitor that location for changes and automatically detect and download the new updates when they’re made available. To demonstrate how to do this on an RPM-based distribution, we’ll use AutoRPM (http://www.autorpm.org).

    AutoRPM is a powerful Perl script that allows you to monitor multiple FTP sites for changes. It will automatically download new or changed packages and either install them automatically or alert you so that you may do so. In addition to monitoring single FTP sites, you can also monitor a pool of mirror sites, to ensure that you still get your updates in spite of a busy FTP server. This feature is especially nice in that AutoRPM will monitor busy FTP servers and keep track of how many times a connection to them has been attempted. Using this information, it assigns internal scores to each of the FTP sites configured within a given pool, with the outcome that the server in the pool that is available most often will be checked first.

    To install AutoRPM, download the latest package and install it like this:

    # rpm -ivh autorpm-3.3-1.noarch.rpm

    Although a tarball is also available, installation is a little more tricky than the typical make; make install, and so it is recommended that you stick to installing from the RPM package.

    By default, AutoRPM is configured to monitor for updated packages for Red Hat’s Linux distribution. However, you can configure it to monitor any file repository of your choosing, such as one for SuSE or Mandrake. 

    Buy the book! If you've enjoyed what you've seen here, or to get more information, click on the "Buy the book!" graphic. Pick up a copy today!

    Visit the O'Reilly Network http://www.oreillynet.com for more online content.



     
     
    >>> More Security Articles          >>> More By O'Reilly Media
     

       

    SECURITY ARTICLES

    - Critical Microsoft Visual Studio Security Pa...
    - US Faces Tech Security Expert Deficit
    - LAN Reconnaissance
    - An Epilogue to Cryptography
    - A Sequel to Cryptography
    - An Introduction to Cryptography
    - Security Overview
    - Network Security Assessment
    - Firewalls
    - What’s behind the curtain? Part II
    - What’s behind the curtain? Part I
    - Vectors
    - PKI: Looking at the Risks
    - A Quick Look at Cross Site Scripting
    - PKI Architectures: How to Choose One





    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 4 Hosted by Hostway
    Stay green...Green IT