You are not logged in.

#1 2017-06-29 03:44:16

Horizon_Brave
Operating System: Linux-Nettrix
Registered: 2015-10-18
Posts: 1,473

Linux System Audit Tool?>

Hey everyone... so I'm posting this in sys. administration, but I mean to make use of the idea in a home laptop. Does anyone know of a linux Audit tool, that is scriptable, that can keep track of changes, and differences made to the file system? For example, if I delete or a program changes something in /home/

likewise any changes in /etc/ or /var/ etc.. from one day to the next etc?   I know of heavier duty security tools like OSSEC, but that seems a bit...heavy handed, and more functionality that I may make use of. Anyone know of something light weight, that you can run to scan the OS, and sort of check again a prior "Gold Standard" image that you make during the initial setup, or check against a list that you say is "correct"?

If I had more time, this sounds like it would be a sort of fun Bash Scripting practice... and I may still attempt to write something very rudimentary in Bash or C, to explore and stretch my skills... but I would prefer something more professional... Any suggestions?


"I have not failed, I have found 10,000 ways that will not work" -Edison

Offline

#2 2017-06-29 06:21:28

Naik
Member
From: Lipsia
Registered: 2015-10-03
Posts: 147

Re: Linux System Audit Tool?>

Hey Horizon_Brave!

I sometimes let my system be checked by Lynis which should be in the repos or can be obtained here.
To run it to the full extend of its capabilities there is a bunch of dependencies (like audit, fail2ban, needrestart etc) but i think it is worth it whenever you think security of your system could be in danger.

If it is really only about having an eye on unwanted (file)changes maybe the audit-daemon alone will do?

When it comes to programming stuff like this by ones self my advice will be of none (to negative) help, so you will have to wait for others to jump in on that part of the question.

`till then have a good time.

naik --greetz


"Kaum macht [Mensch]* es richtig, funktioniert es sofort!"
BL-Kitchen on GitHub

Offline

#3 2017-06-29 06:30:26

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: Linux System Audit Tool?>


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#4 2017-06-29 09:19:22

Naik
Member
From: Lipsia
Registered: 2015-10-03
Posts: 147

Re: Linux System Audit Tool?>

^ sounds good and is also used by lynis package...


"Kaum macht [Mensch]* es richtig, funktioniert es sofort!"
BL-Kitchen on GitHub

Offline

#5 2017-06-29 09:23:26

twoion
ほやほや
Registered: 2015-08-10
Posts: 2,149

Re: Linux System Audit Tool?>

You can use both selinux and apparmor in a 'permissive mode', which means they will log audit trails of what's going on but not impose access control rules.

I recommend apparmor in particular because it is easy to configure. Create an empty, basic profile and add directories of interest (globbing is possible). Run in permissive mode, and enjoy the audit messages in your syslog.

Offline

#6 2017-06-29 16:07:44

Horizon_Brave
Operating System: Linux-Nettrix
Registered: 2015-10-18
Posts: 1,473

Re: Linux System Audit Tool?>

Thanks for the replies everyone, very helpful. Yea HoaS, I knew of tripwire, but again just seemed like a bit of overkill from what I briefly read from it.  I think I'll give both tripwire and the audit-daemon a go. Probably opting for audit-daemon first as it seems like a lighter weight option?... Twoion is apparmor definitely reliant on selinux?

I'll test each out and see what I can see... Thanks again!


"I have not failed, I have found 10,000 ways that will not work" -Edison

Offline

#7 2017-06-29 16:43:19

Naik
Member
From: Lipsia
Registered: 2015-10-03
Posts: 147

Re: Linux System Audit Tool?>

I would like to see what you saw to so please be so kind and post back your findings.

naik --thanks-in-advance


"Kaum macht [Mensch]* es richtig, funktioniert es sofort!"
BL-Kitchen on GitHub

Offline

#8 2017-06-29 17:16:50

twoion
ほやほや
Registered: 2015-08-10
Posts: 2,149

Re: Linux System Audit Tool?>

Horizon_Brave wrote:

Thanks for the replies everyone, very helpful. Yea HoaS, I knew of tripwire, but again just seemed like a bit of overkill from what I briefly read from it.  I think I'll give both tripwire and the audit-daemon a go. Probably opting for audit-daemon first as it seems like a lighter weight option?... Twoion is apparmor definitely reliant on selinux?

I'll test each out and see what I can see... Thanks again!

Eh, I meant 'either or'. You should not be using both at the same time.

Offline

#9 2017-07-04 21:52:05

Horizon_Brave
Operating System: Linux-Nettrix
Registered: 2015-10-18
Posts: 1,473

Re: Linux System Audit Tool?>

Alright, so I've had a chance to play around with auditd and the auditctl suite. Gotta say, not *exactly* what I was looking for. Unfortunately a lot of the auditing tools are mostly security-centric, so they all feature a lot of functions and output that I'm not really needng. That being said from using auditd it is very streamlined, and pretty slick for a command line tool. It took some getting used to, to set it up, but once you have a few of the more basic syntax and logging files down, it's pretty cool! So a big thanks to Naik for this.

Anyway let me explain my use case for needing an audit tool, and then I'll post my review/guide to getting it setup and some basic usage. (nothing that can't be quickly googled...but hey maybe it'll help someone, because I did find some subtle difference between the official redhat version and this one...or atleast the red hat documentation may be outdated.

My Usage Need:

So I have Bunsen Labs running (currently) from two different machines. One which is running Stretch (stable) with basic Hydrogen is on an actual laptop. The other is running as Stretch (Stable) with Helium-dev  (which still says Hydrogen in the lsb_release...?) as a VM on my other laptop. So I'd like to keep track of changes that I make to one system, mostly the VM, which will be more experimental. I'd like to be able to get a human readable list of things I install and remove, changies made to important files, moving things around, additions to startup scripts etc... This way if I need to ever bring up another VM or apply those changes to my Stretch|Hydrogen laptop I can have a list of all configurations I've made. 

Auditd And a Simple Guide and What It's Like:

So to get the auditd suite, the install process is literally just the normal apt install auditd. It'll need and bring with it the auspd plugin library as well.

What It Covers:

Basically, there's three types of Audit rules that can be specified:
    • Control rules — allow the Audit system's behavior and some of its configuration to be modified.
    • File system rules — also known as file watches, allow the auditing of access to a particular file or a directory.
    • System call rules — allow logging of system calls that any specified program makes.

I think it's easiest to make the file system watches. Like I want to keep track of anything I install, so putting a watch the /var/lib/dpkg/status  file it can track whenever something is added... This is probably a very very cludgy way to go about it... and if anyone has any other suggestions, I'm all ears!
I think I'm also going to try to put a watch for the /usr/bin/apt-get command.. but may return a lot of false positives for actual installation of packages...
I think I could likewise make a watch on the apt system call but I'm not quite sure what syscall it uses.. anyway that's a fight for a different day.

Components

The following is from the auditd website I believe

The program itself has several components:

Kernel:

    • audit: hooks into the kernel to capture events and deliver them to auditd
   
Binaries:
    • auditd: daemon to capture events and store them (log file)
    • auditctl: client tool to configure auditd
    • audispd: daemon to multiplex events
    • aureport: reporting tool which reads from log file (auditd.log)
    • ausearch: event viewer (auditd.log)
    • autrace: using audit component in kernel to trace binaries
    • aulast: similar to last, but instaed using audit framework
    • aulastlog: similar to lastlog, also using audit framework instead
    • ausyscall: map syscall ID and name
    • auvirt: displaying audit information regarding virtual machines
Files:
    • /etc/audit/audit.rules: used by auditctl to read what rules need to be used
    • /etc/audit/auditd.conf: configuration file of auditd
    • /var/log/audit/audit_log file:  The file that logs your triggered events.

So far I've only used ausearch, auditctl, and aduitd, though if I get some time over the weekend I may go through each of them and see what they do and how they can help..



Configuration

The configuration of the audit daemon is arranged by two files, one for the daemon itself (auditd.conf) and one for the rules used by the auditctl tool (audit.rules).

/etc/aduit/auditd.conf
The /etc/audit/ directory has tight permissions on by default. To allow yourself access, use sudo -i to access root. That or change the permissions of the directory to 777. (not recommended though) Remember you can't use 'sudo cd' since cd isn't a command.

The file /etc/audit/auditd.conf configures the Linux audit daemon (auditd) with focus on where and how it should log events. It also defines how to deal with full disks, log rotation and the number of logs to keep. What I changed in my conf file is, I brought down the amount of concurrent logs, and their max space. As well as I changed the output logs from RAW to ENRICHED. The RAW output is a bit messy (see the paste at the end of this post for an example). The ENRICHED version is much tidier and resolves the names of a lot of things.


/etc/audit/audit.rules
To configure what events should be audited, the audit framework uses a rules file named audit.rules. This is the default configurations. I've found that anything added here gets written over upon reboot.
The file to write, and properly keep persistent rules is
/etc/audit/audit.d/audit.rules


Creating Rules with auditctl Command

Active rules can be displayed by running auditctl with the -l parameter.

    # auditctl -l
    -w /etc/passwd -p wa  -k passwd-changes
   
If you wish to remove the rules use auditctl -D.

# auditctl -D
No rules


Time to start with monitoring something, let’s say the /etc/passwd file. We put a ‘watch’ on the file by defining the path and actions to look for:

    #auditctl  -w /etc/passwd -p wa
   
By defining the path (-w)   and action (-p) , we instruct it to what directory or file to watch for. The "-p wa" is to  determine what action on the specified file or directory that is being watched for, will trigger auditd.
For example on the /etc/passwd file we have wa. This means that if anyone or thing writes to it, or tries to change an attribute it will trigger an alarm. This is logged to the log file we have set in /var/log/auditd/audit.log
    • r = read
    • w = write
    • x = execute
    • a = attribute change

To define a rule that logs the execution of the /sbin/insmod command, which inserts a module into the Linux kernel, execute the following command:

   

# auditctl -w /sbin/insmod -p x 

To enable and disable the Audit logging configuration. This most likely is the same thing as running systemctl restart auditd.service

# auditctl -e 1

For example the above enables the audit process. I think a 0 here would disable it.


To see the status of the Audit system, for example:

    # auditctl -s
    AUDIT_STATUS: enabled=1 flag=2 pid=0 rate_limit=0 backlog_limit=8192 lost=259 backlog=0

System Call Rules:

Certain rules can be created, not to monitor files or directories, but for when someone or some programs tries to make calls to the system kernel. This could lead to malicious behavior so you can set certain more dubius calls, to be watched for:

To set auditd to watch and monitor system calls:

auditctl -a action, filter  -S  system_call  -F  field=value 

where:

-a <action> can be either:  always or never.

<filter> specifies which kernel rule-matching filter is applied to the event. The rule-matching filter can be one of the following: task, exit, user, and exclude.

-S <system_call>  specifies the system call by its name. A list of all system calls can be found in the /usr/include/asm/unistd_64.h file. Several system calls can be grouped into one rule, each specified after a -S option. Each system call would need it's own -S flag. 

**note for the above, atleast in my own system, I don't have this file or even the asm directory, so I'm not sure if this is some Red-hat specific directory..I even did a search for the file on the file system, and turns up empty. Either way I'll probably need to get a list of system calls and what each means at some point...I'm going to assume it's a massive list  roll **

-F  <field=value>  specifies additional options that furthermore modify the rule to match events based on a specified architecture, group ID, process ID, and others.

System Call Rules Examples:

Honestly, I haven't played around too much with the system calls, So I can only relate to what the docs say at this point. To define a rule that creates a log entry every time the adjtimex or settimeofday system calls are used by a program, execute the following command:

# auditctl -a always,exit -S adjtimex -S settimeofday -k time_change

Oh and btw, notice above that the -k option is used..

-k <arbitrary name> is a key that can be applied to each rule you make to reference it later on when searching.  This name is what shows up in the logs, so you can name it something specific so you know which rule was triggered.

Multiple system calls can be specified but each will need it's own -S flag.


Defining Persistent Rules /etc/audit/audit.rules

To make your rules permanent, you need to add them to the file /etc/audit/rules.d/audit.rules.

Whenever the auditd service is started, it will activate all the rules from the file. This includes the silly -D option at the top, that's goal is to REMOVE all the rules. I commented this out just to avoid any trouble..

This file uses the same auditctl command line syntax to specify the rules, except for the auditctl word itself. Any empty lines or any text following a hash sign (#) is ignored.

-w /etc/passwd -p wa -k passwd_changes
-w /etc/selinux/ -p wa -k selinux_changes
-w /sbin/insmod -p x -k module_insertion

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change

The above 4 lines define persistently set rules in the /etc/audit/audit.d/audit.rules file.

Preconfigured Rules Files:

In the /usr/share/doc/audit-version/ directory, the audit package provides a set of pre-configured rules files according to various certification standards. These are mostly NIST and security standards for business environments, so I'll skip over this.


The Logs:

By default, the Audit system stores log entries in the /var/log/audit/audit.log file; if log rotation is enabled, rotated audit.log files are stored in the same directory.


Using the ausearch Tool to Scan Logs:

The ausearch utility allows you to search Audit log files for specific events. By default, ausearch searches the /var/log/audit/audit.log file.

Something to remember, you probably always want to use the -i option when using ausearch. It converts the pesky UID user number to it's actual username in the output.


To search the logs for a certain directory or file, you can use the -f parameter and pipe it to more or less.

# ausearch -i -f /etc/passwd | less

To search logs for a watched directory or file, but to narrow it down to a particular rule use:

# ausearch -i  /etc/passwd -k password_monitor | less

See the use of -k test_watch here? Even if you have a dozen more rules logging different things on the same file, by using a key string, you can tell ausearch to only list what you're interested in

To search for all activity just for today, you can specify the time with the -ts

# ausearch -ts today -k password-file

or

# ausearch -ts today -f /etc/passwd

The -ts and -te flags are for time-start and time-end parameters. Search for events with time stamps equal to or after the given end time. You may also use the word: now, recent, today, yesterday, this-week, this-month, this-year. Today means starting at 1 second after midnight



To search the /var/log/audit/audit.log file for failed login attempts, use the following command:

# ausearch --message USER_LOGIN -i | grep failed

or

#ausearch --message USER_LOGIN -i | grep <username>

The above will look for all login attempts for the user specified in <username>
Note however the USER_LOGIN is the literal syntax for the command. Don't replace it with an actual user name.


To search for all failed system calls from yesterday up until now, use the following command:

# ausearch --start yesterday --end now --message SYSCALL -sv no -i

The -sv is success-value. It can either be yes or no. So the above is saying to return all syscalls that failed from yesterday to  right now.


There's a lot more syntax and features in the man pages for ausearch. Like I said, I probably need to get more familiar with the actual system call names and how they're referenced. But for me, for now, using the file watches and looking up by that in the logs seems good enough.

Next Steps...

So the next thing for me is the see how to get the output from the reports of my rules, to generate a much much easier formatted report (aureport I'm assuming), put into a text file, and email it to myself, and or atleast just save it where I can grab it. Doesn't sound too hard actually, I think even I can handle it!



Also I saved this to the end as not to take up a ton of space with a wall of text, but in case you're curious here's a same output of one entry into the log from a triggered event:

type=PROCTITLE msg=audit(07/04/2017 17:02:30.935:141) : proctitle=/usr/bin/dpkg --status-fd 25 --no-triggers --unpack --auto-deconfigure /var/cache/apt/archives/neofetch_2.0.2-1_all.deb
type=PATH msg=audit(07/04/2017 17:02:30.935:141) : item=2 name=/var/lib/dpkg/status-old inode=1026 dev=08:06 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=CREATE
type=PATH msg=audit(07/04/2017 17:02:30.935:141) : item=1 name=/var/lib/dpkg/ inode=186 dev=08:06 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT
type=PATH msg=audit(07/04/2017 17:02:30.935:141) : item=0 name=/var/lib/dpkg/status inode=1026 dev=08:06 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL
type=CWD msg=audit(07/04/2017 17:02:30.935:141) : cwd=/
type=SYSCALL msg=audit(07/04/2017 17:02:30.935:141) : arch=x86_64 syscall=link success=yes exit=0 a0=0x560a009ab300 a1=0x560a007d15c0 a2=0xffffffff a3=0x73 items=3 ppid=1219 pid=1239 auid=kingcaesar uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=2 comm=dpkg exe=/usr/bin/dpkg key=package_monitor 

Last edited by Horizon_Brave (2017-07-05 15:42:26)


"I have not failed, I have found 10,000 ways that will not work" -Edison

Offline

#10 2017-07-05 08:10:21

Naik
Member
From: Lipsia
Registered: 2015-10-03
Posts: 147

Re: Linux System Audit Tool?>

Hey, there!

Thanks for the feedback on my suggestion and all the work you put into this "howto".
I do believe that there are more simple solutions for the use case you just described but I didn`t know what you where up to and whenever it comes to security related tasks i would recommend to think big! wink

With this said i almost feel like it has all been said and just wanted to add that ElTyporonie seems to have messed up things a little:

Horizon_Brave wrote:
# ausearch -i -k  /etc/passwd | less

See the use of -k test_watch here? [...]

naik --greetz


"Kaum macht [Mensch]* es richtig, funktioniert es sofort!"
BL-Kitchen on GitHub

Offline

#11 2017-07-05 15:40:15

Horizon_Brave
Operating System: Linux-Nettrix
Registered: 2015-10-18
Posts: 1,473

Re: Linux System Audit Tool?>

Naik wrote:

Hey, there!

Thanks for the feedback on my suggestion and all the work you put into this "howto".
I do believe that there are more simple solutions for the use case you just described but I didn`t know what you where up to and whenever it comes to security related tasks i would recommend to think big! wink

With this said i almost feel like it has all been said and just wanted to add that ElTyporonie seems to have messed up things a little:

Horizon_Brave wrote:
# ausearch -i -k  /etc/passwd | less

See the use of -k test_watch here? [...]

naik --greetz


Ah good eyes! I tried to blend my own notes and observations with what was already documented. That one definitely slipped by me!  And yes I agree, with what I"m trying to do this definitely is not ideal, but hey, it's a good learning experience either way. What I originally was looking for is more tracking of changes made to files, and packages installed/removed etc. It *could* be done with this..but it seems that it would require a super fine level of granularity...


"I have not failed, I have found 10,000 ways that will not work" -Edison

Offline

#12 2018-02-24 03:57:13

rra
New Member
Registered: 2017-01-03
Posts: 1

Re: Linux System Audit Tool?>

sudo apt-get install aide

AIDE does just what you are asking and nothing more. It's easy to exclude files or directories that change often, or only report on changes to permission/ownership. Similar to Tripwire but GPL.

-rick

Offline

Board footer

Powered by FluxBB