Greetings fellow Linux security enthusiasts, Interested in becoming a LinuxSecurity contributor, but need an article topic idea and some guidance to help you get started? . We’re looking for contributors with an understanding of Linux firewalls who can help provide insight into how firewalls can be implemented and configured to improve the security of a Linux system. If you would like to contribute an article on this topic, we suggest that you explore: The types of attacks that firewalls can and cannot protect against Limitations of firewalls, and the the importance of taking a defense-in-depth approach to securing a Linux system Tips and advice for using firewalls to secure a Linux system How using a web application firewall (WAF) can improve security Best practices for securely configuring and maintaining firewalls The LinuxSecurity.com contributor program provides you with the opportunity to share your knowledge and experience with a community of like-minded people who share your passion for Linux and security, receive comments from community members, and engage in meaningful discussions about the topics that interest you most. To get started, register and customize your User Profile . If you are new to LinuxSecurity.com, I would like to extend a warm welcome to the LinuxSecurity community! Yours in Open Source, Brittany Day Be Aware of Zero Trust Challenges Implementing Zero Trust recommendations could potentially lead to a decrease in work productivity during encryption and increased costs associated with ongoing administration. . Participate in our contributor initiative to provide knowledge on Linux security measures and elevate system protection with your experience.. Linux Firewalls, Security Configuration, Open Source Community. . Brittany Day
Running PHP on a Linux web server is a prerequisite for the use of many popular applications such as Wordpress, Joomla and Drupal. Linux administrators and web developers must approach PHP with caution, as new vulnerabilities in poorly written and implemented PHP code are abundant and dangerous. . In a recent security incident, hackers were able to add a backdoor to the PHP source code . Although the backdoor mechanism was discovered before it made it into production, the incident serves as the latest reminder of the importance of prioritizing PHP security. PHP security is inextricably tied to web server security. Because the popular open-source server-side scripting language is often paired with MySQL, PHP compromise can mean a compromise of the accompanying MySQL database, as well as any web applications running on the web server. This article will examine how you can configure and run PHP securely to mitigate the risk of attacks and compromise, secure web applications, protect user privacy and maintain a secure and properly functioning Linux web server. PHP Vulnerabilities Carry Great Risk for Admins Vulnerabilities in PHP code are a prevalent and serious threat to web server administrators and web application developers. These flaws are often introduced when developers are writing code, either due to a mistake or the inability to anticipate malicious hackers’ ever-evolving techniques. A plethora of vulnerabilities exist in the PHP core - with new security bugs being discovered each month. On March 28, 2021, hackers breached the internal PHP Git repository and inserted a backdoor into the PHP source code. Luckily, the malicious code was discovered by Michael Voříšek before it made it into production, and the hack led the PHP team to move source code management operations from its internal Git server to its official GitHub account, which will serve as PHP’s official Git repository going forward. In another PHP security incident that occurred less than three years ago and has yetto be explained today, hackers compromised the official PHP PEAR extensions system website and hosted a backdoored version of the PHP PEAR package manager for almost six months. PHP vulnerabilities can be exploited by attackers to spread malware & take control of hundreds of thousands of web servers in botnets. In one such instance this past year, the infamous hackers-for-hire group DarkCrewFriends resurfaced with a dangerous botnet strategy exploiting an unrestricted file upload vulnerability to compromise PHP servers running websites. In another malicious campaign a year prior, the Neutrino botnet was discovered hijacking servers by taking over other hackers’ PHP and Java web shells to install a cryptocurrency-mining malware . To help you better understand the threats that your web servers and web applications face, let’s take a look at some of the most notorious types of PHP vulnerabilities. A Quick Look at the Most Common & Dangerous Types of PHP Vulnerabilities Threatening Your Web Servers Remote Code Execution (RCE) In this type of vulnerability, a bug in a PHP application accepts user input and evaluates it as PHP code, enabling an attacker to upload code to a website and execute it. This could, for example, allow a malicious actor to tell the website to create a new file containing code that gives him or her full access to the compromised website. RCE vulnerabilities are very serious because they are easy to exploit and grant an attacker full access when exploited. SQL Injection (SQLi) SQL injection (SQLi) occurs when a hacker is able to send instructions to a database and the database executes those instructions. This type of vulnerability occurs when a PHP developer takes input from a website visitor and passes it to the database without reviewing it for malicious code. SQLi vulnerabilities are very serious because they are easy to exploit and often grant full access immediately. Cross-Site Scripting (XSS) Cross-site scripting (XSS) takes place when an attacker causesmalicious code to load in a website visitor’s browser and execute. This code often steals user cookies to grant the attacker administrative level access or performs functions as the user to grant additional access. Cross-site Request Forgery (CSRF) Cross-site request forgery (CSRF) describes a scenario in which a user is tricked into issuing a request that is not in his or her best interest. For instance, an attacker may create a link and trick an administrator into clicking on that link, causing the site to take a certain action such as creating a new ‘admin’ user with a known password. This critical WordPress vulnerability which was fixed in November of 2020 left servers vulnerable to a variety of attacks including cross-site request forgery and cross-site scripting. Authentication Bypass This type of vulnerability is introduced through incorrect validation that a site visitor has the access level required to take a certain action. For example, a developer may wrongly use a function called ‘is_admin()’ - which is designed to indicate if someone is viewing an admin page - to try to validate that someone is an administrator, mistakenly granting non-admin users access to features that only administrators should have access to. PHP Object Injection PHP object injection is a complex attack that occurs when a PHP application takes user input and passes it to the unserialize() function, which takes a stored object and turns it into an object in memory. This type of vulnerability occurs when a developer allows user input to be used in an unsafe way within a PHP application. The unserialize() function must be approached with extreme caution, as this function is commonly exploited by attackers. PHP 7 has includes a new filtered unserialize feature designed to mitigate the impact of code injection vulnerabilities by requiring that developers specify classes that are safe to unserialize. However, it is critical to keep in mind that even with this improvement, passing untrusted input tounserialize() is never safe. Remote File Inclusion (RFI) & Local File Inclusion (LFI) Remote file inclusion (RFI) and local file inclusion (LFI) take place when a PHP application takes user input and passes it to a function designed to load a file. The inclusion of a remote file in a URL is known as Remote File Inclusion (RFI) while the inclusion of a local file in a URL is known as Local File Inclusion (LFI). LFI is often the method an attacker employs to gain access to a WordPress website’s wp-config.php file. Source Code Revelation This type of vulnerability has to do with people being able to see the names and content of files that they shouldn’t be able to view due to the breakdown of a web server’s configuration. The code revealed in this type of vulnerability may list accessible configuration files or contain sensitive information such as database credentials. Session Hijacking Session hijacking occurs when a malicious actor steals a user’s session ID. When a session is set up between a client and a web server, PHP will store the session ID in a cookie on the client side. Sending the ID with the page request provides access to this confidential information, potentially resulting in session hijacking. Session IDs are commonly stolen via XSS attacks, and can also be vulnerable server-side through the use of hosting services that store session information in globally accessible directories. These vulnerabilities in Apache versions 2.4.33-1 and prior - which have since been fixed upstream - left web servers susceptible to session hijacking and an array of other dangerous exploits. Directory Traversal Directory traversal looks for vulnerable websites and causes files to be accessed that the owner did not plan on making publicly accessible. It is also referred to as the ../ (dot, dot, slash) attack, the climbing attack, or the backtracking attack. Tracking advisories is critical in preventing all of these prevalent and serious types of PHP vulnerabilities. Subscribing to ourweekly Linux Advisory Watch newsletter is an easy, convenient way to stay up-to-date on the latest advisories and updates issues by your Linux distro. In addition to tracking advisories, we recommend that web server administrators implement the ModSecurity web application firewall (WAF), which can provide another line of defense against the attacks listed above. The open-source, cross platform WAF has a robust event-based programming language and allows for HTTP traffic monitoring, logging and real-time analysis. Best Practices for Improving PHP Security The majority of attacks on Linux web servers can be attributed to misconfigurations and poor administration. Thus, it is essential that administrators configure their web servers to be as secure as is practical within the construct of their environment. The Open Web Application Security Project (OWASP) , a nonprofit fo undation we trust and admire that works to improve the security of software through community-led open-source projects, suggests that administrators and developers implement these secure PHP configuration recommendations to protect their web servers against dangerous PHP vulnerabilities and prevent attacks. LinuxSecurity.com PHP security experts Brittany Day and Dave Wreski have additional tips and advice for improving PHP security, which we will explore in this section. Our Top PHP Security Tips & Advice Update Your PHP Version and Modules Regularly It is critically important that administrators and developers update their PHP version and modules regularly. With the support of the open-source community behind PHP, patches and bug fixes for vulnerabilities are released frequently, and newer versions of PHP and its modules often contain mitigations for known security issues that can be exploited by malicious hackers. As of January, 2022, the stable release for PHP is version 8.1.1 , from December 2021. It should be noted that when PHP is being used in a hosting environment, users may not be able to update their PHPversion number. In such scenarios, users must be especially careful and vigilant. They should also explore potential workarounds and demand that their hosting provider update PHP at the earliest opportunity. Restrict PHP Information Leakage The unfortunate reality is that it is common for platforms to leak sensitive information - and PHP is no exception. For example, PHP releases versions and the fact that it is installed on a server through the expose_php directive. To prevent the leakage of this sensitive data, administrators should set this directive to off in /etc/php.d/security.ini. expose_php=Off Control File System Access PHP can access files by default via the open_basedir directive using functions like fopen(). To control file access and prevent security issues, the open_basedir directive should always be set to the /var/www/html directory. open_basedir="/var/www/html/" Disable Remote Code Execution (RCE) In PHP, remote code execution is enabled by default. The "allow_url_fopen" directive allows functions including require, include, or URL-aware fopen wrappers to obtain direct access to PHP files. Remote access can be obtained using the HTTP and FTP protocols, leaving system defenseless against code injection vulnerabilities. To protect against these types of exploits, administrators should disable remote code execution by setting the "allow_url_fopen" directive to "Off". Disable Dangerous PHP Functions & Get Rid of Unnecessary Modules PHP comes with a selection of useful functions, but is also plagued with functions that can be exploited by attackers and should be disabled. To disable these dangerous functions, administrators must edit the php.ini file. In this file, they should find the disable_functions directive and disable the dangerous functions in it using: disable_function =exec,passthru, shell_exec,system,proc_open, popen,curl_exec, curl_multi_exec,parse_ini_file,show_source PHP also comes with an array of excellent modules; however, not all modules arerequired for every project. In PHP, all the extension modules found in /etc/php.d/ directory are loaded by default. Administrators should get rid of all modules that are not currently required, as doing so will improve both security and performance. To view available PHP modules, use the command: php -m Once you have accessed this list, you will be able to get rid of all unnecessary modules. To enable or disable a particular module, simply find the configuration file in the /etc/php.d/ directory and comment the module name. Scan PHP Scripts & Audit PHP Code for Security Vulnerabilities Scanning PHP scripts and auditing PHP code is essential in identifying and fixing potential security vulnerabilities before they are exploited by attackers. There is a plethora of excellent free and open-source tools and utilities available to assist Linux users in this process. Here are some of our favorites: Phpcs-security-audit is a set of customizable PHP_CodeSniffer rules that identifies security vulnerabilities and weaknesses in PHP code. The tool checks for CVE issues and security adviso ries related to the CMS/framework, enabling administrators to follow the versioning o f components during static code analysis. SensioLabs Security Checker is a command line tool that checks if an application uses dependencies with known security vulnerabilities using the Security Check Web service and the Security Advisories Database . Suhosin is an advanced security system for PHP installations designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. PHP Malware Finder (PMF) is a self-hosted solution designed to help administrators and developers identify potentially malicious code in files. Detection is performed by crawling the filesystem and t esting files against a set of YARA rules. RIPS is a PHP static code analysis tool that is integrated through the development lifecycle to identify security issues in real-time. The toolsupports 15 different types of vulnerabilities, and is able to scan PHP applications very rapidly for PHP-specific vulnerabilities. SonarPHP is a static code analyzer that uses pattern matching and data fl ow techniques to identify vulnerabilities in PHP code. It is used as an extension for the SonarQube platform and features over 200 rules, along with support of custom rules. Dependency-check-cli is a great tool from OWASP that uses dependency-check-core to detect publicly disclosed vulnerabilities associated with the scanned project dependencies. The tool will generate a report listing the dependency, any identified Common Platform Enumeration (CPE) identifiers, and the associated Common Vulnerability and Exposure (CVE) entries. PHP Secure Configuration Checker is a single file that checks a current PHP configuration for potential security flaws. It is user-friendly and has almost no dependencies. The Bottom Line PHP offers web server administrators and web application developers an array of valuable functions and modules paired with robust security inside out - a characteristic that can largely be attributed to the support that PHP receives from the vibrant, global open-source community. However, PHP security is ultimately in the hands of the administrator. He or she must make sure code is written properly, the proper configurations have been made and that the best practices covered in this article are being implemented. PHP security should be a primary concern for administrators and developers, as it is inextricably tied to the security of a web server as a whole. Sound PHP security can help mitigate the risk of attacks and compromise, secure web applications, protect user privacy and maintain a secure and properly functioning Linux web server. Do you have questions about PHP security or want to discuss the topic in more depth? Let’s chat! Connect with us on social media: Twitter | Facebook . In a recent security incident, hackers were able to add a backdoor tothe PHP source code. Although . running, linux, server, prerequisite, popular, applications. . Brittany Day
Today in Hacks From Pax we'll talk about AIDE, a host intrusion detection system. AIDE can provide another important layer of security for a system, specifically a layer designed not to keep intruders out per se, but to notify administrators of a possible compromise or intrusion. By itself it won't prevent a successful intrusion, but it can help prevent the only thing worse: a successful intrusion that you don't know about yet. . What is AIDE? AIDE stands for Advanced Intrusion Detection Environment, it is a host-based IDS that tracks and checks file integrity. It works by creating a database of system file information and checks the files against this database periodically, notifying an administrator of any changes to the file. AIDE checks not just the file size and modification times, but also can keep track of inode numbers, user and group permissions, and various file checksums. The purpose of this checking is to notify the administrator when any system file changes. A hacker intrusion can result in the modification of system files in order to install a backdoor to the system, and AIDE can help detect this. Ideally an attacker will never penetrate this far, but if it happens AIDE can be a lifesaver, enabling you to know in a timely manner that your machine has been compromised. Configuring AIDE Packages for AIDE exist for all major distributions, and installing AIDE should not pose a problem. Compiling from source involves a typical configure , make , make install procedure and should also be relatively trouble free. The key to using AIDE effectively is in the construction of your AIDE configuration file, /etc/aide/aide.conf . The configuration file allows you to set some typical options such as file paths for the file integrity database and generated reports, but the heart of it is a list of regular expressions that are matched to file paths and the specific attributes of those files that should be checked. The default available attributes are as follows: p: permissions i: inode n: number of links to the file u: user g: group s: size b: block count m: last modification time (mtime) a: last access time (atime) c: last inode/permission change time (ctime) S: size may only grow, not shrink md5: md5 checksum sha1: sha1 checksum rmd160: rmd160 checksum tiger: tiger checksum R: p+i+n+u+g+s+m+c+md5 L: p+i+n+u+g E: Empty group > : Growing logfile p+u+g+i+n+S You can create your own combinations of these attributes for shorthand use within the configuration file. EnGarde Secure Linux, which includes AIDE in the default install, defines the following rules in it's default configuration file: SEC_BIN = p+i+n+u+g+s+b+m+crc32+md5 # Read only SEC_CONFIG = p+i+n+u+g # Changing file SEC_CRIT = p+i+n+u+g+s+b+m+c+crc32+md5 SEC_INVARIANT = p+u+g SEC_LOG = p+i+n+u+g+S # Can grow but not shrink SEC_DEV = p+u+g+s SEC_RUN = p+u+g For example, a typical configuration file located in /etc would be assigned the SEC_CONFIG attribute, which would track changes to the file's permissions, inode, number of links, owner, and group, but not content changes since the file may be changed. A logfile would be assigned SEC_LOG and would track the same attributes but also alert if the file shrunk in size, a suspicious sign of log entries being removed. The rest of the configuration file is a list of regular expressions that assign a desired attribute to any files whose paths match the regexp. Files can be ignored by prefixing the regexp with a ! character. A trailing $ must be used to prevent matching more than just the desired path, for example /etc$ would match only the /etc directory, while having just /etc in your config file would match the /etc directory and everything within it as well. Using AIDE Once your configuration file is completed and you have the files you would like to track listed in it, you cangenerate the AIDE database by running the command aide --init . This creates the database and stores the initial accounting information about each file in your configuration file to be checked against later. The truly paranoid should burn this database to a CD or other read only media to prevent it being modified by an attacker and change the config file to point to this location. Alternatively, SELinux permissions could restrict access to the database as well. As with any security implementation, you must balance your need for security against usability. A perfectly secured offline AIDE database that requires you to perform manual checking may eventually be neglected and therefore not as useful as a possibly compromisable online database that automatically checks the system daily. It depends on your specific security requirements. Now that the database is created, you can check for violations of the AIDE policy by running aide --check . This will create an AIDE report in the location specified in the configuration file, listing all the differences between the accounting information in the database and the current state of the monitored files. The checking can be run as often as necessary depending on your needs, and if automated by a cron job it is a simple matter to have the report emailed to a recipient of your choice for review. Periodically as changes accumulate in the report you should refresh the database to eliminate these old results using the command aide --update . This regenerates the database with the current state of the system and should be done whenever the report becomes unwieldy and cluttered with old changes that no longer are a concern. AIDE can be a very useful addition to your security toolbox. Maintaining an eye on your machine's system file integrity warns you of possible outside intrusion as well as allows you to record when internal changes were made to the system. AIDE and other host-based intrusion detection tools can be a valuable last line of defense behindyour firewall and network IDS to notify you of possible trouble. -- Pax Dickinson has over ten years of experience in systems administration and software development on a wide variety of hardware and software platforms. He is currently employed by Guardian Digital as a systems programmer where he develops and implements security solutions using EnGarde Secure Linux. His experience includes UNIX and Windows systems engineering and support at Prudential Insurance, Guardian Life Insurance, Philips Electronics and a wide variety of small business consulting roles. . Discover AIDE, an advanced host-based Intrusion Detection System (IDS) that meticulously tracks file integrity and promptly notifies on modifications to bolster security.. AIDE, host-based IDS, file integrity monitoring. . Brittany Day
This article will discuss installing and configuring a secure, centralized file-integrity program. Later articles in this series will discuss specific features, like deploying packaged clients to hosts on your network, creating customized reports, and other cool Samhain features. . Centralized monitoring is critical today with the large number of servers that are deployed in many organizations. Reading reports from individual servers can be quite cumbersome and time-consuming. Programs are needed that will provide accurate and secure information about the state and health of servers in a timely manner in a centralized location, whether with one server or multiple servers. One of the most critical needs is a program that will alert an administrator when files have been changed on a system whether intentionally or as the result of a security compromise. Many programs exist that provide from very basic file-integrity to very specific file-integrity. For example, some file-integrity checks look for any file that has changed within a directory and others can ignore if a file has been accessed or grown in size but alert if the permissions have changed. The level of security needed for file-integrity can depend on a number of factors. How many servers are in an organization, the time an administrator has to spend looking at file-integrity reports, the level of training for the administrator, the cost of a good file-integrity program, the sensitivity of data stored on a server, etc.. There are some superb commercial applications that provide fine-grain control of file-integrity configurations. Of course, it can cost quite a bit of money for these programs but if the needs fit an organization this may be their only solution. There are some great free programs that can rival many of the commercial applications. However, some require extra configuration with other third-party software to have logs sent to a central location securely, for example. Some organizations don't have theadministrators who have the time to create custom programs to add extra functionality to the software. There exists software that will run as a daemon on all servers to be monitored, including the centralized monitoring server, send reports over a secure channel, by default, provide access control to determine whether that hosts is allowed to send alerts to the daemon, deploy the client on remote hosts over SSH, runs on Windows, Solaris, Linux, AIX, and other platforms, with tons of other features that is available under the GPL license, Samhain. Samhain ( pronounced "Sowen". "sow" as in a female pig ) is a file-integrity program that provides high-level configuration for determining what files and/or directories have been changed, deleted, or added. It can also keep a record of files that have the suid or sgid bit set, as well. For Linux, it can send an alert if a new kernel-module has been loaded. Samhain provides a secure, centralized logging facility by having the client(s), that perform the integrity checks, on servers, send encrypted reports to a remote server. Samhain provides a ton of extra features that are very well documented in the manual that comes along with the distribution. Of course, this series of articles will give you a real-world working example of how to deploy Samhain. Installing Samhain The central logging server will be called pango.. To install Samhain download the samhain tarball, verify the pgp signatures, and extract it. Linux: tar xzvf samhain-x.x.x.x.tar.gz Solaris & AIX: gzip -dc samhain-x.x.x.x.tar.gz | tar xvf - ############################################################# SERVER INSTALL -- ONLY NEEDED FOR THE CENTRAL FILE-INTEGRITY SERVER If you are using RPMS then you will need to download the mysql-devel package in order to compile Samhain with MySQL support FILE INTEGRITY SERVER...IN THIS CASE, pango.. Samhain server install configured to log to a mysqldatabase: cd / /samhain-x.x.x ./configure --enable-network=server --with-database=mysql --enable-xml-log --with-libs=-L/usr/lib/mysql/ -with-cflags=-I/usr/include/mysql make make install NOTE: the " --with-libs=-L/usr/lib/mysql/ " and " --with-cflags=-I/usr/include/mysql " are specified, explicitly, because on Red Hat the configure script doesn't properly locate the " libmysqlclient.a " library or the " mysql.h " header file. NOTE: On AIX 4.3, the Makefile had to be modified and have the "-O3" optimizations flags removed. These appear to specific to gcc. If gcc is installed on the server then it may work with the modifying the Makefile. This only needs to be done if an optimize error occurs during the " make " process. The "make install" will create a program called yule in /usr/local/bin . Yule is the server that listens on pango. for incoming integrity reports. Its configuration file is /etc/yulerc, by default. The " DatabaseSeverity " directive will have to be specified in the /etc/yulerc file on pango.. DatabaseSeverity=crit DbHostname=pango. DbName=samhain DbTable=log DbUsername=samhain DbPassword=password Be sure that the yulerc file is configured to be readable and writeable only by root. chmod 600 /etc/yulerc The next article will explain how to setup the yulerc file so that the database password (actually the entire yulerc file) and the Samhain daemon can be virtually hidden. Samhain currently supports MySQL and PostGRESQL. The nice thing about logging to a database is that you can then use PHP, Java, PERL or some other language to extract the data and view it over the web or create your own purdy reports. Samhain has a beta program called Beltrane that will do this work for you and provide an interface over the web to view the alerts and logs for clients. END SERVER INSTALL ############################################################# Client install: (See NOTE: for AIX install) cd / /samhain-x.x.x ./configure --enable-network=client --enable-xml-log make make install This will add the samhain configuration file, samhainrc , to /etc and install the " samhain " executable in " /usr/local/sbin ". That executable will be overwritten with the next step. Create a unique 16-digit number that will be added to pango. to validate sending logs to the Samhain server daemon. All logs will be encrypted and sent to pango. in the XML format, which will allow logging to the mysql server. While in the root directory of the samhain source distribution run the command: /usr/local/sbin/samhain_setpwd samhain pudding eg. /usr/local/sbin/samhain_setpwd samhain pudding 1234567890123456 You have to choose a random 16-digit number to pass to the "samhain_setpwd" command. This will create a new executable for samhain in the current directory called, samhain.pudding . The " pudding " is really an arbitrary name, actually it is my sister's nickname. Move that one to the " /usr/local/sbin/ " directory which will overwrite the default samhain executable created during the " make install " process. mv -f samhain.pudding /usr/local/sbin/samhain Copy the 16-digit number to a sheet of paper or open a console on pango.. This number will be used to create the unique checksum to allow this server to authenticate and send logs to pango.. On pango....run the command: /usr/local/sbin/yule -P For example, in the example above. Run the command: /usr/local/sbin/yule -P 1234567890123456 The above command creates this checksum: Client=HOSTNAME@FBE67F98C36DB5DF@30015639090F9CB064937DC58A0E70644B20EEA083AB7 E2BFF6C1D521D7675FD2DDC7BAEB745F59695B342028D548C72E7DFF135D1E9A05987EC 1D503E8FB1E248F035497924C2C1069B6615DDB35E2FA64D3608DFA3BDD53DD8D D7B997A4B8BE0FB2C2BA2F50E0895B8015D795D7B5623FB924CEF3AC8E065FE6D810D971 append the output of the " yule -P " command to the end of the /etc/samhainrc file, under the [Clients] section and change " HOSTNAME " to the name of the server that the number was created on. Configuring the client : The /etc/samhainrc file is heavily documented and provides various levels of file-integrity. It can be configured to check files and directories, that always change, ignore access times, size, check for new files, deleted files, etc.. It can also check for new suid and sgid permissions, it will also send alerts if a file or directory has a uid or gid that doesn't exist on the system. Below are some specific cofigurations added outside of what already exists in the samhainrc file. The default configuration file is very well documented with some examples. Below are some configurations that were added for my setup. ChecksumTest=check SetNiceLevel=19 SetIOLimit=500 SetFilecheckTime=1800 SetMailTime=86400 #Wait for this many messages to accumulate before sending an email SetMailNum=10 #Prevent messages from being echoed to the console SetConsole=/dev/null SetLogServer=pango. #Time between sending TIMESTAMP messages SetLoopTime=86400 Don't send duplicate reports for a modified file: #Takes a yes/no argument ReportOnlyOnce=yes After configuring the Samhain /etc/samhainrc file, create the database. This may take some time, depending on what files and directories it has to create a checksums for and the suid files it has to check. Also, the priority specified in the configuration file can impact how fast the database is created. samhain -t init After the database is created and the steps have been followed above to create a unique key for the host the samhain client is on,start the samhain client samhain -t check -D -e 120 This will run samhain as a daemon ( -D ) and send alerts every 120 seconds ( -e 120 ) to pango.. Use 120 seconds until you are comfortable with your setup then you can set the time between checks longer. Note that in the configuration file the "SetNiceLevel" is set to 19, which means the file check will run quite slow. This will keep the samhain daemon from using up a lot of CPU but it will cause the reports to be delayed when sent to pango.. You may want to set the "SetNiceLevel" to something lower until you have Samhain configured correctly. Be sure to check the /var/log/yule_log file on pango. for any problems with the hosts sending alerts. If Samhain, on pango., doesn't have a valid key for the hosts then it will not accept any alerts from it. A message will be echoed to /var/log/yule_log alerting that the host is invalid. To start the server on pango., in this case: yule -S This will run the yule server in the background. Again, check the /var/log/yule_log file for an error messages with yule starting up or check it to be sure that the yule server started properly. If you started the server after the client, wait a few minutes to see the connection attempts by the clients: tail -f /var/log/yule_log When the connection attempts start and are successful, there will be a lot of information echoed to the /var/log/yule_log file. This information can be tuned up or down depending on how much information you want. There is also an html file in the /var/lib/samhain directory called " yule.html ". This file is updated every 120 seconds, by default. It reads the /etc/samhainrc file for the hosts that are allowed to connect to the yule server and gives their status. It will display whether a client is connected or whether a policy has been sent from that client, etc.. You can create a symbolic link from that location to the webserver directory on pango. and view it anytime. Be sure that you read and understand the security risks involved with creating symbolic links in a web directory. For any monitoring server, I like to use SSH tunneling to access it. Generally, no services are available directly from the public interface. For example, the web server can be forced to listen on the local interface for incoming http requests in the httpd.conf file with the Listen directive set to: 127.0.0.1:80 In order for anyone to connect to the server they will have to be on pango. from the console or they can create an SSH tunnel to access the web server. Conlusion It is hoped that this article provides a good introduction with some of the capabilities of Samhain, how to install it, and set up a centralized file-integrity server. Samhain comes with a detailed manual in the source distribution. The next series of articles will explain other features of Samhain especially how to deploy Samhain, quickly, to multiple servers, hiding Samhain, using the yule server for a remote syslog server, how to setup Beltrane, and sample php and servlet scripts for extracting data from the Samhain log file or database to create customized web-based reports. Special thanks First and foremost, thanks to the Linuxsecurity.com team for their continued support with publishing my articles. Especially, Dave Wreski since I never send him an article on time because I always catch something that isn't right about it at the last minute. Thanks for your patients Dave. ;-) Some LinuxSecurity list members provided a lot of help with proofreading this article and giving suggestions and comments: Emily Ratliff (many thanks!!), Bernard Hoffmann, Matt Hemingway, and Andy Grimm. Thanks to Bone, Chris, Cris, Barium Spring Home for Children ("The Foundation of Duane's Path to Liberation"), Charla, Chrissy, Mr. David, Bob, Donna, CFCC, Pfeiffer University , Leslie, Adam, STG, NCDC, Lauren , Jason, andmutsman for their continued support for all that I do. About the Author Duane Dunston is a Computer Security Analyst at STG Inc. for the National Climatic Data Center in Asheville, NC. He received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS . He writes poetry, just started photography, and hangs out at Old Europe Cafe, Early Girl's eatery (tell'em Duane sent you), and still wakes up every morning ready to go to work. If anybody works at NBC who reads this, tell Ann Curry he says, "Hello", again. . Centralized monitoring is critical today with the large number of servers that are deployed in many . article, discuss, installing, configuring, secure, centralized, file-integrity, program. . Duane Dunston
Get the latest Linux and open source security news straight to your inbox.