[TIP] - Improving "Elastic Search command line" security and auditing

Hi there!

As we most know, elasticsearch CLI options are very dangerous when somebody logged at shell, even if they are not root in special default installations.

Since Elastic Search 2.X, by default it only bind on localhost, what increase a lot default installation security. But what if an attacker has somehow access to a non-root user ? Besides that how to track this in paranoid mode ?

To ilustrate this better I'll create this laboratory:
- CentOS 7.1
- Elasticsearch 2.X
- auditd
- iptables
- user segregation (counting that people has different users when logging to your system =))

Step One without hardening logged as a non-root user:

[elkuser@eventidlabs ~]$ whoami
elkuser
[elkuser@eventidlabs ~]$

[elkuser@eventidlabs ~]$ curl http://localhost:9200 -v
{
  "status" : 200,
  "name" : "EventID One",
  "cluster_name" : "eventid",
  "version" : {
    "number" : "1.7.4",
    "build_hash" : "0d3159b9fc8bc8e367c5c40c09c2a57c0032b32e",
    "build_timestamp" : "2015-12-15T16:45:04Z",
    "build_snapshot" : false,
    "lucene_version" : "4.10.4"
  },
  "tagline" : "You Know, for Search"
}

As we can see, you could easily run any command since there is no authentication in a default installation (and I dind't add anything to protect ES as a reverse proxy or shield).

But to improve monitoring first we could use audit basic rule:

# auditctl -a exit,always -F arch=b64 -S connect -k ELK

Result will be:

# ausearch -k ELK

type=PROCTITLE msg=audit(01-02-2016 21:18:57.770:191034) : proctitle=curl http://localhost:9200 -v
type=SOCKADDR msg=audit(01-02-2016 21:18:57.770:191034) : saddr=inet host:127.0.0.1 serv:9200
type=SYSCALL msg=audit(01-02-2016 21:18:57.770:191034) : arch=x86_64 syscall=connect success=yes exit=0 a0=0x3 a1=0x7f4484000a40 a2=0x10 a3=0x0 items=0 ppid=22817 pid=22842 auid=elkuser uid=elkuser gid=elkuser euid=elkuser suid=elkuser fsuid=elkuser egid=elkuser sgid=elkuser fsgid=elkuser tty=pts1 ses=1187 comm=curl exe=/usr/bin/curl key=ELK

Now to limit access only from a specific user to ES port we will use iptables with owner module (remember to add a group with logstash, elastic and other users you probably need to connect to this port besides root to make less rules).

 # iptables -I OUTPUT -p tcp --dport 9200:9300 -m owner --uid-owner elkuser -j DROP

[elkuser@eventidlabs ~]$ curl http://localhost:9200 -v
* About to connect() to localhost port 9200 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...

 And auditd

type=PROCTITLE msg=audit(01-02-2016 21:36:09.016:192757) : proctitle=curl http://localhost:9200 -v
type=SOCKADDR msg=audit(01-02-2016 21:36:09.016:192757) : saddr=inet host:127.0.0.1 serv:9200
type=SYSCALL msg=audit(01-02-2016 21:36:09.016:192757) : arch=x86_64 syscall=connect success=no exit=-115(Operation now in progress) a0=0x4 a1=0x7ffda9338d70 a2=0x10 a3=0x2 items=0 ppid=22817 pid=23071 auid=elkuser uid=elkuser gid=elkuser euid=elkuser suid=elkuser fsuid=elkuser egid=elkuser sgid=elkuser fsgid=elkuser tty=pts1 ses=1187 comm=curl exe=/usr/bin/curl key=ELK

That's not a big deal but we could improve security a bit using those steps. I'm just showing some basic info related to iptables and auditd, specially auditd you could create but of awesome configuration to monitor lot of other stuff as configuration modifications and if user is using sudo to root, you will have auid different from uid.

Besides Elastic Search you could user audit for lot of cool detection and paranoid. I'll create another post in pt_BR about auditd soon.

Good info related to auditd - https://www.digitalocean.com/community/tutorials/understanding-the-linux-auditing-system-on-centos-7

Happy Detection!

Rodrigo "Sp0oKeR" Montoro