Free security checks software for linux

Seccheck is a feature rich, modular, host-level security checker for Solaris 10.
On reviewing the excellent security benchmarks available over at CI Security, I wanted to automate the security checks of my Solaris 10 servers and produce a highly detailed report listing all security warnings, together with recommendations for their resolution. The solution was seccheck - a modular host-security scanning utility. Easily expandable and feature rich, although at the moment only available for Solaris 10.
This doesnt cover 100% of the checks recommended by CI Security, but has 99% of them - the ones that I consider important. For example, I dont check X configuration because I always ensure my servers dont run X.
Installation
The source distribution should be unpacked to a suitable location. I suggest doing something like the following:
# mkdir /usr/local/seccheck
# chown root:root /usr/local/seccheck
# chmod 700 /usr/local/seccheck
# cd /usr/local/seccheck
# mkdir bin output
# cd /wherever/you/downloaded/seccheck
# gzip -dc ./seccheck-0.7.1.tar.gz | tar xf -
# cd seccheck-0.7.1
# mv modules.d seccheck.sh /usr/local/seccheck/bin
Everything is implemented as bash shell scripts, so there are no really strict installation guidelines, place the files wherever you wish. You can specify an alternate location for the modules directory with the -m option anyway.
Using seccheck
By default, seccheck.sh will search for a modules.d directory in the same directory in which the seccheck.sh script is located. If your modules are not located there, you can use the -m option to specify an alternate module location, for example:
# ./seccheck.sh -m /security/seccheck/mymodules
seccheck will then scan through the modules.d for valid seccheck modules (determined by filename). A seccheck module filename should be of the following format:
seccheck_nn_somename.sh
Where nn is a two digit integer that determines the order in which modules should be executed. For example, included with the current seccheck distribution youll find the following files in modules.d:
# ls -1 modules.d
seccheck_00_services.sh
seccheck_01_users.sh
seccheck_03_kernelcheck.sh
seccheck_05_logging.sh
seccheck_10_accessauth.sh
seccheck_99_perms.sh
seccheck_NN_template.sh.NOT
You can see that seccheck_00_services.sh will be processed before seccheck_01_users.sh, and so on. You can disable a module by renaming it something other than the convention, for example, by appending a .NOT suffix to the module filename.
A template is provided so that you can write your own seccheck modules.
By default, seccheck will write everything out to STDOUT and STDERR. If you want to redirect to an output file, just use the -o option and specify an output directory. After running the script, youll be left with a file such as:
${OUTPUT_DIR}/seccheck-< hostname >-YYYYMMDD-hhmm.log
containing the output of your modules.
Enhancements:
- Bugfixes were made in shell detection logic, for a typo in SAMBA recommendations, and in the use of "printf" instead of "echo" in the authlog recommendation.

Check Your Network Address Translator for Compatibility with Peer-to-Peer Protocols.
If you are accessing the Internet from behind a Network Address Translator (NAT) of some kind, I would appreciate your help in surveying the behavior of different NATs, in terms of how and whether they support a certain technique for enabling peer-to-peer communication between NATted hosts (particularly when both endpoints are behind NATs). Down, you can understand what NAT is.
Suppose there are three communicating hosts: A, B, and C. Host A is a "well-known" Internet server with a permanent IP address, which acts as an "introducer" for the other two nodes. (For example, Host A might be a well-known ultrapeer or a game catalog server of some kind.) Host B, using Host As "introduction" services, would like to establish a direct peer-to-peer connection with host C. Both B and C, however, are behind (probably different) network address/port translators, and neither of them has exclusive use of any public IP address.
To initiate a peer-to-peer connection with host C, host B first sends A a message requesting an "introduction" to host C. A sends B a reply message containing Cs IP address and UDP port number as reported by host C, in addition to Cs IP address and UDP port number as observed by A. (If C is behind a NAT, then these two address/port combinations will be different.) At the same time, host A sends host C a message containing Bs IP address and UDP port numbers - again, both the ones reported by B and the ones observed by A, which will be different if B is behind a NAT.
Now B and C each know that they want to initiate a connection with each other, and they know each others public (NATted) as well as original IP addresses and UDP port numbers. Both B and C now start attempting to send UDP messages directly to each other, at each of the available addresses. If B and C happen to be behind the same NAT, then they will be able to communicate with each other directly using their "originally reported" IP addresses and UDP port numbers.
In the more common case where B and C are behind different NATs, the "originally reported" addresses will be useless because they will both be private IP addresses in different addressing domains. Instead, the IP address/UDP port combinations observed by A can be used in this case to establish direct communication. Although Bs NAT will initially filter out any UDP packets arriving from Cs public (NATted) UDP port directed at Bs public port, the first UDP message B sends to C will cause Bs NAT to open up a new UDP session keyed on Cs public port, allowing future incoming traffic from C to pass through the NAT to B. Similarly, the first few messages from B to C may be filtered out by Cs NAT, but will be able to start passing through the firewall as soon as Cs first message to B causes Cs NAT to open up a new session. In this way, each NAT is tricked into thinking that its respective internal host is the "initiator" of this new session, when in fact the session is fully symmetrical and was initiated (with As help) simultaneously in each direction.
Required NAT Behavior
There is one important requirement that the NATs must satisfy in order for this technique to work: the NATs must be designed so that they assign only one (public IP address, public UDP port) pair to each (internal IP address, internal UDP port) combination, rather than allocating and assigning a new public UDP port for each new UDP session. Recall that a "session" in Internet terminology is defined by the IP addresses and port numbers of both communicating endpoints, so host Bs communication with host A is considered to be one session while host Bs communication with host C is a different session. If Bs NAT, for example, assigns one public UDP port for Bs communication with A, and then assigns B a different public UDP port for the new session B tries to open up with C, then the above technique for peer-to-peer communication will not work because Cs messages to B will be directed to the wrong UDP port.
RFC 3022 explicitly allows and suggests that NATs behave in the former, "desirable" fashion, by maintaining a single (public IP, public port) mapping for a given (internal IP, internal port) combination independent of the number of active sessions involving this mapping. This behavior is not only good for compatibility with UDP applications, but it also helps to conserve the NATs scarce pool of public port numbers. Maintaining a consistent public port mapping does not adversely affect security in any way, either, because incoming traffic can still be filtered on a per-session basis regardless of how addresses are translated. There in fact appears to be no good reason not to implement the desirable behavior in a NAT, except perhaps for the implementation simplicity of naively allocating a new public port for every new session. Unfortunately, RFC 3022 does not require NATs to implement the desirable behavior, which has led me to wonder just how many real NATs actually do, and hence this page.
What NAT Check Does
The program natcheck.c is basically just a program that "pings" a well-known UDP port at two different servers that are publically accessible on the Internet. Both of these servers run the program natserver.c, with the command-line arguments "1" and "2" respectively. In addition, there a third "conspiring" server runs natserver with the command-line argument "3". Whenever each of the first two servers receives a UDP request, it not only sends a reply directly to the sender of that request, but also sends a message to the third server, which in turn "bounces" the reply back to the original client. The effect is that the client will receive not only solicited "ping" replies from the server the request was directed to, but also "unsolicited" replies from the third server.
To determine if the network address translator in use is implementing the desirable behavior of maintaining a single (public IP address, public port) mapping for a given (client IP address, client port), the client program natcheck.c basically just initiates a sequence of simultaneous pings to the first two servers (in case some of the requests or replies are lost in transit) and checks that the clients address and UDP port as reported by both servers is the same. If the NAT naively allocates a new public port for each new session, then the source port as reported by the two servers will be different, and its time to upgrade your NAT.
The replies echoed from the third server are used only to check whether the NAT properly filters out unsolicited incoming traffic on a per-session basis. Since the client never sends any messages to the third server, if the NAT is properly implementing firewall functionality, the client should never see the third servers echoed replies even after opening up active communication sessions with the first two servers.
Enhancements:
- The NAT Check client no longer attempts to guess whether you have Basic NAT or Network Address/Port Translation (NAPT). It turns to be quite difficult to test for this property reliably, because many NAPTs attempt to bind a private UDP port to a public port with the same port number if that port number is available, causing NAT Check to falsely report Basic NAT. The only way to test for this property reliably would be to run NAT Check on at least two client machines simultaneously, and since this property isnt terribly important to P2P apps its just not worth the trouble.
- The NAT Check client now tests for one additional NAT feature, which I call loopback translation. If a NAT supports loopback translation, it means that a host on the private network behind the NAT can communicate with other hosts on the same private network using public (translated) port bindings assigned by the NAT. Most NATs probably do not support this feature yet, but it may become increasingly important in the future where P2P clients may be located behind a common ISP-deployed NAT as well as individual home NATs. More details on loopback translation will appear in the next version of my Internet-Draft, to be released soon.
- The NAT Check client program now has a command-line option, "-v", which turns on verbose messages during the test.

Secheck is a script designed for linux users to keep up with some security issues on their system. secheck runs nightly and checks on such things as: SUID files, passwordless accounts, open ports, users on the system with root access, who has sud to root, etc. For more information, please see the about page.
I have written a small install.sh script which should handle all installation. Heres basiclly what it does, minus the crontabing
1. cp secheck-* /usr/local/etc/ && cd to /usr/local/etc/secheck
2. unpack the archive with: tar -xvf secheck-0.01.tar
3. cd into /usr/local/etc/secheck/
4. chmod +x security.check secheck
5. edit secheck and change the email address to the user(s) or email address you want the output mailed to.
6. Run secheck
7. crontab secheck
When it is finished, the output should look like this:
/root/secheck-*(version number)
/root/secheck-*/secheck
/root/secheck-*/security.check
/root/secheck-*/other docs, README, INSTALL, etc
/usr/local/etc/secheck/secheck
/usr/local/etc/secheck/security.check
/root/.secheck/baslinefiles
If that isnt the case.. you may need to cp a few files here and there, and I will have it fixed in the next release.
Main features:
- 1. Show open ports on the system
- 2. Shows the current users on the system.
- 3. Shows how much drive space is free (in gb)
- 4. Shows SUID and SGID files on the system
- 5. Checks for users with root accounts
- 6. Checks for passwordless accounts
- 7. Shows system processes
- 8. Shows who has sud to root (also includes sudo)
- 9. Optional: shows denied packets through ipchains/iptables
- 11. Shows all files with no owner
- 12. Show the differences between a basline copy of: /etc/passwd, /etc/shadow, /etc/group, and /etc/inetd.conf with the current version.
- 10. Emails the output of all of these to a user specified in check.sh (the wrapper script).

RTL-check is a framework for static analysis of programs from a safety and security perspective.
RTL-check project performs analysis on RTL, which is the low-level intermediate representation generated by GCC.
Enhancements:
- The performance of the analysis was improved, and a minor bug was fixed.

Integcheck is a system integrity checker.
Integcheck checks the integrity of exposed systems by getting a list of MD5 hashes of any important file via SSH.
The idea is to check integrity of exposed systems by getting a list of md5 of any important file via ssh, to keep this list on a pretty safe system (a system that do not run any server publicly available), and, finally, to compare everyday this list and with the previous one.
As long as the system considered as safe is not compromised, it should inform administrators of any changes on the others systems.
As others integrity checker, if its own components are corrupted, it can be fooled. In others words, you cannot have a security policy entirely relying on an integrity checker, and you should always do manual checks regularly to be sure that the integrity checker is not corrupted itself.
So whats the point of this tool, if you are still forced to do manual checks? In fact, it is way faster to check integrity of integcheck than integrity of the whole system.
Enhancements:
- Checks now rely on MD5 and file size instead of just MD5.

GNU Phantom.Security is a computer-controlled security system.
Phantom is designed to be a completely customizable computer controlled security system. All source code (C++/Bourne script) is included. Phantom was designed & tested on a Linux system, but I assume the C++ portions can be easily ported to other Unix systems (even DOS/Windows, maybe?). The Phantom Security system is for use with intrusion/fire detection equipment such as motion sensors, door magnets, and smoke detectors. However, any Normally Open or Normally Closed device may work with little or no change to the code. All source code and diagrams included are free to use,for distributing, and to modify!
Phantom.Controller is to be used in a system with non-powered security devices, i.e. door magnets. Phantom.Controller2 is for systems with powered security devices, i.e. motion sensors & smoke detectors. Anyone with a basic knowledge of circuit design can mix and match from these two diagrams to mix powered & non-powered devices!
Enhancements:
- To compile & install Phantom.Security 1.00:
- configure
- make
- make install
- The default installation directory is /home/Phantom/security. However, this can be modified in the top-level Makefile.am (if this is changed, you need to re-run aclocal, autoconf, & automake). However, both the bindir and datadir should point to the SAME directory, or else Phantom.Security wont function correctly, because it wont be able
- to find the Phantom.conf file.
Enhancements:
- Version 1.0!!! GNU Phantom.Security is out of Beta! I have been running Phantom.Security for months straight on my machine at work and believe it is stable enough to promote it out
- of Beta!
- Created HTML & PostScript versions of documentation. Available on-line.

Network Security Toolkit is a bootable ISO live CD and its based on Fedora Core 2.
The toolkit was designed to provide easy access to best-of-breed Open Source Network Security Applications and should run on most x86 platforms.
The main intent of developing this toolkit was to provide the network security administrator with a comprehensive set of Open Source Network Security Tools. The majority of tools published in the article: Top 75 Security Tools by insecure.org are available in the toolkit.
What we find rather fascinating with NST is that we can transform most x86 systems (Pentium II and above) into a system designed for network traffic analysis, intrusion detection, network packet generation, wireless network monitoring, a virtual system service server, or a sophisticated network/host scanner.
This can all be done without disturbing or modifying any underlying sub-system disk. NST can be up and running on a typical x86 notebook in less than a minute by just rebooting with the NST ISO CD. The notebooks hard disk will not be altered in any way.
NST also makes an excellent tool to help one with all sorts of crash recovery troubleshooting scenarios and situations.
Enhancements:
- We are pleased to announce the latest NST release: v1.5.0. This release is based on Fedora Core 5 using the Linux kernel 2.6.18. Here are some of the highlights for this release: the NST Web User Interface (WUI), has been greatly enhanced and cleaned up; extensive additions to managing and analyzing network packet captures; the ability to setup and manage printers; the ability to easily mount many different supported file system types; the ability to manage the NST as a file server (both NFS and CIFS); the addition of the Inprotect package (a Nessus manager); the addition of the Zabbix package (another network resource monitoring tool - similar to Nagios)....