CIS 290 LINUX Security Tripwire file integrity and change management tool and log monitoring

Security Policy Data integrity -Assuring that the object (files, systems registry) and infrastructure items (server data, Web page content, router configurations etc.) remain in a desired good state. -Deviations from the desired state are identified via an integrity check. -Alerts will be generated and routed to the appropriate parties, and other software systems, enabling rapid recovery Detect improper modification

Tripwire Runs in active or passive mode Gives system admins ability to monitor for added, deleted & modified files Is now a commercial product (note the package level) Checks for changes in file attributes, e.g.: – size, – access & modification timestamps, – permissions, – inode number – signature (more on signature later)

Tripwire UNIX File system Permissions Inode number Number of links (i.e. inode reference count) User ID of owner Group ID of owner File type File size File is expected to grow Device number of the disk on which the inode is stored Device number of the device to which the inode points. Number of blocks allocated Access timestamp Modification timestamp Inode creation / modification timestamp CRC-32 hash of the data MD5 hash of the data SHA hash of the data HAVAL hash of the data

Checking Techniques Established techniques: maintaining checklists, comparison copies, checksum records or backup tapes These methods are costly, prone to error and susceptible to easy spoofing Intruders w/ root privileges can alter checklists or compromise utilities (eg “ls”) Changes to a file can be made w/out changing its length or checksum.

Tripwire files Configuration file (tw.cfg) derived from twcfg.txt Policy file (tw.pol) derived from twpol.txt – list of files & directories to be monitored – their associated selection mask (list attributes that can safely be ignored) Database file --describes each “file” – automatically generated – set of file names, inode attribute values, signature info., associated tw.pol entry

Tripwire Component Overview generate newly generated database tw.config file old database compare apply ignore-masks Tripwire report Files residing on system

Integrity Checking Mode Generate new database Compare new database with baseline db Produce report of added & deleted files Apply selection mask to modified files

Syslog (r)syslog is a utility for tracking and logging all manner of system messages from the merely informational to the extremely critical. Sysogs stored in In LINUX, system logs are stored in /var/log. System messages are recorded in /var/log/messages. Other OS’es may use different files in different directories (e.g. /var/adm). Each system message sent to the syslog server has two descriptive labels associated with it that makes the message easier to handle. - The first describes the function (facility) of the application that generated it. For example, applications such as mail and cron generate messages with easily identifiable facilities named mail and cron. - The second describes the degree of severity of the message.

Syslog Severity:Level: Keyword: Description 0 emergencies System unusable 1 alerts Immediate action required 2 critical Critical condition 3 errors Error conditions 4 warnings Warning conditions 5 notifications Normal but significant conditions 6 informational Informational messages 7 debugging Debugging messages

Syslog The files to which syslog writes each type of message received is set in the /etc/rsyslog.conf configuration file. In older versions of Fedora, this file was named /etc/syslog.conf. This file consists of two columns. The first lists the facilities and severities of messages to expect and the second lists the files to which they should be logged. By default, RedHat/Fedora's /etc/rsyslog.conf file is configured to put most of the messages in the file /var/log/messages. Example: *.info;mail.none;authpriv.none;cron.none /var/log/messages Note other services may record messages in other files (e.g. sendmail) Syslog is also a network service. A common implementation is to forward system info to a common syslog server. Logs compressed,,stored and optionally ed by the logrotate function. Definitions stored in /etc/logrotate.conf and /etc/logrotate.d

Logrotate Log management for LINUX and UNIX Basic config file is /etc/logrotate.conf Individual package package config files in/etc/logrotate.d usually configured during package installation Each config file specifies logfile list, rotate interval, rotation count, log size, compression options, postrotate command to perform a function after the log has been copied.

Logrotate automation UNIX systems require use of a specific CRON job LINUX automatically includes logrotate in ANACRON. ANACRON is an automatic CRON list created for system functions such as logtotate or tripwire. It is an extension of CRON. See /etc files anacron, cron.daily, cron.weekly, cron.monthly. Also /var/spool/anacron

Logwatch Default freeware log monitoring tool Runs in Perl Numerous other “pay for play” tools: -Logrobot -Nagios -Logstash -Graybar

Logwatch files System specific config: /etc/logwatch Default config: /usr/share/logwatch/default.conf/ Distro specific config: /usr/share/logwatch/distro.conf/ Directories: conf /*.conf, conf/logfiles, conf/services scripts/services Always copy default, distro files to local /etc/logwatch for modification Priority sequence: - /etc/logwatch - /usr/share/logwatch/distro.conf - /usr/share/logwatch/default.conf

Security today Governement regulations: -HIPAA -PCI-DSS -SOX No clear text applications – FTP, TELNET, NFS, RCP, RCMD, HTTP Restricted access, minimum to do the job Most legacy 3 rd party apps are now commercial products: - ssh - Nagios - Tripwire - PGP Some have freeware equivalents, but fewer over time.