gelonida's questions

I have a uwsgi.ini file. It works perfectly, but if I add strict=true it fails with the message

[strict-mode] unknown config directive: inifile

however the word inifile doesn't even exist in my inifile.

In order to reproduce the error I went so far, that I created a uwsgi.ini file with only two lines.

[uwsgi]
strict=true

If I run uwsgi --ini uwsgi.ini I get above mentioned error

If I set strict to false I get of course errors about missing parameters.

Even if I use a yaml file with following contents:

uwsgi:
    strict: true

and I call with uwsgi -y uwsgi.yaml

I get:

[uWSGI] getting YAML configuration from uwsgi.yaml
[strict-mode] unknown config directive: inifile

So I think uwsgi wants to tell me something different, but I don't know what.

I like to keep the strict flag to be protected against typos or options that became obsolete or just exist in newer versions. It is difficult to diagnose if I don't get help finding the offending line.

I tested with uwsgi 2.0.18 and 2.0.21

for certain urls I'd like nginx to return a 'slow' 404.

Example:

nginx will reply to /special_path/non_existing with a 404, but only after 5 seconds

can nginx do this without / with a plugin?

I'm having one server, that is behind a reverse proxy, that I don't control. I'd like to use fail2ban to block nginx traffic under certain conditions.

normally fail2ban useses iptables to block traffic originating from the intruder's IP

However my server is behind a reverse proxy and from my server's point of view all traffic originates from the reverse proxy:

I found following url https://forums.freebsd.org/threads/fail2ban-behind-a-proxy.55041/ that suggests tu use iptables with package intropspection like for example:

actionban = iptables -I fail2ban-<name> 1 -p tcp --dport 80 -m string --algo bm --string 'X-Forwarded-For: <ip>' -j DROP

However the reverse proxy that I cannot control forwards the traffic as https traffic, meaning, that I cannot introspect the traffic for X-Forwarded-For headers as they would be encrypted.

Thus my question.

Do others have a similar scenario and is there an existing actionban = that adds Deny rules to nginx ?

Or do I have to handcraft a script trying to do this (edit nginx the nginx configuration and reload nginx)

What other solution would allow me to tell nginx dynamically which requests (containing specific X-Forwarded-For: headers) to block

I'd like to protect two servers against attackers who blindly probe for urls.

my idea is to block requests after a certain amount of 404 status codes.

I could do this with fail2ban.

However one of the servers is behind a reverse proxy that I do not control and that does not communicate the originating IP address (and it will need a very long time before the request of forwarding the originating IP address will be handled), meaning that from nginx's point of few all requests originate from the revere proxy's IP and obviously I don't want to block all incoming traffic if somebody provokes too many 404s.

Is there any way (without fail2ban, with fail2ban or with any other tool) to detect at least 404 errors from the same https connection and to terminate this connection or to let it 404 unconditionally for any subsequent request?

Please tell me if my question is not clear and I'll try to rephrase it, to give more information.

I have basic haproxy knowledge and know how to handle the selection of tcp backends depending on the SNI server name.

The relevant lines are

    acl is_myhost req.ssl_sni -i my.host.com
    acl is_otherhost req.ssl_sni -i other.host.com


    use_backend mybackend if is_myhost
    use_backend otherbackend if is_otherhost

Now I'd like to change them to something that allows me to chose the back end also depending on the source ip but I don't know the exact syntax for below pseudo configuration or whether this is possible at all

    acl is_myhost_for_specif req.ssl_sni -i my.host.com <and source ip = 1.2.3.4>
    acl is_myhost_for_others req.ssl_sni -i my.host.com <and source ip != 1.2.3.4>
    acl is_otherhost req.ssl_sni -i other.host.com


    use_backend mybackend1 if is_myhost_for_specific
    use_backend mybackend2 if is_myhost_for_others
    use_backend otherbackend if is_otherhost

I'm looking for a setup where I'd like to have SSL client certificates for all but one source IP.

My idea is to set

 ssl_verify_client optional;

and to add an elaborate if statement to the locations. However I don't know how to write such an if statement.

  # this requires ssl client certificates for all locations
  location / {
    if ($ssl_client_verify != "SUCCESS") { 
       return 403; 
    ...
  }

  # now what to write to require ssl certs except if source IP is e.g. 1.2.3.4
  location /two {
    if (?????) { 
       return 403; 
    ...
  }

Edit: Additional information

The switch ssl_verify_client with the value optional tells clients, that they can but don't have to send client certificates.

So by checking the variable $var_ssl_client_verify I can see whether a client certificate was presented and valid (SUCCESS) or not. This rule shall be applied for all clients, that do not have a given source IP. For one specific source IP I do not want to verify client certificates.

What I need is something like

    if ($ssl_client_verify != "SUCCESS" and source_ip != 1.2.3.4 ) { 
       return 403; 
    }

Edit 2: I changed the title from setup nginx to require client certs for all but a given source IP to setup nginx to require certain conditions of a location for all but a given source IP as what I am really struggling with has nothing to do with client certificates, but with combining if statements and filtering conditionally on the source IP address.

Rephrased question: (Not sure it's really clearer)

I have a small self written script, that monitors multiple servers. In fact my script just starts periodically tiny smalls scripts and gathers the output. At the moment it starts two per server I want to monitor (one server_is_up script and one server_cert_expires_within_x_days script)

So it obtains following information

• whether an http (nginx) server is up. (try to get favicon.ico via http(s))
• the expiration date of an http server's cert (establish an SSL connection, receive the cert and parse it)

Now I have some nginx servers with client certificate authentication and the CRL files are stored on the nginx server.

What would be the best way to write a script, that tells me whether an nginx servers CRL are exiring within x days.

Is there an easy way to remotely obtain the CRL's expiration date?

I could of course install a cronjob on each server that runs openssl, extracts the expiration date and saves it in a file and my 'monitoring script' just calls a script to perform an http request to retrieve the file generated by latter cron job.

What I wanted to know whether there is any more 'elegant' way of checking the expiration dates of a server's CRLs.

How for example are professional monitoring tools doing this? Is there something built into nginx that makes this task easy?

How do others monitor, that their CRLs are updated as they should?

Is there any way to create a custom log file, that allows to see which requests were handled in the same keep-alive session?

I'd like to create some logs and to estimate how often new sessions are created and what typical live times a keep alive session has in some given scenarios.

If possible I wouldn't like to create debug logs for this but just add one item more per log line for each request.

I have a web site, that is visited by many different mobile devices and embedded devices.

Quite often I encounter the issue, that some devices cannot connect.

The reasons can be:

• the device doesn't recognize an certain CA
• the device is too old and would require an older protocol TLS1.1
• the device requires an outdated crypto algorithm or just a crypto algorithm, that I didn't make available with me server conf.

As the devices are in remote locations, don't have easily accessible logs I would like to be able to analyze such issues with nginx logs.

I can do this by increasing the error-log log level to debug.

error_log  /var/log/nginx/errors_with_debug.log debug;

However this logs contain loads of things which I am not interested in.

Is there any way to log detailed information only if an ssl connection was refused but have a normal error log level for all other cases?

So far I enable debug logging, ask remote users who have issues with their devices to connect and record the the traces, disable debug level, reload nginx and analyze then the obtained traces.

In fact I would already be helped if I could just log the date and the ip address of any client that failed to connect due to SSL issues.

Ideally I'd also like to log the reason, but alerady knowing, that a connection was attempted but failed due to SSL would be very helpful.

I often encounter following problem.

I have an nginx server serving two hostnames via https on the same IP and the same port. Each host name has it's own cert.

What I am doing so far is to have two configurations:

server {
    listen              443 ssl;
    server_name         www.example1.com;
    ssl_certificate     www.example1.com.crt;
    ssl_certificate_key www.example1.com.key;
    ssl_protocols       ...;
    ssl_ciphers         ...;
    ...
}

and

server {
    listen              443 ssl;
    server_name         www.example2.com;
    ssl_certificate     www.example2.com.crt;
    ssl_certificate_key www.example2.com.key;
    ssl_protocols       ...;
    ssl_ciphers         ...;
    ...
}

Is there any trick to have this done in only one server block?

The reason I'm asking is, that both servers share apart of the name and the cert exactly the same config.

What I do so far is:

server {
    listen              443 ssl;
    server_name         www.example1.com;
    ssl_certificate     www.example1.com.crt;
    ssl_certificate_key www.example1.com.key;
    include /etc/nginx/common_config/example1_and_2/*;
}

server {
    listen              443 ssl;
    server_name         www.example2.com;
    ssl_certificate     www.example2.com.crt;
    ssl_certificate_key www.example2.com.key;
    include /etc/nginx/common_config/example1_and_2/*;
}

Can this be improved is there some standard recommendation? If this is at good as it gets, is there at least a recommendation for the path to such common config giles?