Monday, October 5, 2020

Security On The Cheap - Beginning Elastic Stack - Providing Basic Security to Elastic and Kibana 7.9 communication on Ubuntu 20.04

In the first post, we installed Elasticsearch. In the second post, we installed Kibana. In this post, we now provide some basic security to the communication between the Elasticsearch and Kibana. Note, there is a lot more you can do to secure this environment, taking advantage of keystores, etc. 

In generating the Certification Authority (CA) certificate, I choose to use PKCS#12 format. In this format, this file contains both the CA certificate and its private key. This may be a cause for concern in some environments.

Additionally, I created one certificate file to be used by each component. This means the various components need to be able to read the file. This obviously makes the data in the file accessible by those users.  In this post, I am keeping it simple. If you are looking at thoroughly securing your environment, this post is something you can essentially build on if you wish.

If you are wondering why we need to secure the communication between Elastic and Kibana, here is a simple reason why.

root@securitynik-monitoring:~# tcpdump -nnti any host 10.0.0.1 and port 9200 -A
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
IP 10.0.0.1.60100 > 10.0.0.1.9200: Flags [P.], seq 3727928959:3727929473, ack 22660352, win 9203, options [nop,nop,TS val 4105791837 ecr 4105786838], length 514

E..6.G@.@.!"..........#..3...Y....#........
..i]..U.POST /.reporting-*/_search HTTP/1.1
content-type: application/json
Host: 10.0.0.1:9200
Content-Length: 374
Connection: keep-alive

{"seq_no_primary_term":true,"_source":{"excludes":["output.content"]},"query":{"bool":{"filter":{"bool":{"minimum_should_match":1,"should":[{"term":{"status":"pending"}},{"bool":{"must":[{"term":{"status":"processing"}},{"range":{"process_expiration":{"lte":"2020-08-14T01:02:35.764Z"}}}]}}]}}}},"sort":[{"priority":{"order":"asc"}},{"created_at":{"order":"asc"}}],"size":1}

IP 10.0.0.1.9200 > 10.0.0.1.60100: Flags [P.], seq 1:247, ack 514, win 512, options [nop,nop,TS val 4105791839 ecr 4105791837], length 246
E..*..@.@...........#....Y...3.......u.....
..i_..i]HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
content-length: 159
....

As shown above, using tcpdump, we were able to sniff the traffic on the wire, thus gaining visibility into actual communication occurring on the network. At this point, if we can see the data, anyone else can.

With that out of the way, let's get to providing some basic security to this environment via Transport Layer Security (TLS).

First up, we modify our "elasticsearch.yml" file to include "xpack.security.enabled: true". Here is what my configuration looks like.

root@securitynik-monitoring:~# cat /etc/elasticsearch/elasticsearch.yml | grep "xpack.security.enabled: true"
xpack.security.enabled: true

For TLS to work properly, we need a certificate. There are many ways to get certificates. However, for us, we will use the built in "elasticsearch-certutil" utility, to generate our own certification authority.

root@securitynik-monitoring:~# /usr/share/elasticsearch/bin/elasticsearch-certutil ca ca-dn securitynik.local
This tool assists you in the generation of X.509 certificates and certificate signing requests for use with SSL/TLS in the Elastic stack.

The 'ca' mode generates a new 'certificate authority'. This will create a new X.509 certificate and private key that can be used to sign certificate when running in 'cert' mode.


Use the 'ca-dn' option if you wish to configure the 'distinguished name' of the certificate authority

By default the 'ca' mode produces a single PKCS#12 output file which holds:

    * The CA certificate
    * The CA's private key


If you elect to generate PEM format certificates (the -pem option), then the output will be a zip file containing individual files for the CA certificate and private key

Please enter the desired output file [elastic-stack-ca.p12]: SecurityNik-CA.p12

Enter password for SecurityNik-CA.p12 :

Above, my CA cert is named "SecurityNik-CA.p12". Also you have the option to specify a password for the CA cert. I did not specify a password. In my example, the file was stored in:

root@securitynik-monitoring:~# ls /usr/share/elasticsearch/SecurityNik-CA.p12 -al
-rw------- 1 root root 2527 Aug 13 21:49 /usr/share/elasticsearch/SecurityNik-CA.p12

With the CA certificate generated, let's now generate a certificate for our node at "10.0.0.1".

root@securitynik-monitoring:~# /usr/share/elasticsearch/bin/elasticsearch-certutil cert --ca /usr/share/elasticsearch/SecurityNik-CA.p12  --days 1825 --dns monitoring,monitoring.securitynik.local --ip 10.0.0.1 --keysize 2048 --name 10.0.0.1 --out /usr/share/elasticsearch/10.0.0.1.p12 --pass "" --silent

Enter password for CA (/usr/share/elasticsearch/SecurityNik-CA.p12) :

Below we see the file which was created.

root@securitynik-monitoring:~# ls -al /usr/share/elasticsearch/10.0.0.1.p12 -al
-rw------- 1 root root 3529 Aug 13 22:23 /usr/share/elasticsearch/10.0.0.1.p12

Copy this certificate to the "/etc/elasticsearch/" folder.

root@securitynik-monitoring:~# cp /usr/share/elasticsearch/10.0.0.1.p12 /etc/elasticsearch/ -v 
'/usr/share/elasticsearch/10.0.0.1.p12' -> '/etc/elasticsearch/10.0.0.1.p12'

Next I changed the permission of the certificate so it is world readable. Not necessarily the best thing to do but this is for simplicity.

root@securitynik-monitoring:~# chmod 644 /etc/elasticsearch/10.0.0.1.p12
root@securitynik-monitoring:~# ls -al /etc/elasticsearch/10.0.0.1.p12
-rw-r--r-- 1 root elasticsearch 3529 Aug 13 22:32 /etc/elasticsearch/10.0.0.1.p12

As our certificate is in PKCS#12 format, we will add the following lines to our "elasticsearch.yml".

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: 10.0.0.1.p12
xpack.security.transport.ssl.truststore.path: 10.0.0.1.p12

Here is what my Elasticsearch configuration now looks like after those changes.

root@securitynik-monitoring:~# tail --lines 6 /etc/elasticsearch/elasticsearch.yml
# Configuration added by Nik for security
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: "10.0.0.1.p12"
xpack.security.transport.ssl.truststore.path: "10.0.0.1.p12"

Time to restart Elasticsearch and pray that everything works as expected.

root@securitynik-monitoring:~# systemctl status elasticsearch.service
● elasticsearch.service - Elasticsearch
     Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-08-13 22:40:44 EDT; 3min 50s ago
       Docs: https://www.elastic.co
   Main PID: 24533 (java)
      Tasks: 61 (limit: 4563)
     Memory: 1.2G
     CGroup: /system.slice/elasticsearch.service
             ├─24533 /usr/share/elasticsearch/jdk/bin/java -Xshare:auto -Des.networkaddress.cache.ttl=60 -Des.networkaddres>
             └─24725 /usr/share/elasticsearch/modules/x-pack-ml/platform/linux-x86_64/bin/controller

Aug 13 22:40:17 securitynik-monitoring systemd[1]: Starting Elasticsearch...
Aug 13 22:40:44 securitynik-monitoring systemd[1]: Started Elasticsearch.

Above, all looks well. Looking at the network ports via "ss". Note you can also use "netstat". 

root@securitynik-monitoring:~# ss --numeric --listen --tcp | grep 9200
LISTEN  0       4096     [::ffff:10.0.0.1]:9200              *:*

Awesome! 

Next step, let's now generate a certificate for HTTP communication. For example, between Kibana and Elastic and ultimately between our browser and Kibana. Once again, we use "elasticsearch-certutil", this time with the "http" argument.

root@securitynik-monitoring:~# /usr/share/elasticsearch/bin/elasticsearch-certutil http --silent
## Elasticsearch HTTP Certificate Utility
## Do you wish to generate a Certificate Signing Request (CSR)?
Generate a CSR? [y/N]N
## Do you have an existing Certificate Authority (CA) key-pair that you wish to use to sign your certificate?
Use an existing CA? [y/N]Y
## What is the path to your CA?
CA Path: /usr/share/elasticsearch/SecurityNik-CA.p12
Password for SecurityNik-CA.p12:
## How long should your certificates be valid?
For how long should your certificate be valid? [5y]
## Do you wish to generate one certificate per node?
Generate a certificate per node? [y/N]N
## Which hostnames will be used to connect to your nodes?

securitynik-monitoring

securitynik-monitoring.securitynik.local

You entered the following hostnames.

 - securitynik-monitoring
 - securitynik-monitoring.securitynik.local

Is this correct [Y/n]y

## Which IP addresses will be used to connect to your nodes?
10.0.0.1

You entered the following IP addresses.

 - 10.0.0.1
Is this correct [Y/n]y
## Other certificate options
Key Name: securitynik-monitoring
Subject DN: CN=securitynik-monitoring

Key Size: 2048

Do you wish to change any of these options? [y/N]n
## What password do you want for your private key(s)?
Provide a password for the "http.p12" file:  [<ENTER> for none]
## Where should we save the generated files?

What filename should be used for the output zip file? [/usr/share/elasticsearch/elasticsearch-ssl-http.zip]

Confirming the file was successfully created.

root@securitynik-monitoring:~# ls /usr/share/elasticsearch/elasticsearch-ssl-http.zip -l
-rw------- 1 root root 7334 Aug 13 23:22 /usr/share/elasticsearch/elasticsearch-ssl-http.zip

First we install "unzip". With unzip installed, we are now able to look into the zip file

root@securitynik-monitoring:/usr/share/elasticsearch# apt install unzip
root@securitynik-monitoring:/usr/share/elasticsearch# unzip -l elasticsearch-ssl-http.zip
Archive:  elasticsearch-ssl-http.zip
  Length      Date    Time    Name
---------  ---------- -----   ----

        0  2020-08-13 23:22   elasticsearch/
     1091  2020-08-13 23:22   elasticsearch/README.txt
     3499  2020-08-13 23:22   elasticsearch/http.p12
      657  2020-08-13 23:22   elasticsearch/sample-elasticsearch.yml
        0  2020-08-13 23:22   kibana/
     1306  2020-08-13 23:22   kibana/README.txt
     1200  2020-08-13 23:22   kibana/elasticsearch-ca.pem
     1056  2020-08-13 23:22   kibana/sample-kibana.yml
---------                     -------
     8809                     8 files

Extracting the contents from the "elasticsearch-ssl-http.zip" into a folder named "certs" and verifying the extraction.

root@securitynik-monitoring:/usr/share/elasticsearch# unzip -d certs/ elasticsearch-ssl-http.zip
Archive:  elasticsearch-ssl-http.zip
   creating: certs/elasticsearch/
  inflating: certs/elasticsearch/README.txt
  inflating: certs/elasticsearch/http.p12
  inflating: certs/elasticsearch/sample-elasticsearch.yml
   creating: certs/kibana/
  inflating: certs/kibana/README.txt
  inflating: certs/kibana/elasticsearch-ca.pem
  inflating: certs/kibana/sample-kibana.yml
root@securitynik-monitoring:/usr/share/elasticsearch# ls certs/
elasticsearch  kibana

Time to copy "certs/elasticsearch/http.p12" file to "/etc/elasticsearch/" folder. 

root@securitynik-monitoring:~# cp /usr/share/elasticsearch/certs/elasticsearch/http.p12 /etc/elasticsearch/ -v 
'/usr/share/elasticsearch/certs/elasticsearch/http.p12' -> '/etc/elasticsearch/http.p12'

I then added the following lines to the bottom of my "elasticsearch.yml".

# This turns on SSL for the HTTP (Rest) interface
xpack.security.http.ssl.enabled: true
# This configures the keystore to use for SSL on HTTP
xpack.security.http.ssl.keystore.path: "http.p12"

For consistency I also rename the "elasticsearch-ca.pem" file to "SecurityNik-CA.pem"

root@securitynik-monitoring:/usr/share/elasticsearch/certs# cd /etc/kibana/
root@securitynik-monitoring:/etc/kibana# mv elasticsearch-ca.pem SecurityNik-CA.pem
root@securitynik-monitoring:/etc/kibana#

Next the file "kibana/SecurityNik-ca.pem" was copied to the "/etc/kibana" folder

root@securitynik-monitoring:/usr/share/elasticsearch/certs# cp /usr/share/elasticsearch/certs/kibana/SecurityNik-ca.pem /etc/kibana/ -v
'/usr/share/elasticsearch/certs/kibana/SecurityNik-ca.pem' -> '/etc/kibana/SecurityNik-ca.pem'

Next I modified my "kibana.yml" file changing "elasticsearch.hosts: ["http://10.0.0.1:9200"]" to "elasticsearch.hosts: ["https://10.0.0.1:9200"]". Note the https. I also added "elasticsearch.ssl.certificateAuthorities: [ "/etc/kibana/SecurityNik-CA.pem" ]"

With these configurations now out of the way, let's restart both Elasticsearch and Kibana.

root@securitynik-monitoring:/etc/kibana# systemctl stop elasticsearch.service
root@securitynik-monitoring:/etc/kibana# systemctl start elasticsearch.service
root@securitynik-monitoring:/etc/kibana# systemctl stop kibana.service
root@securitynik-monitoring:/etc/kibana# systemctl start kibana.service

Let's now configure Kibana so that we connect to it via HTTPS. 

First I copy the "10.0.0.1.p12" node certificate which was previously created to the Kibana folder. 

root@securitynik-monitoring:~# cp /etc/elasticsearch/10.0.0.1.p12 /etc/kibana/ -v 
'/etc/elasticsearch/10.0.0.1.p12' -> '/etc/kibana/10.0.0.1.p12'

Once again, modifying "kibana.yml", we add the following lines.

server.ssl.keystore.path: "/etc/kibana/10.0.0.1.p12"
server.ssl.enabled: true
server.ssl.keystore.password: ""

Once completed, restarted Kibana 

root@securitynik-monitoring:/etc/kibana# systemctl stop kibana.service
root@securitynik-monitoring:/etc/kibana# systemctl start kibana.service

Before we login, let's setup the default users using "elasticsearch-setup-passwords".

root@securitynik-monitoring:~# /usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive --silent

Please confirm that you would like to continue [y/N]y
Enter password for [elastic]:
Reenter password for [elastic]:
Enter password for [apm_system]:
Reenter password for [apm_system]:
Enter password for [kibana_system]:
Reenter password for [kibana_system]:
Enter password for [logstash_system]:
Reenter password for [logstash_system]:
Enter password for [beats_system]:
Reenter password for [beats_system]:
Enter password for [remote_monitoring_user]:
Reenter password for [remote_monitoring_user]:

Now that the users are setup, the Kibana configuration file must now reflect the values for username and password for "kibana_system" account.

root@securitynik-monitoring:~# cat /etc/kibana/kibana.yml | grep "kibana_system" --after-context 1
elasticsearch.username: "kibana_system"
elasticsearch.password: "WelcomeToSecurityNikElastic"

Below represents some of those changes I've made to the "kibana.yml"

root@securitynik-monitoring:~# tail --lines 8 /etc/kibana/kibana.yml

# Below added by Nik
server.ssl.enabled: true
elasticsearch.ssl.certificateAuthorities: ["/etc/kibana/SecurityNik-CA.pem"]
server.ssl.keystore.path: "/etc/kibana/10.0.0.1.p12"
server.ssl.keystore.password: ""
xpack.encryptedSavedObjects.encryptionKey: 'fhjskloppd678ehkdfdlliverpoolfcr'
xpack.security.session.idleTimeout: "30m"
xpack.security.session.lifespan: "8h"

With those changes in place, we should now be good to go.

Let's authenticate to Kibana using the username and password we setup for the "elastic" user. Once authenticated, you should create a few additional users based on their roles.

HTTPS Login Page


Once you authenticate successfully, you should now see the following.

Before we go, if you remember, when we started, we were able to see the clear text data crossing the wire. If we run tcpdump again, we don't see any data in the clear.

root@n3-monitoring:/etc/elasticsearch# tcpdump -nnti any host 10.0.0.1 and port 9200 -A -c 5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
IP 10.0.0.1.36344 > 10.0.0.1.9200: Flags [P.], seq 2879060748:2879061003, ack 1452891267, win 512, options [nop,nop,TS val 2724200057 ecr 2724168569], length 255
E..3y.@.@.>...........#.....V.\......~.....
._.y._.y.........@.../....Ls}..E...
.l.;........x.^..u..3S...A.,.O...2e.h...../.).*@.a15ou.u.^D...~.3..Hy\W'.../....D.ahL..H...q;...j....$..L.0<%J..._..k]..TMQj.B
m....n.id.O....5.....S...=1.Iq.|Ox...}.mOP......z@..L.&...&X.>....R.u'I.-U*!|.Z..._.Z.[%7=...K.6m...
IP 10.0.0.1.9200 > 10.0.0.1.36344: Flags [P.], seq 1:238, ack 255, win 512, options [nop,nop,TS val 2724200061 ecr 2724200057], length 237
E..!..@.@...........#...V.\..........l.....
._.}._.y..............{.m6!....ZK^...
.j..$-.......4(..\Y6...y=j.....T0v..J.yG..8.I.....'.+%w.6...y..z...r...*K..L......t..cc.Pk.\..RZ.%.N.....l...Zq......qw.W..!05."...{...I..g..)\(.H..........Q...H..<X...1...X4.W..).
.eoB...w..i.....[......+.W
IP 10.0.0.1.36344 > 10.0.0.1.9200: Flags [.], ack 238, win 511, options [nop,nop,TS val 2724200061 ecr 2724200061], length 0
E..4y.@.@.?...........#.....V.]p...........
._.}._.}
IP 10.0.0.1.36294 > 10.0.0.1.9200: Flags [.], ack 2500636561, win 512, options [nop,nop,TS val 2724200281 ecr 2724199268], length 0
E..43.@.@.............#.3.1................
._.Y._.d
IP 10.0.0.1.9200 > 10.0.0.1.36294: Flags [.], ack 1, win 512, options [nop,nop,TS val 2724200281 ecr 2724199268], length 0
E..4..@.@...........#.......3.1............

At this point, it is time to move on, as we were able to provide some basic security to Kibana and Elastic.

Posts in this series:

Security On The Cheap - Beginning Elastic Stack - Installing Elastic 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic Stack - Installing Kibana 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic Stack - Providing Basic Security to Elastic and Kibana 7.9 communication on Ubuntu 20.04
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Metricbeat - Elastic Stack 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Auditbeat - Elastic Stack 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Filebeat - Elastic Stack 7.9 on Ubuntu 20.04
Beginning Elastic - Installing, Configuring and Providing Basic Security to Packetbeat
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Winlogbeat


References:

https://www.elastic.co/blog/getting-started-with-elasticsearch-security
https://www.elastic.co/guide/en/elasticsearch/reference/7.8/configuring-tls.html#node-certificates
https://www.elastic.co/guide/en/elasticsearch/reference/current/get-started-built-in-users.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/get-started-kibana-user.html
https://www.youtube.com/watch?v=nMh1HWWe6B4&feature=youtu.be
https://www.elastic.co/guide/en/elasticsearch/reference/current/trb-security-sslhandshake.html

https://www.elastic.co/guide/en/kibana/7.9/using-kibana-with-security.html

Security On The Cheap - Beginning Elastic Stack - Installing Kibana 7.9 on Ubuntu 20.04

In the previous post, we installed and configured Elasticsearch on Ubuntu 20.04. In this post, we install and configure Kibana on Ubuntu 20.04.

Since we already installed some of the prerequisites in the previous post, let's focus now on installing and configuring Kibana.

root@securitynik-monitoring:/etc/elasticsearch# apt-get update && apt-get install kibana
...
Get:1 https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 kibana amd64 7.9.2 [302 MB]
Fetched 302 MB in 10s (31.3 MB/s)
Selecting previously unselected package kibana.
(Reading database ... 88849 files and directories currently installed.)
Preparing to unpack .../kibana_7.9.2_amd64.deb ...
Unpacking kibana (7.9.2) ...
Setting up kibana (7.9.2) ...
Processing triggers for systemd (245.4-4ubuntu3.2) ...

As before, I changed into Kibana directory and made a copy of the original config file.

root@securitynik-monitoring:/etc/elasticsearch# cd /etc/kibana/
root@securitynik-monitoring:/etc/kibana# cp kibana.yml kibana.yml.ORIGINAL

Here are the options I un-commented and or modified.

root@securitynik-monitoring:~# cat /etc/kibana/kibana.yml | grep --perl-regexp "^server.port|^server.host|^server.name|^elasticsearch.host|^elasticsearch.logQueries|run"
server.port: 5601
server.host: "10.0.0.1"
server.name: "kibana.securitynik.local"
elasticsearch.hosts: ["http://10.0.0.1:9200"]
elasticsearch.logQueries: true
pid.file: /var/run/kibana/kibana.pid

To prevent Kibana from throwing the error "message":"{ [Error: EACCES: permission denied, open '/var/run/kibana.pid']", I created a directory named "kibana" under "/var/run/" and made the "kibana" user the owner.

root@securitynik-monitoring:~# mkdir /var/run/kibana
root@securitynik-monitoring:~# chown kibana.kibana /var/run/kibana/
root@securitynik-monitoring:~# ls -al /var/run/
...
drwxr-xr-x  2 kibana        kibana          40 Oct  2 09:37 kibana

Configuring Kibana service.

root@securitynik-monitoring:/etc/kibana# systemctl daemon-reload
root@securitynik-monitoring:/etc/kibana# systemctl enable --now kibana.service
Synchronizing state of kibana.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable kibana
Created symlink /etc/systemd/system/multi-user.target.wants/kibana.service → /etc/systemd/system/kibana.service.

Verify the service is running.

root@securitynik-monitoring:/etc/kibana# systemctl status kibana.service
● kibana.service - Kibana
     Loaded: loaded (/etc/systemd/system/kibana.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2020-08-14 00:02:02 UTC; 49s ago
   Main PID: 19495 (node)
      Tasks: 11 (limit: 4563)
     Memory: 429.9M
     CGroup: /system.slice/kibana.service
             └─19495 /usr/share/kibana/bin/../node/bin/node /usr/share/kibana/bin/../src/cli


Aug 14 00:02:02 securitynik-monitoring systemd[1]: Started Kibana.
Aug 14 00:02:06 securitynik-monitoring kibana[19495]: {"type":"log","@timestamp":"2020-08-14T00:02:06Z","tags":["warning","plugins-d>
Aug 14 00:02:06 securitynik-monitoring kibana[19495]: {"type":"log","@timestamp":"2020-08-14T00:02:06Z","tags":["warning","plugins-d>

Looks good! Verify the service is listening on port 5601.

root@securitynik-monitoring:/etc/kibana# ss --numeric --listen --process --tcp --udp
Netid  State   Recv-Q  Send-Q          Local Address:Port   Peer Address:Port  Process
tcp    LISTEN  0       511               10.0.0.1:5601        0.0.0.0:*      users:(("node",pid=19495,fd=18))
tcp    LISTEN  0       4096     [::ffff:10.0.0.1]:9200              *:*      users:(("java",pid=18392,fd=267))
tcp    LISTEN  0       4096     [::ffff:10.0.0.1]:9300              *:*      users:(("java",pid=18392,fd=253))

Looks like the Kibana service is available on port 5601. Time for the final validation. This will be done by connecting to the web UI.

Kibana Welcome Page - No authentication at this point


At this point, you have the option of using the sample data provided by Elastic or explore on your own. We will explore on our own in future posts by taking advantage of the various Beats. Those are Filebeat, Packetbeat, Winlogbeat, Auditbeat and Metricbeat.


With this done, let's now move to the next post, where we provide some basic security to the communication between the Elastic stack components.

Posts in this series:

Security On The Cheap - Beginning Elastic Stack - Installing Elastic 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic Stack - Installing Kibana 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic Stack - Providing Basic Security to Elastic and Kibana 7.9 communication on Ubuntu 20.04
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Metricbeat - Elastic Stack 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Auditbeat - Elastic Stack 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Filebeat - Elastic Stack 7.9 on Ubuntu 20.04
Beginning Elastic - Installing, Configuring and Providing Basic Security to Packetbeat
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Winlogbeat


References:
https://www.elastic.co/guide/en/kibana/7.9/deb.html#deb-repo
https://www.elastic.co/guide/en/kibana/7.9/settings.html

Security On The Cheap - Beginning Elastic Stack - Installing Elastic 7.9 on Ubuntu 20.04

In this post, we are installing Elastic Stack version 7.9 on Ubuntu 20.04. I would like to think this process should work for versions just prior to 7.9 and may also work for versions just after.

root@securitynik-monitoring:~# lsb_release --all
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04 LTS
Release:        20.04
Codename:       focal

First step, let's update the server, ensuring we have all the necessary updates.

root@securitynik-monitoring:~# apt-get update && apt-get upgrade -y

Now that the server is up-to-date, let's install Elasticsearch.

Import Elasticsearch PGP Key. This will be used throughout our install for the rest of the components.

root@securitynik-monitoring:~# wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
OK

Now install the the "apt-transport-https" package and save the repository definition.

root@securitynik-monitoring:~# apt-get install apt-transport-https
root@securitynik-monitoring:~# echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list
deb https://artifacts.elastic.co/packages/7.x/apt stable main

With the dependencies installed, time to install Elasticsearch.

root@securitynik-monitoring:~# apt-get update && apt-get install elasticsearch
...
Get:1 https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 elasticsearch amd64 7.9.2 [317 MB]
Fetched 317 MB in 10s (32.3 MB/s)
Selecting previously unselected package elasticsearch.
(Reading database ... 87809 files and directories currently installed.)
Preparing to unpack .../elasticsearch_7.9.2_amd64.deb ...
Creating elasticsearch group... OK
Creating elasticsearch user... OK
Unpacking elasticsearch (7.9.2) ...
Setting up elasticsearch (7.9.2) ...
Created elasticsearch keystore in /etc/elasticsearch/elasticsearch.keystore
Processing triggers for systemd (245.4-4ubuntu3.2) ...

With Elasticsearch now installed, switch to the Elasticsearch configuration directory and modify the "elasticsearch.yml" file. My practice before modifying any configuration file, is to make a copy of it.

root@securitynik-monitoring:/etc/elasticsearch# cd /etc/elasticsearch/
root@securitynik-monitoring:/etc/elasticsearch# cp elasticsearch.yml elasticsearch.yml.ORIGINAL

Here are the values I un-commented and modified to reflect my environment.

root@securitynik-monitoring:~# cat /etc/elasticsearch/elasticsearch.yml | grep --perl-regexp "cluster.name|node.name|network.host|http.port|discovery.seed_hosts|cluster.initial.master_nodes"
cluster.name: securitynik.local
node.name: elastic-10.0.0.1
network.host: 10.0.0.1
http.port: 9200
discovery.seed_hosts: ["10.0.0.1"]
cluster.initial_master_nodes: ["10.0.0.1"]

Enable and start the Elasticsearch service via "systemctl".

root@securitynik-monitoring:/etc/elasticsearch# systemctl enable --now elasticsearch.service
Synchronizing state of elasticsearch.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable elasticsearch
Created symlink /etc/systemd/system/multi-user.target.wants/elasticsearch.service → /lib/systemd/system/elasticsearch.service.

Verify that the service is running via "systemctl"

root@securitynik-monitoring:~# systemctl status elasticsearch.service
● elasticsearch.service - Elasticsearch
     Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-08-13 23:05:07 UTC; 4min 27s ago
       Docs: https://www.elastic.co
   Main PID: 18392 (java)
      Tasks: 44 (limit: 4563)
     Memory: 1.2G
     CGroup: /system.slice/elasticsearch.service
             ├─18392 /usr/share/elasticsearch/jdk/bin/java -Xshare:auto -Des.networkaddress.cache.ttl=60 -Des.networkad>
             └─18588 /usr/share/elasticsearch/modules/x-pack-ml/platform/linux-x86_64/bin/controller

Aug 13 23:04:12 securitynik-monitoring systemd[1]: Starting Elasticsearch...
Aug 13 23:05:07 securitynik-monitoring systemd[1]: Started Elasticsearch.

From above we, we see the service is "active (running)". We can further confirm the service is available by leveraging "ss" or "netstat" command, looking for the listening ports.

root@securitynik-monitoring:/etc/elasticsearch# ss --numeric --listen --process --tcp --udp
Netid State  Recv-Q  Send-Q          Local Address:Port   Peer Address:Port Process
...
tcp   LISTEN 0       4096     [::ffff:10.0.0.1]:9200              *:*     users:(("java",pid=18392,fd=267))
tcp   LISTEN 0       4096     [::ffff:10.0.0.1]:9300              *:*     users:(("java",pid=18392,fd=253))
...

So far everything suggests we have installed Elasticsearch successfully. Let's now confirm this by connecting to the Elasticsearch URL.

root@securitynik-monitoring:/etc/elasticsearch# curl --request GET --verbose "http://10.0.0.1:9200/?pretty" --header "User-Agent: www.securitynik.com"
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 10.0.0.1:9200...
* TCP_NODELAY set
* Connected to 10.0.0.1 (10.0.0.1) port 9200 (#0)
> GET /?pretty HTTP/1.1
> Host: 10.0.0.1:9200
> Accept: */*
> User-Agent: www.securitynik.com
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< content-type: application/json; charset=UTF-8
< content-length: 529
<
{
  "name" : "elastic-10.0.0.1",
  "cluster_name" : "securitynik.local",
  "cluster_uuid" : "_na_",
  "version" : {
    "number" : "7.9.2",
    "build_flavor" : "default",
    "build_type" : "deb",
    "build_hash" : "b5ca9c58fb664ca8bf9e4057fc229b3396bf3a89",
    "build_date" : "2020-07-21T16:40:44.668009Z",
    "build_snapshot" : false,
    "lucene_version" : "8.6.2",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}
* Connection #0 to host 10.0.0.1 left intact

Good stuff! All the tests suggest we have successfully installed Elasticsearch.

See you in the next post where we install and configure Kibana.

Posts in this series:

Security On The Cheap - Beginning Elastic Stack - Installing Elastic 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic Stack - Installing Kibana 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic Stack - Providing Basic Security to Elastic and Kibana 7.9 communication on Ubuntu 20.04
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Metricbeat - Elastic Stack 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Auditbeat - Elastic Stack 7.9 on Ubuntu 20.04
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Filebeat - Elastic Stack 7.9 on Ubuntu 20.04
Beginning Elastic - Installing, Configuring and Providing Basic Security to Packetbeat
Security On The Cheap - Beginning Elastic - Installing and Providing Basic Security to Winlogbeat



References:

Wednesday, September 9, 2020

Just a few days left to register for my upcoming SANS SEC582 Mastering TShark Packet Analysis class and get a Free copy of "Hack and Detect" or "Mastering TShark Network Forensics"

 Get a Free copy of "Learning by Practicing - Mastering TShark Network Forensics: Moving From Zero to Hero" or "Learning By Practicing - Hack & Detect: Leveraging the Cyber Kill Chain for Practical Hacking and its Detection via Network Forensics" when you register for my upcoming SANS SEC582 Mastering TShark Packet Analysis class


To learn more see: 

SEC582: Mastering TShark Packet Analysis

Beginning File System Forensics - Timeline analysis

Now that the drive has been mounted and the file metadata has been exported as seen in the previous post, let's poke at some files of "interest". The file of interest is related to my SANS SEC582 - Mastering TShark Packet Analysis class. 

Let's assume we have an indicator of compromise. That indicator being a suspicious file name. We can then use the "grep" utility to search the previously created "linux_mint_files_export.txt" to see if we get a hit. Let's try that. At the same time, let's pipe the results into "wc --lines" to see how many entries were returned.

kali@securitynik:~/forensics$ grep "SEC582" linux_mint_files_export.txt | wc --lines
22

Above it looks like 22 results were returned. Taking a look at those entries. 

kali@securitynik:~/forensics$ grep "SEC582" linux_mint_files_export.txt
05/13/2020|08:31:58.8300000000|05/13/2020|20:00:00.0000000000|05/13/2020|08:32:00.0000000000|755|0|root|0|root|16384|SANS SEC582 - Labs and Challenges PDFs
05/13/2020|09:47:17.0200000000|05/12/2020|20:00:00.0000000000|05/13/2020|09:47:18.0000000000|755|0|root|0|root|16384|SANS SEC582 - Labs and Challenges PDFs/Day 1
05/13/2020|09:17:58.1200000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:18:00.0000000000|755|0|root|0|root|439479|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.2 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:26:59.1700000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:27:02.0000000000|755|0|root|0|root|817648|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.3 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:30:58.7100000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:31:02.0000000000|755|0|root|0|root|505620|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.4 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:33:56.1000000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:33:58.0000000000|755|0|root|0|root|158779|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.5 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:36:20.3600000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:36:22.0000000000|755|0|root|0|root|209775|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.6 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:43:38.9500000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:43:42.0000000000|755|0|root|0|root|290017|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.7 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:44:42.0100000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:44:44.0000000000|755|0|root|0|root|157451|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.8 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|08:34:08.4100000000|05/13/2020|20:00:00.0000000000|05/13/2020|08:34:10.0000000000|755|0|root|0|root|396034|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.1 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:47:33.1500000000|05/12/2020|20:00:00.0000000000|05/13/2020|09:47:34.0000000000|755|0|root|0|root|16384|SANS SEC582 - Labs and Challenges PDFs/Day 2
05/13/2020|09:46:45.6500000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:46:48.0000000000|755|0|root|0|root|173404|SANS SEC582 - Labs and Challenges PDFs/Day 2/Exercise 2.1 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|10:44:37.9400000000|05/13/2020|20:00:00.0000000000|05/13/2020|10:44:40.0000000000|755|0|root|0|root|194576|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.1 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:04:45.2100000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:04:48.0000000000|755|0|root|0|root|604994|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.2 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:11:34.8000000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:11:40.0000000000|755|0|root|0|root|110284|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.3 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:18:01.4200000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:18:06.0000000000|755|0|root|0|root|221816|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.4 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:27:05.3600000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:27:08.0000000000|755|0|root|0|root|160748|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.5 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:37:28.2700000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:37:30.0000000000|755|0|root|0|root|246089|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.7 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:38:15.8100000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:38:18.0000000000|755|0|root|0|root|155128|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.8 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:39:09.4800000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:39:12.0000000000|755|0|root|0|root|168333|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.9 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:45:31.3500000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:45:34.0000000000|755|0|root|0|root|303851|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.10 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/14/2020|05:52:29.6100000000|05/13/2020|20:00:00.0000000000|05/14/2020|06:39:22.0000000000|755|0|root|0|root|1998024|SANS SEC582 - Labs and Challenges PDFs/Initial Setup - SANS SEC582_ Mastering TShark Packet Analysis.pdf

As you may remember in the previous post, the columns above are organized as follow: last status changed date (%Cx), last status changed time (%CT), last access date (%Ax), last access time (%AT), last modification time (%Tx), last modification time (%TT), file permissions (%m), file numeric user id (%U), username (%u), group id (%G), group name (%u), size (%s), path (%P) and finally put ever entry on a new line (\n)

Considering the preceding, let's instead sort this from first creation date and time, to last creation date and time. We will put the most recent date at the top. To achieve this, we will use the previous output, in conjunction with "sort" using a "--field-separator" of pipe "|". We will also use fields 1 and 2 as our keys and then "--reverse" the output. This is how we are able to achieve our objective.

kali@securitynik:~/forensics$ cat linux_mint_files_export.txt | grep SEC582 | sort --field-separator "|" --key=1,2 --reverse
05/14/2020|05:52:29.6100000000|05/13/2020|20:00:00.0000000000|05/14/2020|06:39:22.0000000000|755|0|root|0|root|1998024|SANS SEC582 - Labs and Challenges PDFs/Initial Setup - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:45:31.3500000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:45:34.0000000000|755|0|root|0|root|303851|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.10 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:39:09.4800000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:39:12.0000000000|755|0|root|0|root|168333|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.9 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:38:15.8100000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:38:18.0000000000|755|0|root|0|root|155128|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.8 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:37:28.2700000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:37:30.0000000000|755|0|root|0|root|246089|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.7 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:27:05.3600000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:27:08.0000000000|755|0|root|0|root|160748|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.5 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:18:01.4200000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:18:06.0000000000|755|0|root|0|root|221816|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.4 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:11:34.8000000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:11:40.0000000000|755|0|root|0|root|110284|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.3 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|11:04:45.2100000000|05/13/2020|20:00:00.0000000000|05/13/2020|11:04:48.0000000000|755|0|root|0|root|604994|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.2 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|10:44:37.9400000000|05/13/2020|20:00:00.0000000000|05/13/2020|10:44:40.0000000000|755|0|root|0|root|194576|SANS SEC582 - Labs and Challenges PDFs/Day 2/Challenge 2.1 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:47:33.1500000000|05/12/2020|20:00:00.0000000000|05/13/2020|09:47:34.0000000000|755|0|root|0|root|16384|SANS SEC582 - Labs and Challenges PDFs/Day 2
05/13/2020|09:47:17.0200000000|05/12/2020|20:00:00.0000000000|05/13/2020|09:47:18.0000000000|755|0|root|0|root|16384|SANS SEC582 - Labs and Challenges PDFs/Day 1
05/13/2020|09:46:45.6500000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:46:48.0000000000|755|0|root|0|root|173404|SANS SEC582 - Labs and Challenges PDFs/Day 2/Exercise 2.1 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:44:42.0100000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:44:44.0000000000|755|0|root|0|root|157451|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.8 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:43:38.9500000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:43:42.0000000000|755|0|root|0|root|290017|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.7 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:36:20.3600000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:36:22.0000000000|755|0|root|0|root|209775|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.6 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:33:56.1000000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:33:58.0000000000|755|0|root|0|root|158779|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.5 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:30:58.7100000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:31:02.0000000000|755|0|root|0|root|505620|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.4 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:26:59.1700000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:27:02.0000000000|755|0|root|0|root|817648|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.3 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|09:17:58.1200000000|05/13/2020|20:00:00.0000000000|05/13/2020|09:18:00.0000000000|755|0|root|0|root|439479|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.2 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|08:34:08.4100000000|05/13/2020|20:00:00.0000000000|05/13/2020|08:34:10.0000000000|755|0|root|0|root|396034|SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.1 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
05/13/2020|08:31:58.8300000000|05/13/2020|20:00:00.0000000000|05/13/2020|08:32:00.0000000000|755|0|root|0|root|16384|SANS SEC582 - Labs and Challenges PDFs

Now that we have the above, we can make some assumptions thus allowing us to come to some conclusions.
1.  The activity surrounding the IoC for string "SEC582" started on May 13, 2020 around 08:31:58 
2. On May 13, 2020 at 08:31:58 local time the user root, created a file "SANS SEC582 - Labs and Challenges PDFs".
3. This file was then modified on the same date at 08:32:00

4. However, as we look closer, we see what seems like two sub directories "/Day 1" and "/Day 2" were created. Filtering these out so we can focus closer on the times, we see:

kali@securitynik:~/forensics$ cat linux_mint_files_export.txt | grep SEC582 | sort --field-separator "|" --key=1,2 --reverse | grep --invert-match --perl-regexp "\.pdf$"
05/13/2020|09:47:33.1500000000|05/12/2020|20:00:00.0000000000|05/13/2020|09:47:34.0000000000|755|0|root|0|root|16384|SANS SEC582 - Labs and Challenges PDFs/Day 2
05/13/2020|09:47:17.0200000000|05/12/2020|20:00:00.0000000000|05/13/2020|09:47:18.0000000000|755|0|root|0|root|16384|SANS SEC582 - Labs and Challenges PDFs/Day 1
05/13/2020|08:31:58.8300000000|05/13/2020|20:00:00.0000000000|05/13/2020|08:32:00.0000000000|755|0|root|0|root|16384|SANS SEC582 - Labs and Challenges PDFs

Paying closer attention to the time we see it seems like the two directories have an access date and time of  "05/12/2020|20:00:00.0000000000"  and "05/12/2020|20:00:00.0000000000" respectively. How could this be? How can the sub directories have a date and time earlier than the parent directory which has "05/13/2020|08:31:58.8300000000"? Could it be this parent folder was created and then the sub folders were copied to this destination?

5. Looking at the other 19 entries, we can say from a creation date the first file "SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.1 - SANS SEC582_ Mastering TShark Packet Analysis.pdf
" was created on May 13, 2020 around 8:34 and the last file "SANS SEC582 - Labs and Challenges PDFs/Initial Setup - SANS SEC582_ Mastering TShark Packet Analysis.pdf" was created on May 14, around 05:52. 

6. Looking at the other 19 entries, we can say from a modification date and time, the first file "SANS SEC582 - Labs and Challenges PDFs/Day 1/Exercise 1.1 - SANS SEC582_ Mastering TShark Packet Analysis.pdf" was modified on May 13, 2020 around 8:34 and the last file "SANS SEC582 - Labs and Challenges PDFs/Initial Setup - SANS SEC582_ Mastering TShark Packet Analysis.pdf" was modified on May 14, around 06:39.

7. Finally, I see the access times of all 19 files have May 13, 2020 at 20:00. Does the proximity with this timing help to reaffirm the conclusion that these files might have been copied? 

Arite!, I think that is enough for this post. 

Ohh and by the way, hope to see you in one of my SANS SEC582 Mastering TShark Packet Analysis class. :-) If you cannot make that one, come hang out with me in the SEC503 or SEC504 class. :-) :-)


References:




Beginning File System Forensics - mounting and learning about the drive

In the previous post, we learned about the disk and the Master Boot Record (MBR), let's now mount that disk, so that we can analyze its contents.

Before mounting, let's once again take a look at the drive to see where the partitions starts.

kali@securitynik:~/forensics$ sudo fdisk --list linux_mint_usb.raw
Disk linux_mint_usb.raw: 29.3 GiB, 31457280000 bytes, 61440000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00051443

Device              Boot Start      End  Sectors  Size Id Type
linux_mint_usb.raw1       2048 61437951 61435904 29.3G  c W95 FAT32 (LBA)

Above, we see one one partition, which has a "Start" sector 2048. To get the actual byte position, multiply 2048*512. 512 once again being the size of the sectors.

512*2048 = 1,048,576‬

Taking a look at this sector with XXD before mounting, we see:

kali@securitynik:~/forensics$ xxd --seek 1048576 --length 512 linux_mint_usb.raw | more
00100000: eb58 904d 5344 4f53 352e 3000 0220 e00a  .X.MSDOS5.0.. ..
00100010: 0200 0000 00f8 0000 3f00 ff00 0008 0000  ........?.......
00100020: 0070 a903 903a 0000 0000 0000 0200 0000  .p...:..........
00100030: 0100 0600 0000 0000 0000 0000 0000 0000  ................
00100040: 8000 2980 b481 fc4e 4f20 4e41 4d45 2020  ..)....NO NAME  
00100050: 2020 4641 5433 3220 2020 33c9 8ed1 bcf4    FAT32   3.....
00100060: 7b8e c18e d9bd 007c 8856 4088 4e02 8a56  {......|.V@.N..V
00100070: 40b4 41bb aa55 cd13 7210 81fb 55aa 750a  @.A..U..r...U.u.
00100080: f6c1 0174 05fe 4602 eb2d 8a56 40b4 08cd  ...t..F..-.V@...
00100090: 1373 05b9 ffff 8af1 660f b6c6 4066 0fb6  .s......f...@f..
001000a0: d180 e23f f7e2 86cd c0ed 0641 660f b7c9  ...?.......Af...
001000b0: 66f7 e166 8946 f883 7e16 0075 3983 7e2a  f..f.F..~..u9.~*
001000c0: 0077 3366 8b46 1c66 83c0 0cbb 0080 b901  .w3f.F.f........
001000d0: 00e8 2c00 e9a8 03a1 f87d 80c4 7c8b f0ac  ..,......}..|...
001000e0: 84c0 7417 3cff 7409 b40e bb07 00cd 10eb  ..t.<.t.........
001000f0: eea1 fa7d ebe4 a17d 80eb df98 cd16 cd19  ...}...}........
00100100: 6660 807e 0200 0f84 2000 666a 0066 5006  f`.~.... .fj.fP.
00100110: 5366 6810 0001 00b4 428a 5640 8bf4 cd13  Sfh.....B.V@....
00100120: 6658 6658 6658 6658 eb33 663b 46f8 7203  fXfXfXfX.3f;F.r.
00100130: f9eb 2a66 33d2 660f b74e 1866 f7f1 fec2  ..*f3.f..N.f....
00100140: 8aca 668b d066 c1ea 10f7 761a 86d6 8a56  ..f..f....v....V
00100150: 408a e8c0 e406 0acc b801 02cd 1366 610f  @............fa.
00100160: 8274 ff81 c300 0266 4049 7594 c342 4f4f  .t.....f@Iu..BOO
00100170: 544d 4752 2020 2020 0000 0000 0000 0000  TMGR    ........
00100180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00100190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001001a0: 0000 0000 0000 0000 0000 0000 0d0a 4469  ..............Di
001001b0: 736b 2065 7272 6f72 ff0d 0a50 7265 7373  sk error...Press
001001c0: 2061 6e79 206b 6579 2074 6f20 7265 7374   any key to rest
001001d0: 6172 740d 0a00 0000 0000 0000 0000 0000  art.............
001001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001001f0: 0000 0000 0000 0000 ac01 b901 0000 55aa  ..............U.

First create a directory which will be used as your mount target

kali@securitynik:~/forensics$ mkdir usb

Let's now mount the drive:
kali@securitynik:~/forensics$ sudo mount --read-only --verbose --options noatime,nodiratime,loop,offset=1048576 --source linux_mint_usb.raw --target usb/
mount: /dev/loop0 mounted on /home/kali/forensics/usb.

Here is what the above does
mount - mount the drive

--read-only - mount the drive as read only

--verbose - print the informational message, for each successful mount 

--options 
    noatime - Do not update the access timestamps when the file is read
    nodiratime -  Do not update the directory inode access times on this file system
    loop - sets up a loop device to correspond to the image file "linux_mint_usb.raw" and then mount that image to "--target usb/"

    We can confirm this loop device as follows:
  
 kali@securitynik:~/forensics$ df --human-readable --type vfat --print-type
    Filesystem     Type  Size  Used Avail Use% Mounted on
    /dev/loop0     vfat   30G   12G   19G  38% /home/kali/forensics/usb
 
    offset=1048576 - mount the drive at this offset 

--source linux_mint_usb.raw - The source image which was created.

--target usb/ - The location to which this drive will be mounted.

Now that we know the drive has been mounted, we can now verify we have access

kali@securitynik:~/forensics$ ls usb/
 Fido-Apr04_2020-1.pdf   LINUX   PortablApps                              'System Volume Information'
 Girls                   Nakia  'SANS SEC582 - Labs and Challenges PDFs'   tshark

Let's now export all the files, printing out information relating to the file's last status changed date (%Cx), last status changed time (%CT), last access date (%Ax), last access time (%AT), last modification time (%Tx), last modification time (%TT), file permissions (%m), file numeric user id (%U), username (%u), group id (%G), group name (%u), size (%s), path (%P) and finally put ever entry on a new line (\n)

kali@securitynik:~/forensics$ find usb/ -printf "%Cx|%CT|%Ax|%AT|%Tx|%TT|%m|%U|%u|%G|%g|%s|%P\n" | more

Here is a snapshot of what the output looks like.

kali@securitynik:~/forensics$ find usb/ -printf "%Cx|%CT|%Ax|%AT|%Tx|%TT|%m|%U|%u|%G|%g|%s|%P\n" | more
12/31/1969|19:00:00.0000000000|12/31/1969|19:00:00.0000000000|12/31/1969|19:00:00.0000000000|755|0|root|0|root|16384|
04/06/2020|13:58:31.2200000000|04/05/2020|20:00:00.0000000000|04/06/2020|13:58:32.0000000000|755|0|root|0|root|16384|System
 Volume Information
04/06/2020|13:58:31.2500000000|05/13/2020|20:00:00.0000000000|04/06/2020|13:58:32.0000000000|755|0|root|0|root|12|System Vo
lume Information/WPSettings.dat
04/06/2020|20:14:57.0700000000|04/06/2020|20:00:00.0000000000|04/06/2020|20:14:58.0000000000|755|0|root|0|root|16384|System
 Volume Information/ClientRecoveryPasswordRotation
04/06/2020|20:14:57.1400000000|04/06/2020|20:00:00.0000000000|04/06/2020|20:14:58.0000000000|755|0|root|0|root|16384|System
 Volume Information/AadRecoveryPasswordDelete
04/06/2020|20:14:57.4300000000|05/13/2020|20:00:00.0000000000|04/06/2020|20:14:58.0000000000|755|0|root|0|root|76|System Vo
lume Information/IndexerVolumeGuid
04/07/2020|20:39:36.0000000000|04/07/2020|20:00:00.0000000000|04/07/2020|20:39:36.0000000000|755|0|root|0|root|16384|Nakia
04/07/2020|20:38:04.0000000000|05/12/2020|20:00:00.0000000000|04/07/2020|20:38:04.0000000000|755|0|root|0|root|1387601|Naki
a/Nakia code dot org certificate.pdf
04/07/2020|20:38:04.0000000000|05/12/2020|20:00:00.0000000000|04/07/2020|20:38:04.0000000000|755|0|root|0|root|766251|Nakia
/Nakia_code-org-blank_certificate.png

....

Let's now redirect this output to a file for later analysis.

kali@securitynik:~/forensics$ find usb/ -printf "%Cx|%CT|%Ax|%AT|%Tx|%TT|%m|%U|%u|%G|%g|%s|%P\n" > linux_mint_files_export.txt

Once the contents are all in the file, we can then check to see how many lines were written as follows:

kali@securitynik:~/forensics$ cat linux_mint_files_export.txt | wc --lines
106191

Looks like we have about 106,191 entries. 

You can now take this file and open it with spreadsheet document or even a database to perform analysis.

From our exported results, let's find a file of interest to learn about its activities in the next post.

An important takeaway for above, is that the data which was retrieved was from "allocated" space. That means, files which might have been deleted, are more than likely not going to be seen within this output. Thus you may wish to use another tool such as Autopsy or the SleuthKit to get a better handle on the information on the disk. Keep these things in mind as you perform your file systems forensics.

P.S. Not sure if you noticed it but I changed disks from the previous posts. However, the concepts remain the same.




Beginning File System Forensics - Acquiring Disk Image

In this series, I am looking at file system forensics. For this post, I inserted a USB device which can be found at: "/dev/sdb"

Taking a quick look at the disk using "fdisk --list" before we make a copy of it, we see:

kali@securitynik:~$ sudo fdisk --list /dev/sdb
[sudo] password for kali: 
Disk /dev/sdb: 29.3 GiB, 31457280000 bytes, 61440000 sectors
Disk model: USB DISK        
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00051443

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1        2048 61437951 61435904 29.3G  c W95 FAT32 (LBA)

We will revisit this as we compare our cloned disk with the output above.

Let's now go ahead and create an image of the disk, so that we can perform our "dead" forensics.

kali@securitynik:~$ sudo dcfldd if=/dev/sdb of=linux_mint_usb.raw bs=512 errlog=linux_mint_err.log hash=md5,sha1,sha256 hashlog=linux_mint_usb_.hash status=on verifylog=linux_mint.verify hashwindow=100M

Specify the input file, which we know is the USB located at /dev/sdb
if=/dev/sdb 


Specify an output File
of=linux_mint_usb.raw 

Specify a block size of 512 bytes.
bs=512 

Send all errors to a log file, rather than writing to the screen
errlog=linux_mint_err.log 


Specify the hash algorithms to use. This ensure we can validate the integrity of the image as it is analyzed during the forensic process.
hash=md5,sha1,sha256 


Send the hash information to a log file
hashlog=linux_mint_usb_.hash 

Displays the status message
status=on 

Send the verified results to a log 
verifylog=linux_mint.verify 

Perform a hash on every 100 Megabytes
hashwindow=100M


Once completed, here is what the output looks like:

61440000 blocks (30000Mb) written.
61440000+0 records in
61440000+0 records out

Looks like the total records read in equals to the total records written out. 

and the created files

kali@securitynik:~/forensics$ ls 
linux_mint_usb_.hash  linux_mint_err.log  linux_mint_usb.raw  linux_mint.verify


Looking at the "linux_mint_err.log" file

kali@securitynik:~/forensics$ ls 
linux_mint_usb_.hash  linux_mint_err.log  linux_mint_usb.raw  linux_mint.verify

Looking at the "linux_mint_usb.hash" file 

kali@securitynik:~/forensics$ cat linux_mint_usb.hash | more
0 - 104857600: a833657ba6ffe7aecc9502474830d0e3
0 - 104857600: 9c1a801e95178826c4e49bb498fdae18389429fa
0 - 104857600: 74b7b3f871998cc0bd614dea1d345e5057f87f0ff3579e8f372226ec0ae9e1df
104857600 - 209715200: 8d6305573b4500f27dbcee6cd582e4a8
104857600 - 209715200: 25bb8f02271ede26bfad67d6350ae038ee88a9f5
104857600 - 209715200: 308e467ed64fc4efb36a3c7e520ea6406e360fa260c7d87f9810345ecd09abf4
209715200 - 314572800: ce08ffdb8612f95e4752539044daf1ee
209715200 - 314572800: 4ae41ba71b7c70c470eadc8fa351d78c863facae
209715200 - 314572800: 987da527a07d254d8448233673b81a3843a0aafd0607527df67f333ebec0b913
314572800 - 419430400: 36c76342755d6828990a480c0056d31a
...
31352422400 - 31457280000: 75a8749d0ad3734052147bfa16069060
31352422400 - 31457280000: 9675bdbe94ccb0cd25601e35687a235a2630768a
31352422400 - 31457280000: 90db0b4ccf1b539dfc5c28cca76fd1e3b43316622c9fe4fc1f274ac0cb94e380

Total (md5): e995c8773f355b895792fafdc24e80d4

Total (sha1): 1473fda5a96d0b286b6ffba2b9f2550c1b67ab93

Total (sha256): 998a16707ee4aec57987e2ef768764d652cc55d648fc0f30b295b56b417b4747

Looking at the file "linux_mint_usb.raw"

kali@securitynik:~/forensics$ file linux_mint_usb.raw 
linux_mint_usb.raw: DOS/MBR boot sector; partition 1 : ID=0xc, start-CHS (0x0,32,33), end-CHS (0x3ff,254,63), startsector 2048, 61435904 sectors

Now that we have the image, let's mount and perform some basic analysis in the next post.

Post in this series: