LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   How to audit and find who did what with files (external applications included (https://www.linuxquestions.org/questions/linux-security-4/how-to-audit-and-find-who-did-what-with-files-external-applications-included-4175451135/)

mosiac 02-21-2013 10:14 AM

How to audit and find who did what with files (external applications included
 
So I have a server, that recently, had some files missing (not a problem we have back ups and restores are accurate up to a couple hours after modification). But I've been tasked with figuring out who did it.

First thought in my mind would be the owner of said files, or a user in the same group that file belongs to. So, correct me if I'm wrong, but if a file belongs to user1.group1 only user1 or a user that belongs to group1 can make changes to the file or the directory with those permissions; correct? (excluding root and sudo users(me))

Secondly, I have turned on verbose ssh logging as well as file auditing on the directories were things seem to keep going missing. I thought file auditing would catch the person but it apparently only logs actions that take place directly on the server in a terminal. So anything that gets modified by an external program doesn't get logged. I thought openssh verbose logging would catch other programs that make modifications to files and directories (a user accessing a directory via WinScp) but no luck.

Tell me where I'm going wrong, and what I can do to fix it. Please.

linosaurusroot 02-21-2013 11:05 AM

Removing or renaming files depends on write permission to the directory not the file.

If you enabled auditing after the files disappeared you won't see what happened (unless it happens again). But it should report everything it's configured to from boot up to shutdown. Alterations made while booted from a live CD wouldn't show.

mosiac 02-21-2013 11:10 AM

OK so my first assumption is right and that it had to be someone who has access to that directory. As for the auditing I do realize that I won't see what happened the first time since I missed it, but the two times after that I still haven't seen what happened or I'm not looking over the ausearch properly.

For example the files exist in /data/log/reports but I've set up auditing at the level /data/ When I view the audit logs I can see stuff happening in /data and in /data/log/ and in /data/log/exitfiles but for some reason i'm not seeing anything that happened in /data/log/reports. If the directory reports was deleted or moved wouldn't I see an audit log of that action taking place?

chrism01 02-22-2013 01:08 AM

I guess you should show exactly how you're auditing.

mosiac 02-22-2013 07:46 AM

Ok first, here is the guide I followed. Cybercity guide on file auditing.

Next here is the key I set specific to my situation (there are others but nothing has been missing from there)

LIST_RULES: exit,always dir=/data/dl/reports (0xe) perm=rwxa key=reports-file

You can do an ausearch for my key and see everything that has happened in the reports folder and below. But for some reason, I never seem to have information on files that go missing.

unSpawn 02-22-2013 08:38 AM

Could you please attach or post the complete contents of your /etc/audit/audit.rules?

mosiac 02-22-2013 08:54 AM

Quote:

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page
Looks like I need some more rules don't I?

unSpawn 02-22-2013 09:39 AM

Quote:

Originally Posted by mosiac (Post 4897522)
Looks like I need some more rules don't I?

Similar to 'iptables-save' vs 'cat /etc/sysconfig/iptables' this only means you have rules actively loaded that aren't committed (yet): 'auditctl -l' vs 'cat /etc/audit/audit.rules' really. So if you could please post full 'auditctl -l' output?

mosiac 02-22-2013 09:42 AM

Quote:

LIST_RULES: exit,always dir=/data/dl/reports (0xe) perm=rwxa key=reports-file
LIST_RULES: exit,always dir=/data/dl/finance (0xf) perm=rwxa key=Finance-file
LIST_RULES: exit,always dir=/data/dl/business (0xe) perm=rwxa key=business-file
LIST_RULES: exit,always dir=/data/dl/business2 (0xf) perm=rwxa key=business2-file
LIST_RULES: exit,always dir=/data/dl/hr (0xa) perm=rwxa key=hr-file
LIST_RULES: exit,always dir=/data/dl/payroll (0xf) perm=rwxa key=payroll-file
LIST_RULES: exit,always dir=/data/dl/staff (0xf) perm=rwxa key=staff-file
That's my full output from auditctl -l

unSpawn 02-22-2013 11:03 AM

What you wrote amounts to using
Code:

auditctl -a exit,always -S close -S write -S truncate -S ftruncate -S unlink -S unlinkat -F dir=/tmp -k WATCH_this_too
(to some extent because the above won't catch WRITE or CLOSE_WRITE) and your rules looks OK to me. No idea why it won't log.

If we take for example the "/data/dl/reports" directory, what can you tell us about the files it contains and how they get there? Are they dynamically generated files? Or maybe FTPed there? Are they constantly kept open by a writing process? Are they not plain text but for example database tables? Please share anything else we might want to know.

*Unless you are forced to solve this using the audit service another approach you may want to try is using inotify(wait) watching for the modify, close_write, moved_from, delete, delete_self events.

mosiac 02-22-2013 12:12 PM

The files in the reports directory are all .csv files generated by an oracle application and then modified by a human. They aren't always kept open.

How would I use inotify?

unSpawn 02-23-2013 06:54 AM

Quote:

Originally Posted by mosiac (Post 4897630)
How would I use inotify?

Reading 'man inotifywait' should make you end up minimally with something like
Code:

inotifywait -m -e modify -e close_write -e moved_from -e delete -e delete_self -r /data/dl

mosiac 02-25-2013 08:28 AM

Thanks,

I went over the man page and made some tweaks and I'm adding inotify to the logging options. Maybe I'll see something this time.

unSpawn 02-25-2013 08:38 AM

NP. Let us know if it doesn't, OK?


All times are GMT -5. The time now is 12:08 AM.