naxsi
naxsi copied to clipboard
[FEATURE]: Allow log_format customization
Hi, first of all thanks for the amazing module!!
It would be really nice to have a configuration option to set the log_format. Currently we have Nginx running behind AWS ELB using PROXY_PROTOCOL
and the ip field in the naxsi logs are showing the ELBs IPs instead of the real client ip.
In Nginx we can set the log_format like this to catch the real ip.
log_format main '$proxy_protocol_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" "$http_user_agent"';
Having the same kind of option for naxsi would be awesome. This would also help us on our logging system for extracting fields of the logs and parsing them for reporting purposes.
Maybe #258 can help.
Hi @marcelomd, thanks for the quick feedback!
I'm afraid #258 does not do what I'm suggesting to.
What I'd need is basically a way to set how the logs generated by naxsi will be formatted.
Hello,
I think we will take inspiration for this and add it to @marcelomd PR.
Allow user to export the NAXSI_FMT
content in a variable, so it can be used in nginx's log_format
.
I guess it would fit both requirement while limiting unnecessary code :)
Hi @buixor, sounds great!!
Just wondering if it wouldn't be mutually better to not involve the Nginx logging format with this and just have a naxsi_log_forma
directive with its variables set and keeping it logging the way it already is!!
As I mentioned before, I need the naxsi logs to use the $proxy_protocol_addr
variable instead of the $remote_addr
for the ip:
field.
Just my .2 cents.
Thanks!
Hello,
I don't think I'll be down the naxsi_log_format
directive right now, and stick to @marcelomd approach which will be more extensive. However, I will give a look at nginx's log_format
mechanism to see if we can re-use it. The later approach won't come before 0.57 I think ( while @marcelomd's PR should land in 0.56)
Hi @buixor, sounds good!
Thanks!!
Hello !
I have the same expectation as @danlsgiga because my Nginx server is behind Cloudflare. Everything is great in Nginx logs because I use the "real ip" to get from the X-Forwarded-For
header.
But Naxsi still logs the errors with the Cloudflare servers IPs and I don't find a way to change it. It would be ok as the requests are still blocked, so there is no real security warning. Yet I can not use Fail2ban to block the Ips from Naxsi logged errors without getting the real client ip in the logs... Even worth, I can not create withelist rules based on IP (mine for example)...
I will wait the 0.57 to see if it will work ;) Thanks for the hard work !
@Montano5 : I think that it's a bug in nginx - in 1.8 with real-ip works fine, in 1.10 it doesn't.
@theundefined : Oh, I think you're right, I'm using Nginx 1.10.2 indeed... Thank you for the information !
thanks @Montano5 for the info !
That's great info! Thanks for letting us know... Is there any bug open for this on Nginx?
Hi, well i am not good that much in C/C++ but i was able to do this by adding the x_real_ip of nginx instead fo the connection->addr.
The change i made was on line 819 of naxsi_runtime.c (https://github.com/nbs-system/naxsi/blob/master/naxsi_src/naxsi_runtime.c#L819) change it with this code and recompile your nginx with naxsi module.
ngx_table_elt_t real_ip;
ngx_table_elt_t *real_ip_t = r->headers_in.x_real_ip;
if(real_ip_t != NULL){
real_ip = real_ip_t[0];
sub = snprintf((char *)fragment->data, sz_left, fmt_base,real_ip.value.len,
real_ip.value.data,
r->headers_in.server.len, r->headers_in.server.data,
tmp_uri->len, tmp_uri->data, ctx->learning ? 1 : 0, strlen(NAXSI_VERSION),
NAXSI_VERSION, cf->request_processed, cf->request_blocked, ctx->block ? 1 : 0);
}else{
sub = snprintf((char *)fragment->data, sz_left, fmt_base, r->connection->addr_text.len,
r->connection->addr_text.data,
r->headers_in.server.len, r->headers_in.server.data,
tmp_uri->len, tmp_uri->data, ctx->learning ? 1 : 0, strlen(NAXSI_VERSION),
NAXSI_VERSION, cf->request_processed, cf->request_blocked, ctx->block ? 1 : 0);
}
this code will log the X-Real-IP header in the NAXSI_FMT error log and if the X-Real-IP is not availible you will find the CloudFlare IP .
What i have now as log is :
2016/11/17 11:52:35 [error] 2363#0: *3 NAXSI_FMT: ip=[REAL CLIENT IP]&server=&uri=/'"><h1>test&learning=0&vers=0.55&total_processed=1&total_blocked=1&block=1&cscore0=$SQL&score0=8&cscore1=$XSS&score1=8&zone0=URL&id0=1001&var_name0=, client: 127.0.0.1, server: , request: "GET /'%22%3E%3Ch1%3Etest HTTP/1.0"
@danlsgiga Sorry for my bad english :p hope this help you as i have passed a whole day searching for a solution. Also i don't advise you to use this in a production mode but use it temporary and wait for the official release.
Have a nice day.
@benkhlifafahmi Thanks a lot!! This looks great from my perspective. Are you going to submit a PR to have it in for the next release?
Hi @benkhlifafahmi, did you submit a PR? Looking forward for this enhancement! Thanks
@danlsgiga I did but i guess there was a problem compiling the solution i submited, will check it again and re-submit the solution once it compile correctly.
Note: I have compiled the solution on our company server and it work fine, what i did is i enabled the x_real_ip module of NGINX when compiling NGINX with NAXSI.
@benkhlifafahmi - Looking forward to this enhancement.
@benkhlifafahmi Thanks for this PR! I'm looking forward for the release containing that piece of code.
Is log customization now possible?
I use 0.55rc1 from Dotdeb nginx-extras
and Naxsi still logs the LB address instead of the real_ip
.
@mathieumd and @danlsgiga i can confirm that the PR i pushed last time can be used on a production env. we are using this from NOV till now and it works fine :+1:
Thanks @benkhlifafahmi, good to know it is stable and works. I'll just wait for 0.6 to come out, which I wish it comes sooner than later. 😃
soon soon ! :D
Hi there,
I've seen this issue is schedule for O.57 and that's a good news. Do you know when it will be released ?
Any update or document for this issue, it's help us very well.
I think request_id and user agent and much more data will be useful, i think approach like access log is better just allow to nginx user add custom variable into log.
yeah ok is it done