# Dwi Siswanto

Security R&D | Rapper | Shitposter | ACAB Empowering Teler HTTP Intrusion Detection as WAF with Fail2ban | Dwi Siswanto

# Empowering Teler HTTP Intrusion Detection as WAF with Fail2ban

March 16, 2021

Damn, it’s so good to be a defensive!

TL;DR — As you know, Teler is free & open-source real-time HTTP intrusion detection program that written in Go. Its use has skyrocketed (based on stars chart) and also thanks to the contributors who helped carry out the mission!

Basically, Teler is only able to detect — yes, of course, it’s an IDS, not IPS. Because the main idea is to be used for IoCs purpose that placed out-of-bands (and standalone). Unlike WAF — which can only be an man-in-the-middle of services, because it placed in front of web applications.

What can teler detect is such as:

• Common Web Attack (SQLi, XSS, SSRF, .etc),
• CVE attacks,
• Directory Bruteforce.

Take a look at main repository page to browse its features. I’m really sorry I didn’t make an article to introduce Teler, but — oh, have you seen my presentation slides, “Protect Your WebApp”? Also these videos may can help you to get started: “Tutorial: Cyber Threat Hunting — Useful Threat Hunting Tools (Part One)” by s3m1y (Semi Yulianto) & brief explanation (Indonesian) by Onno W. Purbo.

PSA: We’ve moved installation, configuration and more related documentations to Notion.

# Weaponize Fail2ban

So, let’s get to the main topic. First, the prerequisite needed is Fail2ban, and how it works is by scanning logs with patterns that indicate what they (log lines) shouldn’t (i.e. failure, 404, .etc). Once there’s such a thing, Fail2ban carries out predefined actions (e.g. ban IP by X or any conditions).
I understand it’s irrelevant to use Fail2ban for this — but, back to the subtopic, “iT’S So G0od”!

Fail2ban requires a filter definition and a jail configuration file. The filter instructs Fail2ban what to look for in Teler’s log files and the jail instructs it on how to respond to matches.

> wget https://github.com/kitabisa/teler/raw/development/teler.fail2ban-{filter,jail}.example.conf


The teler.fail2ban-filter.example.conf contains the following pattern:

$<HOST>$ $(Common Web Attack(: .*)?|CVE-[0-9]{4}-[0-9]{4,7}|Bad (IP Address|Referrer|Crawler)|Directory Bruteforce)$ .*\$


(Visualization of failregex pattern Fail2ban filter for Teler)

Note that failregex pattern above is standard output from Teler (you must adjust if you use JSON output logging format), and it applies to all types of threats that are in the Teler log (read: change the pattern according to your need). Oh, the **** tag is pattern for IP addresses and hostnames that apply in Fail2ban.

In the teler.fail2ban-jail.example.conf file section, there’s a logpath variable which we will define as the output file from Teler, and of course there are banning rules that we’ll use, update the pretty self-explanatory variables as you wish.

After Fail2ban configuration is ready, we’ll move those files into their respective Fail2ban subdirectories:

> cp teler.fail2ban-filter.example.conf /etc/fail2ban/filter.d/teler.conf
> cp teler.fail2ban-jail.example.conf /etc/fail2ban/jail.d/teler.conf


Then run Teler with the output pointing to logpath value according to previous Fail2ban jail configuration file:

> tail -f access.log | teler -c config.yaml -o /path/to/teler-threats.log


To load our filter & jail, it’s required to restart the Fail2ban service:

> systemctl restart fail2ban.service


After that, we’ve to see if the Teler jail is running with:

Status
|- Number of jail:      1
- Jail list:   teler


Looks good so far, but I need to test whether the Fail2ban filter for Teler really works, allow banning your IP (don’t do it in production) with:

> fail2ban-client set "teler" ignoreself False


So this is a demo that the Fail2ban filter for Teler is working:

(Demo of Fail2ban filter for Teler)

In case you accidentally lock yourself out from browse to local web server, unblock your IP by running:

> fail2ban-client set teler unbanip "127.0.0.1"


## Conclusion

It’s still not precise in use, because the actual flow is: request enters and Fail2ban filtering Teler log, then the web server (if not denied by Fail2ban jail), and finally it’ll be analyzed by Teler.
Yes, the Teler here will be the last process, because it read the access logs from the web server, meanwhile — if the maxretry in your jail configuration is 5, it means that (at least) the Teler log has detected 5 threats, then the initiation of request will NOT be counted by Fail2ban, so that the filter will work after 6 (or maxretry`+1) threat logs are detected on Teler, which will be imprecise.

How does it look? IMO, this is still useful to do so, but if you guys have any better ideas or suggestions, please drop to discussion panel in our repository.