Logging

[eroyee]

I think it would be useful to log http get requests to file, similar to the way Apache/NGINX log to access.log?

Essentially, at INFO level, I'd like to see the accessing IP address recorded, and perhaps some limited additional data such as frequency in use. Perhaps this could be enabled on screen for others to see, although personally I'm quite happy tailing a log file from the cli :-)

Not wanting to be one of those who ask for something without contributing I will say that I've done this already, rather crudely (to file), and am working through what I believe to be useful detail. As part of this I created a log file path/name and log level parameter in the conf file, thinking that to be the most elegant way of dealing with things.

However what I've done is really rather a hack, and no doubt could be done far more elegantly! So at this stage I'll limit my contribution to simply recording this note for the record, particularly in case it's already in the pipeline.

[jketterl]

Well, you wouldn't find any frequencies in that access log anyway. The receiver control commands are sent via websockets. I think they are actually in the output right now, but this is more by carelessness than by intention (i.e. I have forgotten to remove the logging).

I am trying to keep OpenWebRX without any logfile interaction on it's own. The current idea for basic logging in Linux is to just log to stdout. This is actually not really too bad of a pattern, since you can see what's happening when developping, you can inspect the output with journalctl on most modern Linux platforms, or you can get the output with docker logs.

I have disabled the access logs for the http part because there's not too much of interest there for now. The webserver has been running stable, but the files it serves are pretty much all the same whenever somebody connects. You can easily get it back by manipulating the loglevel in owrx/http.py. The messages are sent on debug by the log_message method; The loglevel on top however is set to logging.INFO at the top.

[eroyee]

In my hack I'm outputting frequency data to the logfile, this is purely for interest really. It could have some statistical value, and if an operator was keen they could use that to improve things like their antenna.

However, of greater importance is logging IP address and connection time. To my mind any publically exposed server should log this.

The main reason of course is for security, particularly where one allows access to settings such as I understand you're enabling? By logging this data it gives the ability to use standard tools such as fail2ban (or iptables directly for certain jobs) in order to protect a system.

Anyway I'm happy with what I'm putting out to the file presently, and thanks for the info you provided. I added a few lines of code to http.py, and altered main.py to suit my use case. Particularly with a headless server a decent log is a bit more useful than stdout :-)

EDIT:

Just caught a probe this morning from 119.147.171.64 (China, of course!) on the completely non-standard port I'm using for OpenwebRX. Whatever they were trying to do caused an exception error in python's socketserver, and me to look at geoblocking China on this server [which I already do on others] >:-(

[jketterl]

Well, I'm certainly not going to support geoblocking, if that's what you're looking for. If there's bugs in the python socketserver, you may bring them up with the python dev team, I suppose, but they will probably tell you that their webserver is not intended to be used publicly.

Warning http.server is not recommended for production. It only implements basic security checks.

[eroyee]

Yes, I assumed you were aware of that python comment, but wasn't going to mention it (I didn't want to appear critical of OpenwebRX - very much the opposite!).

I think logging is not only useful in providing interesting detail for the station owner as to who is using their system, but also it allows for some security checks and possible debugging if a problem arises.

It's certainly not about geoblocking per se. Rather, if one found it necessary, you could be more specific around denying certain IP numbers that may have attempted to attack the system.

Geoblocking is blunt tool, but in the absence of logging/auth you can't use something like fail2ban, and with a possibly insecure http server there's perhaps some argument for it. I should add that as I see logs of other public servers I'm only too aware of likely geographical sources of attack.

FWIW I did set up an Apache reverse-proxy for OpenwebRX, thinking that might harden the system a little, and possibly allow the use of HTTPS. The latter is partly due to another (client) site that uses Squid proxy, at which OpenwebRX (and KiwiSDR) doesn't work. The issue appears to be around Squid's operation with websockets and there was some thought that an ssl instance would circumvent the problem.

Anyway I wasn't going to speak about that too much, and I've not had time to pursue it further (I was more bothered about AGC :-). Besides anyone sufficiently concerned about security would probably know how to run a reverse proxy etc.