In my previous blog post I created a system to monitor my network traffic. This system is capable to visualize connections even in geographic manner. Checking the data I found two network devices who phones home to servers located in China. What can I find out about those connections. What are they? Do they pose any security threat to me?
My sole purpose was to experiment and learn new things. Please mind that I could pick any other countries the same way as I chose China. Although I have security concerns, I want to learn and not to make statements over any countries or vendors.
I wanted to see what happens on my home network. Is there something going on I should be aware of? Is there any device which creates suspicious connections like phoning home? I will use OpenWRT and syslog-ng to get the answers and Elasticsearch to get analytics.
SOHO routers are usually not really resourceful, neither is mine. Therefore I needed a solution using as little resource as possible but still capable to answers that questions. My solution uses connection tracking data from the main OpenWRT router. Offload the information from OpenWRT to a central syslog server. Enrich it with GeoIP, Reverse DNS and session length metadata by using syslog-ng. Then analyze the logs with Elasticsearch.
The first part of this blog series answers where the packets come and go and some metrics. What are inside the packets is up to another posts. Continue reading
We already have a central log server where we can collect logs of Docker containers. It is very common to run web servers running in containerized ecosystems. In this tutorial I show you how you can parse access logs of NGINX or Apache with syslog-ng. I also describe how visualizing NGINX access logs in Kibana can be achieved.
This simplified guide to logging Docker to Elasticsearch shows you how to send logs of containers into Elastic. Although there are many tutorials on to logging Docker to Elasticsearch, this one is different from all as it uses syslog-ng. Visualize them on a nice dashboard in Kibana. And you can download it all at the end of the post!
Update: I moved the chapters about parsing and visualizing NGINX / Apache access logs in Kibana into a dedicated post / github repo.
Update 2: This post has been refactored and simplified to be compatible with Elasticsearch ECS and make it easier to implement. Compatible with Elasticsearch 7.x. Continue reading
In the last post I wrote about how you can create a central syslog server. This time I will show you how you can use syslog-ng to parse fail2ban log messages, enrich it with GeoIP metadata and send into Elasticsearch. You can even visualizing Fail2ban logs in Kibana to see where the failed login attempts are coming from.
Update: This post has been reviewed and all Fail2ban and GeoIP related contents have been merged here from the previous post. Look no further, you will find everything you need here. Note that this guide requires Elasticsearch 7.x.
Your home network might already contain some devices or systems like a home server, a WiFi router, a media player, or home automation system. It is a best practice creating a central syslog server and storing logs of various sources in one place.
Update: The fail2ban and GeoIP related contents have been merged into post visualizing Fail2ban logs in Kibana.
This post will cover the basics. Creating a central log server and receiving logs from an OpenWRT device. Please note that you can do many more. See the other posts I created in this subject.
I already had plans to write about Docker. However a recent system update caused issues and Docker failed to restart. This service outage made me think and write about such a typical maintenance task.
I know that I created the issue at the first place. However I could fix it and I will show you how I did it and how can I avoid that in the future.
When I created a central file sever, I mentioned that some of the problems with the solution are yet to be resolved.
- YaST created an import rule in file /etc/fstab, which is the de-facto place for storing such information. Its content and the mounts are usually static in server environments. On most client (in term of using an export of an NFS server) the network connectivity rarely or never changes in traditional environments.
However in case of mobile devices like on laptops, the network state could vary a lot. It can be offline, or on WiFi, or on wired connection, maybe using VPNs. We need much more flexibility than a mostly static file.
- Users would like to mount exports on their own. The system should be as transparent as possible to the end users.
Lucky for us, mounting NFS exports by using autofs service help us and gives the following advantages too. Continue reading
In 2019 almost everyone has a digital life, so as I. Having digital photos or videos taken with our smartphones is an every day action.
Year by year the number of smart phones and computers rises in households. Files started to be found everywhere. In your computers, in the cloud, everywhere
Why do not we store them in one place and access them from everywhere?
I wanted to create a file server providing a central location for all our digital data. Creating an NFS file server looked promising.