Blynk.log Date/Time Format

Running Blynk Local Server-> server-0.40.2-java8.jar

Question regarding log entries in blynk.log (level=trace).

fail2ban requires date/time format in line items being scanned. In previous versions of the server, this was done (date & time). Here are some samples found on this site:
old version:
2017-01-30 16:24:08.782 INFO - HTTP API server listening at 8080 port.
new version:
17:44:43.376 INFO - Automatic certificate generation is turned ON.

I understand the archiving process but this does not work for fail2ban as it needs to use regex parsing for this information.

  1. Is there a switch or setting I’m missing to get this back in the log?
  2. Is it possible to get more IP address info in log for bad connections (hacking activity,etc)?


Not quite sure whats up with the zero support for this question? :thinking:

After applying iptables to traffic, one may want to re-consider running a local server…

Probably due its very niche range of general user interest.

Since trace is the lowest level of log, it may have been reduced to save space… have you tried any of the higher levels?

Thanks Gunnar for responding. I was hoping that someone knew of additional server switches to bring more information into the log file (more than INFO). If not, maybe a blynk developer like Dmitriy would chime in.

What brought me down this road was implementing fail2ban. Its a utility that works with iptables (part of debian stretch install) to firewall ip’s trying to hack your system through open ports. Many evil people out there.:hot_face:

Default SSH uses port 22 but that can and should be reassigned since we have many to pick from. In addition, users typically forward 8080 and 9443 to their local server ip. Anyhow, fail2ban is a filter type scanner where you can use regex expressions to parse log files for certain key words. For instance, I was using DEBUG logging and found:

-> DEBUG- Unsecured connection attempt.
-> DEBUG- Error resolving url. No path found. GET : /robots.txt

The ip’s were from another country and trying to access the web interface on blynk. After getting over the shell shock, I started looking back to 2017 and found all kinds of attempts.

My next step was to increase the reporting content using log.level=trace on the server. What I seen next was even worse. It was then I wrote my filter to scan the blynk.log and ban ip’s doing these nefarious activities. The problem I ran into was blynk was not listing ip’s for the below log entries/hacking events. Without the ip information, fail2ban cannot firewall the ip. I read on this site,reponse from Dmitriy’s, that a server reset (below) was caused by hardware or router. While that is true, its more likely caused by hacking attempts. I proved this by logging port activity on ports 8080 & 9443 (iptables-syslog contained source ip). I then compared the syslog time with the blynk.log and the below events were caused by those illegal access attempts.

  • 01:09:16.220 TRACE- Blynk server IOException. Connection reset by peer

  • 00:13:12.668 TRACE- HTTP connection detected.

  • 00:13:12.669 TRACE- In http and websocket unificator handler.

NOTE: The above entries Do Not contain ip’s so fail2ban cannot flag them.

As you stated, help on this topic from the community might be niche BUT these activities are happening if your running a local blynk server open to the outside world. I’ve implemented a set of interfaces (fail2ban & scripts) that have addressed the issue with much success. My hope is Dmitriy would add ALL ip information into the blynk.log so fail2ban can scan and firewall these types of events. Security is everyone’s concern these days and all these robots are eating bandwidth which we pay for. Bottom line, having some standards for a firewall would be a plus for the local blynk server community.

In summary:

  1. If your running a local server open to the outside world, robots & hacking attempts are happening. If your of the group :see_no_evil::hear_no_evil::speak_no_evil:…then stop reading and sleep well at night.
  2. After locking down admin web ip login, general security measures for hacking seem to end in blynk. SSL does not stop the attempts.
  3. Implementing a recommended firewall process for local blynk servers is easy with ip & full date logging. Yes, you will have a log size increase but simple crontab events can be set to clean the archive directory. Note: once fail2ban gets a hit, it has a DB that takes over tracking how long to ban it…blynk.log no longer needed.

If anyone is interested in more specifics, I’ll do my best to steer you in setting something up. Just for reference, I’m running a pi 3 and I’M NOT A UNIX GURU.

Regards and thanks again Gunner.:+1:

hai minnkid, can you tell me how to get fail2ban work with blynk log?

sorry english is not my first language, i’m still learning it