DAudit

The DAudit system consists of several modules: System_audit, System_netlink, System_host. We also supply you a template to create your own module. You select which modules to load using a simple configuration file. Any number of clients are supported.

Modules

The modules are loaded into shared libraries and loaded at run-time:

  • System_audit - uses the auditd(8) subsystem to collect information that you have configured using auditctl. You can monitor any events that auditd supports. This system collects and processes the data in realtime.
  • System_netlink - uses the netlink subsystem to collect process starts, forks and exits. This system collects and processes the data in realtime.
  • System_host - collects cpu and disk utilization and reports it every 5 minutes. You can log the data or view it live on this web system. Reports can also be generated on logged data.

Reporting

The modules collect the data and send it to the bunny server for reporting to make analysis easier. You can create scheduled reports and have them emailed to you.

Since we process the data in realtime, you can also generate reports of new or unique activity on the systems and generate alerts.

Example

How to audit Firefox activity

Let's say you want to know what Firefox is doing. The first step is to get the auditd(8) system running. We'll need to have the audispd system too, so edit /etc/audisp/plugins.d/af_unix.conf and set "active" to "yes":

# This file controls the configuration of the
# af_unix socket plugin. It simply takes events
# and writes them to a unix domain socket. This
# plugin can take 2 arguments, the path for the
# socket and the socket permissions in octal.

active = yes
direction = out
path = builtin_af_unix
type = builtin 
args = 0640 /var/run/audispd_events
format = string

Start and enable the auditd system:

  1. systemctl enable auditd
  2. systemctl start auditd

You should now have auditd running and the named pipe /var/run/audispd_events should exist. To configure what events auditd will track, you use auditctl. In this example I track bind, connect, and open so I can see what sockets and files are being used:

auditctl -a never,exit -F arch=b64 -S connect,openat -F exe=/usr/bin/syslog-ng
auditctl -a always,exit -F arch=b64 -S bind,connect,openat -F auid!=1 -F euid!=0 -F key=opens
auditctl -a always,exit -F arch=b32 -S bind,openat,connect -F auid!=1 -F euid!=0 -F key=opens
auditctl -a always,exit -F arch=b32 -S open -F exit=-EPERM -F euid!=0 -F key=openf
auditctl -a always,exit -F arch=b64 -S open -F exit=-EPERM -F euid!=0 -F key=openf

You can put them in a startup file so they get loaded automatically, but now the system should be collecting information and you can check by looking in /var/log/audit/audit.log.

To get the client software, you'll need a free account on this server to download the source code. After you create your account:

  1. Sign on, go to "my account" and enable the "daudit" bundle (in the bundles tab)

  2. Click on the "companies" tab and create a company

  3. Go to "my account" and click on your company
  4. Click on the "devices" tab and add a device

  5. Download the certificate, password and certificate password
  6. Click on the "sites" tab and add a site using that device

  7. Download the source code in the "downloads" tab
  8. Extract the source file and follow the README.txt file to build it
  9. Edit the "dssClient.conf" file and add your information
  10. Start the dssClient program

Now when you sign on and go to your company's main screen, you should see realtime activity. Go to the "maintenance" tab and add some scheduled reports. I would add a report for "unique" records since we strip out the duplicates you've already seen.

Your first report will contain all the files and sockets opened, using the summary reports here is helpful. Here's a sample daily summary report:

By Host - AuditD

Host oberon
    /usr/lib/firefox/firefox	198135
      openat 191385
        /usr/share/ca-certificates/trust-source/blacklist 7492
        /usr/share/ca-certificates/trust-source/anchors 7490
        /etc/ca-certificates/trust-source/blacklist 7492
        /etc/ca-certificates/trust-source/anchors 7494
        /etc/hosts 491
        /proc/self/mountinfo 47123
        /run/systemd/machines/push.services.mozilla.com 126
       ....
       lots of deleted stuff here!
       ....

The number at the end of the line is how many times that was used. This summary is really too much to check each day, so we process the data in realtime to find only the "new and unique" records, based on an index you can specify, or use the default values.

After the first report, you can view just the "new and unique" records, for instance:

By Host - AuditD

Host oberon
    /usr/bin/tcpdump	1
      setsockopt 1
    /usr/lib/firefox/firefox	3
      connect 3
        35.82.253.63 3

Now we just see the activity that we haven't seen before. Let's say we want to know why Firefox is connecting to some seemingly random Amazon Web Services Accounts, we'll need to use tcpdump.

Let's say I want to see what's going to the 35.* network, I can simply run tcpdump and see. I'll use udp since the port is "0" above:

tcpdump -vv udp net 35

11:29:15.001007 IP (tos 0x0, ttl 64, id 30507, offset 0, flags [DF], proto UDP (17), length 71)
    oberon.36455 > 64.151.110.139.domain: [bad udp cksum 0xbb9a -> 0x2472!] 14334+ A? push.services.mozilla.com. (43)
11:29:15.002490 IP (tos 0x0, ttl 64, id 30508, offset 0, flags [DF], proto UDP (17), length 73)
    oberon.35473 > 64.151.110.139.domain: [bad udp cksum 0xbb9c -> 0xa908!] 59878+ PTR? 139.110.151.64.in-addr.arpa. (45)
11:29:15.018491 IP (tos 0x20, ttl 48, id 19449, offset 0, flags [none], proto UDP (17), length 125)
    64.151.110.139.domain > oberon.36455: [udp sum ok] 14334 q: A? push.services.mozilla.com. 2/0/0 push.services.mozilla.com. CNAME autopush.prod.mozaws.net., autopush.prod.mozaws.net. A 52.26.249.11 (97)
11:29:15.065150 IP (tos 0x20, ttl 50, id 19455, offset 0, flags [none], proto UDP (17), length 136)
    64.151.110.139.domain > oberon.35473: [udp sum ok] 59878 NXDomain q: PTR? 139.110.151.64.in-addr.arpa. 0/1/0 ns: 110.151.64.in-addr.arpa. SOA ns.rackspace.com. hostmaster.rackspace.com. 1539013308 3600 300 1814400 300 (108)
11:29:26.659994 IP (tos 0x0, ttl 64, id 33797, offset 0, flags [DF], proto UDP (17), length 66)
    oberon.57983 > 64.151.110.139.domain: [bad udp cksum 0xbb95 -> 0xb089!] 50461+ A? sockets.nextdoor.com. (38)
11:29:26.660615 IP (tos 0x0, ttl 64, id 33798, offset 0, flags [DF], proto UDP (17), length 66)
    oberon.57983 > 64.151.110.139.domain: [bad udp cksum 0xbb95 -> 0xa389!] 53762+ AAAA? sockets.nextdoor.com. (38)
11:29:26.676423 IP (tos 0x20, ttl 50, id 20284, offset 0, flags [none], proto UDP (17), length 114)
    64.151.110.139.domain > oberon.57983: [udp sum ok] 50461 q: A? sockets.nextdoor.com. 3/0/0 sockets.nextdoor.com. A 35.82.253.63, sockets.nextdoor.com. A 52.43.176.122, sockets.nextdoor.com. A 44.230.16.148 (86)
11:29:26.680684 IP (tos 0x20, ttl 50, id 20286, offset 0, flags [none], proto UDP (17), length 151)
    64.151.110.139.domain > oberon.57983: [udp sum ok] 53762 q: AAAA? sockets.nextdoor.com. 0/1/0 ns: nextdoor.com. SOA ns-1005.awsdns-61.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 (123)
11:29:26.935602 IP (tos 0x0, ttl 64, id 33820, offset 0, flags [DF], proto UDP (17), length 66)
    oberon.33009 > 64.151.110.139.domain: [bad udp cksum 0xbb95 -> 0x5f54!] 30689+ A? sockets.nextdoor.com. (38)
11:29:26.955839 IP (tos 0x20, ttl 50, id 20342, offset 0, flags [none], proto UDP (17), length 114)
    64.151.110.139.domain > oberon.33009: [udp sum ok] 30689 q: A? sockets.nextdoor.com. 3/0/0 sockets.nextdoor.com. A 35.82.253.63, sockets.nextdoor.com. A 52.43.176.122, sockets.nextdoor.com. A 44.230.16.148 (86)
11:29:51.666527 IP (tos 0x0, ttl 64, id 40542, offset 0, flags [DF], proto UDP (17), length 66)
    oberon.43779 > 64.151.110.139.domain: [bad udp cksum 0xbb95 -> 0x3f53!] 28112+ A? sockets.nextdoor.com. (38)
11:29:51.666923 IP (tos 0x0, ttl 64, id 40543, offset 0, flags [DF], proto UDP (17), length 66)
    oberon.43779 > 64.151.110.139.domain: [bad udp cksum 0xbb95 -> 0x81e5!] 11043+ AAAA? sockets.nextdoor.com. (38)
11:29:51.685185 IP (tos 0x20, ttl 49, id 24960, offset 0, flags [none], proto UDP (17), length 114)
    64.151.110.139.domain > oberon.43779: [udp sum ok] 28112 q: A? sockets.nextdoor.com. 3/0/0 sockets.nextdoor.com. A 35.82.253.63, sockets.nextdoor.com. A 52.43.176.122, sockets.nextdoor.com. A 44.230.16.148 (86)
11:29:51.687307 IP (tos 0x20, ttl 49, id 24961, offset 0, flags [none], proto UDP (17), length 151)
    64.151.110.139.domain > oberon.43779: [udp sum ok] 11043 q: AAAA? sockets.nextdoor.com. 0/1/0 ns: nextdoor.com. SOA ns-1005.awsdns-61.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 (123)
11:29:51.945011 IP (tos 0x0, ttl 64, id 40574, offset 0, flags [DF], proto UDP (17), length 66)
    oberon.39311 > 64.151.110.139.domain: [bad udp cksum 0xbb95 -> 0x72a2!] 19445+ A? sockets.nextdoor.com. (38)
11:29:51.961238 IP (tos 0x20, ttl 49, id 24998, offset 0, flags [none], proto UDP (17), length 114)
    64.151.110.139.domain > oberon.39311: [udp sum ok] 19445 q: A? sockets.nextdoor.com. 3/0/0 sockets.nextdoor.com. A 35.82.253.63, sockets.nextdoor.com. A 52.43.176.122, sockets.nextdoor.com. A 44.230.16.148 (86)

And now we can see what those sockets are used for.