Stay Ahead With Linux Security Features
security advisory attack A Linux server gets cleaned up after an intrusion. The suspicious process is terminated, credentials are rotated, and the system is rebooted during maintenance. Everything seems secure. A few hours later, the same outbound connection appears again. . Situations like that point to persistence . The attacker no longer needs the original exploit because something on the host continues restoring access behind the scenes. Finding that mechanism is often more important than understanding how the...
Jun 08, 2026 
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026 
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026 
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026 
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026 
Refine features
X Clear Filters Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -1 articles for you...
102
file integrityhost intrusion detectionsecurity alert systemEnhancing Security With AIDE: Host-Based IDS for File Integrity Monitoring
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
Dec 20, 2005 •
102
file integrityosirismass deploymentMass Deployment Of Osiris For Secure File Integrity Management
Osiris is a centralized file-integrity program that uses a client/server architecture to check for changes on a system. A central server maintains the file-integrity database and configuration for a client and at a specified time, sends the configuration file over to the client, runs a scan and sends the results back to the server to compare any changes. Those changes are then sent via email, if configured, to a system admin or group of people. The communication is all done over an encrypted communication channel.. Osiris can be deployed locally or it can be deployed on another continent. One of the major features that makes that possible and secure is the secure communication channel that is used to communicate with the client. Osiris uses SSL for communication between the client and server. Another feature of Osiris is that it is portable across a few platforms including Linux, BSD's, Windows, AIX, Solaris, MacOS, etc.. Osiris has many other features like: logging to syslog emailing alerts filtering out recurring alerts detecting new accounts being created or deleted monitoring kernel modules configuring what attributes of a file to scan manually starting scans scheduling a scan and many other features. It should be noted that the central server or the server maintaining the management console should be kept secure and limited access allowed to the server except for those administering the osiris management console and the clients that will need to communicate with it. By default, the management console will only allow incoming login connections from the localhost (127.0.0.1) and any other hosts will need to be added. Those allowed access to the management console can log onto the server directly or log in remotely with the osiris commandline client, provided their IP is allowed to connect. If the central server is kept secure and a client is compromised and the attacker deletes or kills the osiris client, no problem. The central server maintains theconfiguration file and the database. All that needs to be done is for the client reinstalled on the compromised system, preferrably with a static binary as this article describes, then the admin logins into the management console, pushes a scan config file over, initiates a scan and it will send the results back and compare it against the database on the central server, so you can still see what the attacker did on the computer. This article discusses how to mass deploy Osiris in a Linux environment. This is useful for environments with a large number of computer systems they want to deploy Osiris too. This applies if Osiris is going to be installed and managed locally or 2,000 miles from where the managment console is located. The mass deployment is done using the program "remote_update.pl". It uses SSH to execute commands on multiple machines and logs the output to a file for each system it logs into. It has the ability to only run commands on servers that failed during a previous run. Also, multiple machines can be logged into at once. Since remote_update.pl requires a password that is located in a text file, the program "ccrypt" will be used to encrypt the text file and decrypted on the fly when remote_update.pl is executed. There are other programs that can be used such as GnuPG but ccrypt was chosen because it too is portable across many Operating systms Linux, Solaris, AIX, BSD's, Windows, etc. and can be quickly deployed. Osiris - remote_update.pl - ccrypt - (or some other commandline file encryption program like GnuPG. This tutorial will discuss ccrypt.) If you know how to install Osiris as a static binary on other OS's, please email me with the instructions and I'll add it to this article. Osiris Untar the distributions to " /tmp/ ". /bin/tar -xzvf osiris-x.x.x.tar.gz cd osiris-x.x.x-release First edit the file: "src/install/install.sh " and change the line: INTERACTIVE=1 to INTERACTIVE=0 This will prevent the " remote_update.pl " program from prompting you for input when Osiris is installed on the remote systems. Change any other options you need in that file. If you will be running Osiris on multiple Linux versions, you can compile it as a static binary on one Linux system and then push that binary out to the other Linux systems. If you want to do this, then add this before running ./configure : export CFLAGS="-static $CFLAGS " Now to compile Osiris: ./configure or as a static binary: export CFLAGS="-static $CFLAGS" ./configure /bin/make /bin/make agent /bin/make console 1 (optional) 1 (Note: Run this command to create static binaries of the management console.) In the source directory there will be a tarball created of the agent that was just compiled. It is located under the Osiris source directory in: " src/install " It will have the name format of: osiris-version-release-kernel-version-architecture.tar.gz /bin/ls src/install/ You should see something like: osiris-agent-x.x.x-release-Linux.2.4.26.tar.gz (if you ran: /bin/make console you will also see osiris-console-x.x.x-release-Linux.2.4.26.tar.gz) remote_update.pl Untar the " remote_update.pl " tarball: /bin/tar xzvf remote_update-x.x.tar.gz /bin/cp remote_update-x.x/remote_update.pl /usr/sbin create a directory called " osiris/ " under " /tmp/ ": /bin/mkdir /tmp/osiris cd /tmp/osiris Create the directories: " files/ " and " scripts/ " and a text file named " hosts " and " password " in the root of " /tmp/osiris/ ": /bin/mkdir /tmp/osiris/{files,scripts} /usr/bin/touch /tmp/osiris/{hosts,password} Copy the files that you want to transfer to the directory " files/ " /bin/cp/tmp/osiris-x.x.x/src/install/osiris-agent-x.x.x-release-Linux-2.4.26-1-686.tar.gz /tmp/osiris/files (Optionally you can copy over the management console to some hosts but it is recommended to copy it to only a few computers. In particular, just those that will be managing the Osiris file-integrity program.) Then, create a script that will untar the Osiris distribution and run the install program on the remote systems and put that script in " scripts/ ". Here is a sample script called " Osiris-deploy.sh ": ##################### /tmp/osiris/scripts/Osiris-deploy.sh ########################## #!/bin/sh /bin/tar -xzvf ./files/osiris-agent-x.x.x-release-Linux-2.4.26-1-686.tar.gz # I like to be sure the temporary remote directory is owned by the user that is logging # in so all temporary files and directories are removed /bin/chown -R user:user /home/user/.remote_update/ cd ./osiris-agent-x.x.x-release ./install.sh ##################### /tmp/osiris/scripts/Osiris-deploy.sh ########################## Make the file executable and copy it to the " scripts/ " directory: /bin/chmod +x Osiris-deploy.sh /bin/cp Osiris-deploy.sh /tmp/osiris/scripts/ Next, specify in the " hosts " file a list of hosts, one per line, to deploy Osiris on. For example, ##################### /tmp/osiris/hosts ########################## host1 127.0.0.1 myhost.domain.net ##################### /tmp/osiris/hosts ########################## ccrypt The program ccrypt will be installed based on the distribution you are using, OS, and the format you choose to use. It comes as a static binary, RPM, or source. For debian I ran: /usr/sbin/apt-get install ccrypt Now comes the really imporant part, the " password " file. The remote_update program comes with a sample password file so you can peruse that for more information. Below is an example of how to setup the password file: and a list of passwordsfor root. The remote_update program will try each password until it succeeds or fails. Here is a sample password file called " password ": ##################### /tmp/osiris/password ########################## # 1. Be sure no one is looking over you shoulder during this part! # 2. Be sure you type the passwords correctly. # 3. The username must be at the beginning of the line and the password # has to be one tab over and underneath the username for that particular user. # 4. There are some exceptions to this so read the "example_password.txt" file # in the source directory of remote_update # 5. remote_update will keep trying until there are no more user/password combinations or until it suceeds duane password1 password2 password3 password4 ryan password1 password2 root password1 password2 ##################### /tmp/osiris/password ########################## Immediately encrypt the file with " ccrypt " (or GnuPG): /usr/bin/ccrypt -e password After you type a password to encrypt the file it will give the file a " .cpt " extension. All Together now Be sure that that the " hosts " file is located in the root of " /tmp/osiris/ ". Now you are ready to deploy Osiris with the command: /usr/bin/ccat password.cpt | /usr/sbin/remote_update.pl -v -p - -d /tmp/osiris Here is what is going on. First you decrypt the contents of the " password.cpt " file ( /usr/bin/ccat password.cpt ) and pipe it into the remote_update program and tell it to get the password from standard input: ( | /usr/sbin/remote_update.pl -p - ) then specify the directory where the scripts and files to copy over is located ( -d /tmp/osiris ). I have a sick and personal thing about seeing stuff moving on my terminals so I specified the verbose switch ( -v ). For each host specified in the hosts file under " /tmp/osiris" there will be a " .log " file created with the verbose output from the remote system under the " /tmp/osiris/ " directory. This is the same output as the ( -v ) switch on the commandline. If there are any errors with installing osiris on some hosts you can specify the ( -f ) switch and remote_update will only retry the hosts that failed. /usr/bin/ccat password.cpt | /usr/sbin/remote_update.pl -v -f -p - -d /tmp/osiris Under the directory " /tmp/osiris " there will be a " .log " file for each hosts specified in the " hosts " file. Now you have three great programs to work with, Osiris, remote_update.pl, and ccrypt. Remote_update.pl can be used for a wide variety of purposes when you are administering a lot of computer systems at once. Duane Dunston received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS. Hey,Ann Curry!. Osiris can be deployed locally or it can be deployed on another continent. One of the major features. osiris, centralized, file-integrity, program, client/server, architecture, check. . Duane Dunston
Nov 22, 2004 • 
102
file integrityopen source softwaresecurity configurationInstall Samhain For Centralized File Integrity Monitoring On Linux
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
Aug 09, 2002 • 102
intrusion detectionfile integritysecurity incidentEffective System Monitoring And Intrusion Detection For Linux Admins
Have you ever suspected or been notified that your Linux system is under attack? How do you determine whether your system has been compromised? This document is intended to explain how an administrator can implement basic security incident investigation techniques.. r> Background A s mentioned in the Intrusion Detection Primer ,the process of preventing and detecting security breaches by monitoring user and application activity is known as intrusion detection. It is a proactive process that requires the constant attention. In this document I explain step-by-step how to monitor user and application activity using standard Linux/Unix commands. This document is intended to be read by novice Linux who are interested in security. Who are the intruders and where are they from? Intruders may be curious teenagers, disgruntled employees, or even professional criminals from rival companies. Attacks can originate from practically anywhere in the world via the Internet or dialup lines. This fact makes intrusion investigation a difficult task. Types of Intrusion Detection Intrusion detection can be broken down into five types. These types include file integrity checking, log file monitoring, host based ID (intrusion detection), network based ID, and administrator based monitoring. Checking file Integrity: This is the process of checking files to determine whether unauthorized changes to files have been made. Many times the program Tripwire is used to automate this process. . Master essential Linux commands for intrusion detection and efficiently analyze security breaches.. Intrusion Detection, System Monitoring, Linux Administration, Incident Response. . Brittany Day
Jun 29, 2000 • 
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More