Cienega – A Project about Container Security

I have developed a new interest recently – Docker. As someone who works on DevOps on daily basis, I am very impressed by what containers can achieved in terms of deployment and maintenance, after deployed some servers for fun, I start thinking, how can I centralize the container logs for security monitoring?

I named this project “Cienega” because La Cienega boulevad is a street that I love and hate at the same time. After I have the name settled down, I spent some time to do my research for technical details, following is the architecture I am going to start with:

Log collector: Fluentd

The kubenetes and Fluentd integration is the main reason I choose to use it over other solutions such as Logstash, and the number of different plugins in Fluentd can make log parsing easier.

Log Streaming: Kakfa

To consider the scalability of project, it would be better to have a robust data pipeline. Kafka is the best choice for data streaming and I am also not a stranger to Kafka. That’s why I picked up Kafka.

Log Storage: InfluxDB

This is a hard decision to use this time-series NoSQL database. First I do not think relational database will be a good choice after I have seen the inconvenient of the relational database by having a less flexible structure, I believe logs are more like “json” than “csv”, so NoSQL would suit my situation better. Second, among all the NoSQL solution available, I chose this Time-series database over MongoDB or Apache Cassandra is because of the target I am monitoring – Containers. Containers are applications are not users, I am thinking a time-series database would be more easier to track the trend of the application because application logs can be less random than user logs.

Log Analytics: Pending

Using Influxdb means I may not able to use ELK stack anymore, Influx has its own stack called TICK but I still need to try it and see how advance it can achieve and how the performance looks like.

Next step will be run each component in containers in my lab, getting familiar with all these services and write some code for writing data to InfluxDB from Kafka. I will updating my GitHub repository and sharing some learning note on this blog.

Dissect Cyber Kill Chain – Reconnaissance Part 1

What is hacking actually looks like when it is not in the movie “Wargames” in which a middle schooler magically log in theirs school’s “vulnerable”grading system as a high privilege user after insert a floppy disk into a big-head computer in his bedroom so he can change his biology grade from F to C in a snap? It is not that easy, it needs patience, strategy, it takes time, might as long as two terms of two different presidents of United State (See how Iran nuclear plant being exploited by Stuxnet Malware). However, there also is a common strategy that being used by most of cyber attack — Cyber Kill Chain.

This blog will dig into how first stage of Cyber Kill Chain — Reconnaissance works in a technical way from an attacker perspective.  Which information is wanted specifically and which tools can be used to achieve that? And some of my personal experience and preferences when I dealing with those tools will be provided so this article won’t just boring like a man page.

  1. Getting to know the weakest spot of your target —Human

When we look back on the successful exploitations conducted by elite APT hacker groups, one thing in common is human is most likely be the first one who get exploited and compromised  so attackers can gain theirs first access into the system. It’s not impossible for attackers to crack the credentials of a public facing SSH server or router by brute force in order to get initial access, there is a possibility in there and this actually happened in a company I dealt with before. But comparing with strategy like brute force which not only consumes ridiculously amount of processing power but also makes a loud noise that can makes you easily expose yourself, social engineering is definitely a shortcut to take. In the end, this most essential information to make this phishing exploitation happens seem simple— Email Addresses.

“theHarvest” tool comes in handy when you want to automatically extract a list of email from the website of your target. By giving the website of your target and the source you want to use to search for email addresses, theHarvest will enumerate email addresses for you.

Syntax:

theHarvest -d <taget website> -d <source>

example: theHarvest -d zwduck.com -d google

Tips: Don’t limit the power of theHarvest within google, theHarvest supports many other resources, sometimes bing or duckduckgo or Linkedin might have a better result.

2. Scan Network from outside

Hands are tied when scanner is placed outside of the network, there are firewalls, DMZ, bastions, and not to say IT guys are doing their job. But we should also believe that human make mistakes. I have seen a VPN router using default credentials has been left 443 port open to public and after authenticated there is a built in cmd tool which is able to open a shell of router’s operating system for you. Anyway, scanning from outside is not a “low hanging fruit” which can provides a quick result, but who knows. 

When we start scanning, we may think of the most essential and widely-used scanner—Nmap, but there is no need to jump on Nmap right now because there are couple of preparation steps need to be done before we bring Nmap out.

First step is find what IP range of your target using, If there is a big name company we are talking about, bgp.he.net will help you identify the IP range for you, if it is a small company whose IP range is relatively small and not publicly available, social engineering might works at its best.

Second step is after IP range is identified, the IP addresses that are accessible for us need to be extracted from this list. “Ping Sweep” is what we want and “netdiscover” is the enumeration tool can be used in this stage

Syntax:

netdiscover -r <subnet address>

example: netdiscover -r 192.168.1.0/24

Third step is where Nmap comes to play, Nmap is able to detect opening port, potential operating system and even conduct a vulnerability scan. Since Nmap has numerous functions and being called a Swiss Army Knife of network utilities, I will only pick some tips and tricks of Nmap.

1)Don’t forget there is might still have a firewall in between of you and your target, so use SYN scan to make it stealthy. A regular scan will get blocked by firewall or IPS for most of time, but I SYN Scan can bypass them.

Syntax:

nmap -sS <Target IP address>

2) A loud banner scan will provide you a much more detailed information including version number of running service, but it will also get you blocked. It is a tradeoff but still worth a try.

Syntax of banner scan I prefer

nmap -sV -sT <Target IP address>

3) Identify the operating system using fingerprinting: Result of this scan is mainly for reference use since the result it not 100% accurate. If OS is a router’s OS, you target probably is a VPN router, if OS is a Linux box, your target might be a web server. Making a good guess is absolutely a critical part of hacking.

Syntax:

nmap -O <Target IP address>

4) Don’t give up on unpopular ports: By default, Nmap will go through top 1000 popular ports. But some hidden gem may running on a random port. I have heard a company migrates mysql port from 3306 to a higher port. Scanning all ports can be a dreadful and hideous project, but enumeration is the key to find vulnerability.

Last step is be persistent, picking up your methodology of network scanning and set it up as a cronjob to run it on daily basis because you never know what going to happen tomorrow. Make a bash script, run you scanner, and then compare the output with output from yesterday. All you need to do is check the different between today and yesterday.

Next part of Reconnaissance will discuss about the result of port scanning, when we looking at an opening port, what should we think about and what need to be done, and what can be done.