The plain HTTP request was sent to HTTPS port

Server NGINX
1

So we’re doing a credit card transaction and it comes back from paypal
on
the return trip with that error (on our end). The reason is that the
return
URL is:

http://www.domain.com:443/…

so its trying to access port 443 via http.

I won’t know till tomorrow, but I hope that we can adjust the return URL
to
correctly be "https://www.domain.com… than it works as it should.

My question is, should I put something in the Nginx configuration file
that
if someone tries to access “http” using port 443, redirect them to
https?
If so, how? Is that the correct way of going about it outside of
correcting
the return URL (which of course would be the ideal way), but in general,
should requests coming to http://www.domain.com:443 be forced to HTTPS?

Thanks!

2

On Thu, Aug 20, 2009 at 09:05:18PM -0400, Ilan B. wrote:

My question is, should I put something in the Nginx configuration file that
if someone tries to access “http” using port 443, redirect them to https?
If so, how? Is that the correct way of going about it outside of correcting
the return URL (which of course would be the ideal way), but in general,
should requests coming to http://www.domain.com:443 be forced to HTTPS?

nginx supports some internal error codes to handle error_page
redirection:

 error_page  497  https://$host$request_uri;

497 means that plain HTTP request was sent to HTTPS port.

3

I’ve come across this setting for nginx, but am not sure if this will
solve
it?

proxy_set_header X_FORWARDED_PROTO https;

2009/8/21 Igor S. [email protected]

4

On Fri, Aug 21, 2009 at 09:08:42AM -0400, Ilan B. wrote:

I’ve come across this setting for nginx, but am not sure if this will solve
it?

proxy_set_header X_FORWARDED_PROTO https;

This depends on proxied server.

5

Igor,

Thank you for the fast response, I’m not exactly clear regarding your
question. Currently we’re passing all of our requests to PHP via
fastcgi.

2009/8/21 Igor S. [email protected]

6

On Fri, Aug 21, 2009 at 09:53:10AM -0400, Ilan B. wrote:

Igor,

Thank you for the fast response, I’m not exactly clear regarding your
question. Currently we’re passing all of our requests to PHP via fastcgi.

Then you probably need

fastcgi_param X_FORWARDED_PROTO https;
or
fastcgi_param HTTPS on;

This depends on PHP scripts.

7

Anyone using fail2ban w/nginx? What are some good rules to protect
against
attacks? I’m getting slammed here.

8

How are you integrating protection against bots and scanners?

Are you integrating iptables with nginx?

We were thinking about something like this:
if x amount of requests
redirect to different domain that has a page informing them they have
been
redirected for x amount of time

is that possible with iptables?

If so will it disrupt good crawlers like google?

9

On Sun, 2009-08-23 at 10:02 -0500, AMP Admin wrote:

Anyone using fail2ban w/nginx? What are some good rules to protect against
attacks? I’m getting slammed here.

Describe characteristics of these attacks. What hurts you most ( your
bottlenecks )? Giving us your OS might be helpful too.

10

On Sun, Aug 23, 2009 at 12:18 PM, AMP Admin[email protected] wrote:

On the nginx box I keep getting people scanning or something making too many requests. I don’t wanna lock out good bots like google so I’m thinking maybe fail2ban would be good for nginx.

You can easily block simple DoS attempts using fail2ban. Check the
wiki and the fail2ban etc conf.d directory for examples. You simply
need to point the parser at your nginx log and match a regex for x
amount of requests per second. Fail2ban excels at locking out brute
force attempts but it does not excel at port scans or trickle-type
scans. Plus it is potentially CPU intensive since it has to regex
every new line of your logfile – and under intense load you may well
have your nginx logging completely disabled.

Your other option is to map known-bad URLs (i.e. malware and other
vulnerability scans) to a local catch-all ban script which adds a
host-ban rule to your firewall when executed. This would be the least
resource intensive option if you are already running e.g. php-fpm.

And the third option of course is to use snort with a limited ruleset
which would accomplish the same as the method above but with higher
resource usage vs. the benefit of less configuration.

Cheers
Kon