|
[ Pobierz całość w formacie PDF ]
edit the password file. 38 Cracking passwords In Linux the passwords are stored in a hashed format, however this does not make them irretrievable, chances are you cannot reverse engineer the password from the resulting hash, however you can hash a list of words and compare them. If the results match then you have found the password, this is why good passwords are critical, and dictionary words are a terrible idea. Even with a shadow passwords file the passwords are still accessible by the root user, and if you have improperly written scripts or programs that run as root (say a www based CGI script) the password file may be retrieved by attackers. The majority of current password cracking software also allows running on multiple hosts in parallel to speed things up. John the ripper An efficient password cracker available from: http://www.false.com/security/john/. Crack The original widespread password cracker (as far as I know), you can get it at: http://www.users.dircon.co.uk/~crypto/. Saltine cracker Another password cracker with network capabilities, you can download it from: http://www.thegrid.net/gravitino/products.html. VCU VCU (Velocity Cracking Utilities) is a windows based programs to aid in cracking passwords, VCU attempts to make the cracking of passwords a simple task for computer users of any experience level. . You can download it from: http://wilter.com/wf/vcu/. I hope this is sufficient motivation to use shadow passwords and a stronger hash like MD5 (which Red Hat 6.0 supports, I don t know of other distributions supporting it). 39 Software Management RPM RPM is a software management tool originally created by Red Hat, and later GNU'ed and given to the public (http://www.rpm.org/). It forms the core of administration on most systems, since one of the major tasks for any administrator is installing and keeping software up to date. Various estimates place most of the blame for security break-ins on bad passwords, and old software with known vulnerabilities. This isn't exactly surprising one would think, but while the average server contains 200-400 software packages on average, one begins to see why keeping software up to date can be a major task. The man page for RPM is pretty bad, there is no nice way of putting it. The book "Maximum RPM" (ISBN: 0-672-31105-4) on the other hand is really wonderful (freely available at http://www.rpm.org/ in post script format). I would suggest this book for any Red Hat administrator, and can say safely that it is required reading if you plan to build RPM packages. The basics of RPM are pretty self explanatory, packages come in an rpm format, with a simple filename convention: package_name-package_version-rpm_build_version-architecture.rpm nfs-server-2.2beta29-5.i386.rpm would be nfs-server , version 2.2beta29 of nfs-server , the fifth build of that rpm (i.e. it has been packaged and built 5 times, minor modifications, changes in file locations, etc.), for the Intel architecture, and it s an rpm file. Command Function -q Queries Packages / Database for info -i Install software -U Upgrades or Installs the software -e Extracts the software from the system (removes) -v be more Verbose -h Hash marks, a.k.a. done-o-dial Command Example Function rpm -ivh package.rpm Install 'package.rpm', be verbose, show hash marks rpm -Uvh package.rpm Upgrade 'package.rpm', be verbose, show hash marks rpm -qf /some/file Check which package owns a file rpm -qpi package.rpm Queries 'package.rpm', lists info rpm -qpl package.rpm Queries 'package.rpm', lists all files rpm -qa Queries RPM database lists all packages installed rpm -e package-name Removes 'package-name' from the system (as listed by rpm -qa) Red Hat Linux 5.1 shipped with 528 packages, and Red Hat Linux 5.2 shipped with 573, which when you think about it is a heck of a lot of software (SuSE 6.0 ships on 5 CD's, I haven t bothered to count how many packages). Typically you will end up with 2-300 packages installed (more apps on workstations, servers tend to be leaner, but this is not always the case). So which of these should you install and which should you avoid if possible (like the r services packages). One thing I will say, the RPM's that ship with Red Hat distributions are usually pretty good, and typically last 6-12 months before they are found to be broken. There is a list of URL's and mailing lists where distribution specific errata and updates are available later on in this document. 40 dpkg The Debian package system is a similar package to RPM, however lacks some of the functionality, although overall it does an excellent job of managing software packages on a system. Combined with the dselect utility (being phased out) you can connect to remote sites, scroll through the available packages, install them, run any configuration scripts needed (like say for gpm), all from the comfort of your console. The man page for dpkg "man dpkg" is quite extensive. The general format of a Debian package file (.deb) is: packagename_packageversion-debversion.deb ncftp2_2.4.3-2.deb Unlike rpm files .deb files are not labeled for architecture as well (not a big deal but something to be aware of). Command Function -I Queries Package -i Install software -l List installed software (equiv. to rpm -qa) -r Removes the software from the system Command Example Function dpkg -i package.deb Install package.deb dpkg -I package.deb Lists info about package.deb (rpm -qpi) dpkg -c package.deb Lists all files in package.deb (rpm -qpl) dpkg -l Shows all installed packages rpm -r package-name Removes 'package-name' from the system (as listed by dpkg -l) Debian has 1500+ packages available with the system. You will learn to love dpkg (functionally it has everything necessary, I just miss a few of the bells and whistles that rpm has, on the other hand dselect has some features I wish rpm had). There is a list of URL's and mailing lists where distribution specific errata is later on in this document. tarballs / tgz Most modern Linux distributions use a package management system to install, keep track of and remove software on the system. There are however many exceptions, Slackware does not use a true package management system per se, but instead has precompiled tarballs (a compressed tar file containing files) that you simply unpack from the root directory to install, some of which have install script to handle any post install tasks such as adding a user. These packages can also be removed, but functions such as querying, comparing installed files against packages files (trying to find tampering, etc.) is pretty much not there. Or perhaps you [ Pobierz całość w formacie PDF ] |
Podobne
|