# Log file encoding changing from ASCII to Binary



## larynx (Mar 5, 2018)

I'm running Fail2Ban 0.10.1 on FreeBSD 11.1-RELEASE with Nginx running inside a jail. I have Fail2Ban check the Nginx error log file for suspicious activity but the Fail2Ban log file shows a message saying it can't parse some of the lines in the Nginx log file because they're not encoded correctly. This is the type of message I'm getting:



> WARNING Error decoding line from 'var/log/nginx/error.log' with 'utf-8'. Consider setting logencoding=utf-8 (or another appropriate encoding) for this jail. Continuing to process line ignoring invalid characters: '2018/03/03 14:34:39 [info] 95523#100097: *89 client sent invalid method while reading client request line, client: 174.5.4.14, server: , request: "\x16\x03\x01\x01"\x01\x00\x01\x1e\x03\x03\xb9\xaer\xab\xc8J\xf0\x8eFr\xf3\xdd\x00\x00\x88\xc00\xc0,\xc0(\xc0$\xc0\x14\xc0"\n'



The error.log file shows up as "application/octet-stream; charset=binary" when I run the file command on it.
I tried setting up the Fail2Ban config file with utf-8 (as a default and in the Fail2Ban jail like the warning suggested) but that didn't work, I also tried to create a new error.log file and set it's encoding to ascii but it changed back to data after a while.

I don't know if this is a FreeBSD, Fail2Ban or Nginx issue that's why I'm posting here. Thanks


----------



## SirDice (Mar 5, 2018)

At first I thought of a broken malware bot. Looking for any specific bots I came across this:
http://www.noah.org/wiki/Apache2_Invalid_method_in_request_\x16\x03\x01

So my guess is a broken SSL config on a virtualhost that's responding with plain, unencrypted data on 443. Or somebody trying SSL on port 80. The encoding is a red herring.


----------



## ShelLuser (Mar 5, 2018)

You probably want to check NGinx to verify what kind of file format it uses for its output log. That's where I'd start.


----------

