
Gixy: Nginx Configuration Static Analyzer - petercooper
https://github.com/yandex/gixy
======
mrb
It is unsafe to configure Nginx to use _any_ DNS resolver other than 127.0.0.1
("resolver x.x.x.x") because the transaction ID can be predictible, and Nginx
fails to randomize the UDP source port. Gixy should check for that. Strangely
the Nginx developers _staunchly_ refuse to consider this a security flaw. See
[http://blog.zorinaq.com/nginx-resolver-vulns/](http://blog.zorinaq.com/nginx-
resolver-vulns/)

~~~
user5994461
It is more than unsafe. It is plain stupid.

There is no resolver running on 127.0.0.1 ... except on a couple of systems.
If I have to make an educated guess, the guy who wrote that is running on
Ubuntu.

~~~
pbarnes_1
It takes 10 seconds to install unbound.

~~~
omginternets
>It takes 10 seconds to install unbound.

And a lot longer to ensure people know to do this.

------
TheAceOfHearts
I haven't tried this yet, but I love the idea of it! ShellCheck [0] is a
similar tool for shell scripts. I'd love something similar for common
configurations like ssh servers, apache, etc.

For many of these tools there's objectively wrong configurations, where you'd
only use certain settings for legacy reasons. But it's not always clear for
newcomers.

[0] [https://www.shellcheck.net](https://www.shellcheck.net)

~~~
viraptor
There are a few solutions for that. I worked on
[https://github.com/HewlettPackard/reconbf](https://github.com/HewlettPackard/reconbf)
another popular one is
[https://github.com/CISOfy/lynis](https://github.com/CISOfy/lynis)

------
orf
Woah this is awesome, we just ran this and found that we have this[1] issue in
our config. Thanks for this! I'm going to add it to our CI runs.

Edit: the add_header config option is quite confusing and I had absolutely no
idea it behaved like that, I highly suggest trying this tool on your configs
and seeing what it reports.

1\.
[https://github.com/yandex/gixy/blob/master/docs/en/plugins/a...](https://github.com/yandex/gixy/blob/master/docs/en/plugins/addheaderredefinition.md)

~~~
tucaz
May I ask what's your setup so your nginx conf file is part of the CI process?
Any reference you could share is welcome.

~~~
orf
We use gitlab, here is roughly what our stage looks like:

    
    
       Run Gixy:
          image: python:3
          stage: code_check
          cache: 
             paths: 
                - .pip-cache
          script:
            - pip install gixy --cache-dir=.pip-cache
            - gixy nginx.conf

------
mozumder
What's a typical latency increase (on a purely localhost) of adding SSL/TLS to
nginx?

I've been doing some testing, and I see an increase of about 40-60ms, just for
initial connection server compute. Is that normal? How does one reduce the
initial SSL/TLS connection compute time?

My web app responds in 1-2ms. Adding another 40-60ms on top of for https that
wrecks latency.

~~~
elithrar
a) what is that as a fraction of the total RTT in "real world" conditions (not
localhost)

b) with session tickets configured, do you see this increase consistently for
the same client?

c) would your users find it acceptable to have the occasional 50ms hit on a
full handshake in order to get authentication & encryption? would they even
notice (see 'a')

~~~
mozumder
a) It's a pretty large percentage (~50%) for viewers within my target critical
region (east coast) but it becomes less important when accessed worldwide.

b) Session tickets cuts it from 60ms down to about .5ms extra delay (when
loadtesting with a keepalive https connections) so this is really only an
initial handshake problem.

c) The localhost full handshake latency problem is really a proxy to the real
problem: the CPU load. TLS/SSL is adding a lot of compute requirement to each
initial connection. This becomes important as I have to deal with celebrity
content, where a single Twitter link can lead to hundreds of thousands of
incoming connections within a few minutes.

TLS/SSL handshake compute requirements really need to be sped up somehow..

~~~
pfg
60ms sounds like too much. How are you measuring this, and what does your TLS
config look like?

A quick test with ab (-n 1 -c 1) against a nginx instance shows about 5ms for
me, on an Intel E3-1245 V2 @ 3.40GHz. This is with a P-384 key, so it would be
even less with P-256 or RSA-2048 (which, IIRC, have fast assembler
implementations in openssl).

------
gshulegaard
Pretty cool to see a tool like this generate so much interest!

I work on NGINX Amplify and we have been playing with config analysis for a
little while as a cloud-based reporting tool.

This hit my radar originally when they wrote their blog:
[https://habrahabr.ru/company/yandex/blog/327590/](https://habrahabr.ru/company/yandex/blog/327590/)
(they referenced Amplify)

------
Hamcha
Wow, it found some issues (add_header_redefinition) right away. I'll be sure
to add it to my toolchain (my nginx.conf is generated). Good find!

------
wanderr
Seems to choke on my map complex directive. [nginx_parser] ERROR Failed to
parse config ... Expected end of text (at char 148), (line:8, col:1)

the line in question: map
$cookie_MULTI_SITE_3:$cookie_client_ms:$cookie_counselor_ms $magic_root {

there's a simpler map directive above this one that it doesn't seem to have a
problem with

------
pyoungworth
Does anything like this exist for Apache?

------
nisa
great project! but breaks on my nginx config (several vhosts, lot's of
subdomain specific stuff)

~~~
buglloc
Hi! Can you file the issue with more details about problem? I'll try to fix :)

~~~
pbarnes_1
I get this as:

[nginx_parser] WARNING Skip unparseable block: "http"

Which presumably means it's broken there too? :)

~~~
buglloc
Yep, probably this is Gixy bug :( Can you show your http section? Maybe better
via email: buglloc@yandex.ru :)

