I have nginx setup with the following parameters in order to place entries into a different log that come from my own ISP IP. I use some iptables -string drops, all that drop correctly except for one that is listed below. They get past the iptables -string drop and are also ending up in my special log. I was wondering if someone can see anything where the nginx parameters is causing these -string DROP entries to be bypassed and placed into the wrong log.

iptables -string DROP entries:

iptables -I INPUT 1 -p tcp --dport 80 -m string --string "vtigercrm" --algo bm --to 300 -j DROP


Log entry into my 123.456.789.012 special ISP IP log:

119.81.182.22 - - [21/Jul/2015:03:51:24 -0500] "GET /vtigercrm/vtigerservice.php HTTP/1.1" 404 2096 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 lib$


My nginx parameters:

server {
listen 123.456.789.012:80; ## listen for ipv4; this line is default and implied
listen 443 ssl;

error_page 404 /404.html;
ssl_certificate /etc/nginx/keycrt/me.net.crt;
ssl_certificate_key /etc/nginx/keycrt/me.net.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+A$
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparams.pem;

root /var/www;
index index.html index.htm;

location / {
access_log /var/log/nginx/123.456.789.012.log;
}
}

server {
listen 80; ## listen for ipv4; this line is default and implied
listen [::]:80 default_server ipv6only=on; ## listen for ipv6

listen 443 ssl;
server_name www.me.net;
error_page 404 /404.html;
ssl_certificate /etc/nginx/keycrt/me.net.crt;
ssl_certificate_key /etc/nginx/keycrt/me.net.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+A$
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparams.pem;

root /var/www;
index index.html index.htm;

# Make site accessible from http://localhost/
server_name localhost;

location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ /index.html;
# Uncomment to enable naxsi on this location
# include /etc/nginx/naxsi.rules
}
{

I see a drop on port 80 but a listen on 443.
Otherwise do a traceroute to 119 to find out by which route its coming in.

---
nginx for Windows http://nginx-win.ecsds.eu/

Never thought about him coming in on 443. That is probably why iptables is missing the drop. He is getting into the special log because the port 443 is being hit through the first server 'listen 443 ssl'. I am not a complete newbie, but still learning. Thanks for the help.

There still seems to be a problem. My iptables -string DROP entry is now:

iptables -I INPUT 1 -p tcp -m multiport --dports 80,443 -m string --string "vtigercrm" --algo bm --to 300 -j DROP

Today I found this in my above example 123.456.789.012:80 log:

95.110.186.196 - - [04/Aug/2015:09:57:55 -0500] "GET /vtigercrm/test/logo/zizo.php HTTP/1.1" 404 2096 "-" "curl/7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5"

I think that this is probably something to do with the iptables parameters, but I can't see it. It only happens with the 123.456.789.012:80 server.

"Otherwise do a traceroute to find out by which route its coming in." which sounds like a route not covered by iptables.

---
nginx for Windows http://nginx-win.ecsds.eu/

I'm not real knowledgeable in this stuff. Here is a traceroute, but I can't tell anything from it. The firewall is searching for the -string vtigercrm. I thought that packets coming in with that in it would be rejected. I don't now how routing would affect that.

traceroute to 69.58.178.57 (69.58.178.57), 30 hops max, 60 byte packets
1 me.me.32.254 (me.me.32.254) 0.805 ms me.me.32.253 (me.me.32.253) 0.552 ms me.me.32.254 (me.me.32.254) 0.630 ms
2 me.me.0.241 (me.me.0.241) 0.568 ms me.me.0.233 (me.me.0.233) 0.531 ms me.me.0.229 (me.me.0.229) 0.488 ms
3 verisign.telecity4.nl-ix.net (193.239.117.25) 0.935 ms 0.883 ms 0.830 ms
4 xe-2-3-0.r2.bb-fo.lon3.vrsn.net (199.7.62.61) 6.214 ms xe-3-0-0.r1.bb-fo.lon3.vrsn.net (199.7.62.21) 7.339 ms xe-1-2-0.r2.bb-fo.lon3.vrsn.net (199.16.94.173) 7.396 ms
5 xe-5-1-0.r1.bb-fo.nyc3.vrsn.net (199.7.62.44) 81.286 ms xe-4-2-0.r2.bb-fo.nyc3.vrsn.net (199.7.62.59) 80.234 ms 80.289 ms
6 xe-0-2-0.r1.bb-fo.nyc3.vrsn.net (199.16.94.1) 80.029 ms xe-2-1-0.r2.bb-fo.ilg1.vrsn.net (199.7.62.18) 83.186 ms 199.7.62.64 (199.7.62.64) 81.419 ms
7 199.7.62.66 (199.7.62.66) 81.706 ms xe-1-2-0.r1.bb-fo.ilg1.vrsn.net (199.16.94.10) 81.402 ms po1.2010.r1.shared-fo.ilg1.vrsn.net (199.16.95.10) 103.165 ms
8 po1.2010.r1.shared-fo.ilg1.vrsn.net (199.16.95.10) 103.166 ms te1-2.r2.colo-fo.ilg1.vrsn.net (69.58.176.194) 83.119 ms 86.078 ms
9 te1-2.r1.colo-fo.ilg1.vrsn.net (69.58.176.198) 81.467 ms * *
10 * * *
...

Plenty to find,
http://ubuntuforums.org/showthread.php?t=2141628

https://www.google.nl/#q=iptables%20string%20match%20not%20working

---
nginx for Windows http://nginx-win.ecsds.eu/

Thanks. Definitely have some more studying to do.