readyornot's questions

I want my server to only respond to https requests and my SSL configuration is working fine. My question is about how best to disable http...

Is it better to have a default server block that listens to port 80 and returns a 444 (see below), or to just remove all port 80 server blocks altogether? I would assume that the latter is better because it would result in the server doing the minimum amount of processing, but I can't find anything about this online, so perhaps I'm missing something?

server {
  listen 80 default_server;
  return 444;
}

I'm trying to get a simple redirect working on my nginx server. I am receiving the 302 response code back, but the Location header is not set. What am I missing?

My minimal case (with a hard coded image):

location /redirectme {
    return 302 https://www.google.com/logos/doodles/2016/childrens-day-2016-brazil-5739205150900224-hp2x.jpg;
}

My actual use case (redirect the user to the URL passed into the url query parameter):

location /redirectme {
  return 302 $arg_url
}

Another config that I tried (manually setting the Location header):

location /redirectme {
  add_header Location $arg_url;
  return 302;
}

None of these work in actually redirecting the client to the new URL (only returning the 302). The rest of my web app works great, just not this redirection piece. If it makes a difference, I'm working within an ssl server {...} block. Any ideas? Thanks!

----- UPDATE ------

Here is the entire server block...

server {
  listen   443;
  server_name myserver.com;
  access_log /path-to/myserver.com-ssl.access.log;

  ssl on;
  ssl_certificate /path-to/myserver.com.crt;
  ssl_certificate_key /path-to/myserver.com.key;

  ssl_client_certificate /path-to/clientkey.pem;
  ssl_verify_client on;
  ssl_verify_depth 1;

  keepalive_timeout 5;

  root /srv/www/myserver/public/;

  location /redirectme {
    return 302 $arg_url;
  }

  location / {
    try_files $uri/index.html $uri/index.htm @unicorn;
  }

  location @unicorn {
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-CLIENT-VERIFY $ssl_client_verify;
    proxy_redirect off;

    proxy_read_timeout 60;
    proxy_send_timeout 60;

    # If you don't find the filename in the static files
    # Then request it from the unicorn server
    if (!-f $request_filename) {
      proxy_pass http://unicorn_myserver.com;
      break;
    }
  }

  error_page 500 502 503 504 /500.html;
  location = /500.html {
    root /srv/www/myserver/public/;
  }
}

And the response from doing curl -i:

HTTP/1.1 302 Found
Content-Type: application/json
Content-Length: 0
Connection: keep-alive
Date: Fri, 14 Oct 2016 18:37:32 GMT
x-amzn-RequestId: 44e865b2-923d-11e6-a60a-5f6291eee9a8
X-Cache: Miss from cloudfront
Via: 1.1 aa89533ad2ec5e0edba466c9920bd000.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 7dzQ9JQK380hFD-nFyJxm6mIWT5D4mWzvCbSAhDaa-pHwpF4oZHszw==

It may also be relevant (I don't understand how, but maybe) that I have Amazon API Gateway sitting in front of my requests, directly proxying them to my server (note: the ssl_client_certificate /path-to/clientkey.pem; is configured to only accept requests from API Gateway).

I have an Opsworks Rails Layer (nginx/unicorn) instance that has been running for a while, and I have successfully deployed my rails app to it many times directly from GitHub.

Yesterday, I started seeing a strange error where our latest code changes are not actually being deployed by Opsworks. i.e. I get a 500 error along with a stack trace that can only be from an older version of my github repo. The line where the error occurs no longer exists in the latest version of the code.

When I SSH into the instance and look at the /srv/www/<myapp>/current folder, I do see the latest code files, and I see a reference to the latest GitHub commit in the Opsworks Deploy log file. It looks like everything is being deployed properly (i.e. I see no errors in the log file and the Deploy finishes sucessfully) but obviously something is going wrong.

Does anyone have any ideas? Is there a code cache on the server that I don't know about? I finally tried stoping/restarting the instance and when it rebooted, I started getting this error: (111: Connection refused) while connecting to upstream - Opsworks Rails 4. I don't know if the two issues are related... maybe this is all about Unicorn not restarting properly... but right now, I'd really like to get to the bottom of why my latest GitHub repo code doesn't end up running on the server after what looks like a successful deployment.

Thanks in advance!

I have a question that is an extension of this one: Examples where an AWS Security Group is not sufficient as a firewall?. Initially, the answer in that question made sense to me and I was working with the assumption that the firewall that is an AWS Security Group is good enough for now for my app infrastructure (AWS VPC with public/private subnets + Internet Gateway + NAT Device + Elastic Load Balancer).

However, this morning when I woke up and checked my server logs, I saw that I had received approx. a thousand spam GET requests overnight to paths that don't exist, which resulted in 404 responses from my server. The requests kept coming and showed no signs of stopping. The IP addresses for the requests were different but within a specific range. So, I update the Network ACL Inbound rules on my Elastic Load Balancer and added one to DENY access to IP addresses from that range. At this point, the requests stopped hitting my app server.

I don't know if the attacker was trying to DOS me or if this is just standard spamming. I have been getting requests similar to this, here and there every few hours, over the past few weeks since my system went online, but the quantity/frequency of these requests was something that I've never seen. I am relatively new to server ops. I'm happy that I was able to block the attack from continuing to load my app servers, but I'm wondering if I had had a Web Application Firewall in place (implemented as a WAF sandwich: Load Balancer-WAF-Load Balancer), if the whole situation would have been taken care of for me.

As I'm new to this space, the answer is not clear to me when I read the product marketing details of different WAF products here: https://aws.amazon.com/marketplace/search/results/ref=srh_navgno_search_box?page=1&searchTerms=web+application+firewall. I'm really looking for practical advice on whether I need a WAF in my infrastructure (i.e. I can't actually rely on AWS Security Groups to protect my system from spam/DDOS) and what basic features I need in the product. Thanks in advance!

P.S. My app is NOT built on SQL, so I'm not worried about SQL injection attacks.