I have installed Mod Security 3 on my Nginx server.
Up to date and seeing multiple pages on how to put an IP on the white list, I find that all docs talk to me about doing something, and that causes me a configuration error in nginx.
whitelist.conf (call on modsecurity.conf after read all rules files)
SecRule REMOTE_ADDR "#ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off
Error
root#hq:/etc/nginx/modsec/whitelist# nginx -t
nginx: [emerg] "modsecurity_rules_file" directive Rules error. File: /etc/nginx/modsec/whitelist/whitelist.conf. Line: 1. Column: 19. in /etc/nginx/conf.d/default.conf:4
Some body can help me?
main.conf
# From https://github.com/SpiderLabs/ModSecurity/blob/master/
# modsecurity.conf-recommended
#
# Edit to set SecRuleEngine On
Include "/etc/nginx/modsec/modsecurity.conf"
# Basic test rule
# SecRule ARGS:testparam "#contains test" "id:1234,deny,status:403"
# OWASP CRS v3 rules
Include /usr/local/owasp-modsecurity-crs-3.0.2/crs-setup.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-901-INITIALIZATION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-905-COMMON-EXCEPTIONS.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-910-IP-REPUTATION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-911-METHOD-ENFORCEMENT.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-912-DOS-PROTECTION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-913-SCANNER-DETECTION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-921-PROTOCOL-ATTACK.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-949-BLOCKING-EVALUATION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/RESPONSE-950-DATA-LEAKAGES.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/RESPONSE-980-CORRELATION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
# Mias
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf
# Whitelisting
Include /etc/nginx/modsec/whitelist/*.conf
Within CRS 3.x two files are provided to help you add these different rule modifications, they are: rules/REQUEST-00-LOCAL-WHITELIST.conf.example and rules/RESPONSE-99-EXCEPTIONS.conf.example. As is noted in the Installing OWASP CRS documentation, the .example extension is provided specifically so that when these files are renamed, future updates will not overwrite these files. As is listed within the Installing OWASP CRS documentation, before adding a whitelist or exception modification you should rename these files to end in the .conf exception.
https://www.modsecurity.org/CRS/Documentation/exceptions.html
Related
I'm looking to extend the mime types in my Nginx configuration.
I've learned that I could, in principle, either edit the mime.types file, or after including mime.types in the http block of the config you could follow include mime.types with a types = {...} to append more types a la this answer.
Since I'm setting up Nginx with Chef, I have a templated configuration in sites-enabled folder that's included into the Nginx config proper. I would prefer not to have to template the nginx config or mime.types file, so I'm hoping it's possible to get it in the sites-enabled config file.
In a similar spirit to the linked question above, could I include this in my sites-enabled file to get the same effect?
http {
types {
# here is additional types
}
}
My working theory is that if blocks work as described in the link above, adding such a block would not overwrite the http block in the Nginx config, but would extend it as if I had added the types directly to the http block in nginx.conf.
Is this a valid strategy? Or am I overlooking something easier?
Although not explicitly stated in the documentation, the nginx types directive appears to behave similarly to other directives with regard to inheritance.
The directive is inherited from the previous level if and only if there are no type directives defined on the current level.
The types directive may appear in the http, server or location block level.
To extend the mime types (rather than redefining them) to can add a types block with your additions in any file containing an http, server or location context.
But if you add a types block at the server or location level, you should also add another include mime.types statement at the same level, so as not to lose the system defaults.
In your sites-enabled files:
# (1)
server {
# (2)
location ... {
# (3)
}
}
If your sites-enabled file includes the server { ... } block definition, you might add a types block in position (1) which would augment the mime types already loaded by the main nginx.conf file.
However, if you added a types block in positions (2) or (3), you would also need to add an include statement to pull in the system types again:
server {
include mime.types;
types { ... }
...
}
The types directive is documented here.
I am new to Nginx but I managed to install Drupal on windows 8 machine. I just noticed that this URL(http://localhost:8080/drupal/) spits out error message 403 Forbidden. If I mutate that URL a bit by including the index(http://localhost:8080/drupal/index.php) file then it works as expected. My question is this:
How could I configure Nginx so that I wont get error message when I go to http://localhost:8080/drupal/?
Depending on your configuration, an index directive will encourage nginx to look for specific files when encountering a directory:
index index.php;
For a more specific rule, to single out that one path and map it to the controller, you could use an exact match location directive:
location = /drupal/ { rewrite ^ /drupal/index.php last; }
See this and this for more.
I spent days now in researching on how to add some headers to nginx. All I try to do is adding these lines:
location ~ ^/(assets)/ {
add_header Access-Control-Allow-Origin *;
}
What is the best way to put these lines into the nginx.conf?
Is there also a way to not overwrite the standard nginx.conf just in case beanstalk updates the settings so I wont miss it?
The default elastic beanstalk nginx.conf seems to have this line toward the end :
include /etc/nginx/conf.d/*.conf;
(Well, I can tell you that's what the file looks like for the docker solution stack versions 1.4.1 and 2.0.4, no idea if that's guaranteed across all solution stacks).
So I think one way would be to to drop a file named whatever.conf into the /etc/nginx/conf directory using the ebextensions mechanism .
I have the following Nginx configuration using regular expression server names, so I can easily add static sites without adding new configuration entries:
server {
server_name ~^(?<domain>.+)$;
root /home/static/sites/$domain;
access_log /var/log/nginx/$domain-static-access.log;
error_log /var/log/nginx/$domain-static-error.log;
}
This works fine for serving the site, and the access logs end up at e.g. /var/log/nginx/example.com-static-access.log as desired. But the error logs end up at /var/log/nginx/$domain-static-error.log. It does not interpolate the value of that regex capture.
Any idea how to fix that?
Only some nginx configuration directives support variables. Whether or not variables are supported by a particular configuration directive in a particular parameter is explicitly documented. E.g., the access_log directive description say:
The file path can contain variables (0.7.6+), but such logs have some constraints...
The error_log directive does not support variables at all, and accordingly its description doesn't say anything about variables support. Note that this is intentional: error logs are to log errors, including low-level ones like memory allocation errors, and error logging is designed to avoid operations which can fail.
In other words, error_log does not support variables and there are no plans to add such a support. Use some fixed name instead.
Well then, take a look at this. Indeed, it seems to be that error_log path won't accept variables in nginx configuration file.
Actually based on http://www.openldap.org/doc/admin24/slapdconf2.html said that i can converting slapd.conf to cn=config format.
So for this purpose i try to make slapd.conf file on server which have role provider like bellow:
database bdb
suffix dc=mydomain,dc=org
rootdn cn=admin,dc=mydomain,dc=org
directory /var/lib/ldap/db
index objectclass,entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
database config
rootpw mypassword
Then i try to convert that file using slaptest command, but i got error message like bellow :
$ slaptest -f slapd.conf -v
slapd.conf: line 2: <suffix> invalid DN 21 (Invalid syntax)
slaptest: bad configuration file
Actually my suffix is absolutely right, but why always "invalid DN"
How to solve this error ?
You probably have solved it by now, but for the benefit of the googles out there...
Your suffix is not absolutely right because it uses the domainComponent attribute "dc=" but you haven't added the schema that defines it. So until that is done the distinguished name is an unknown and "invalid DN".
Explanation: In the core.schema file (typically in /etc/openldap/schemas/, at least for RedHat/CentOS RPMs) you can find this (and much more that is needed):
# RFC 1274 + RFC 2247
attributetype ( 0.9.2342.19200300.100.1.25
NAME ( 'dc' 'domainComponent' )
DESC 'RFC1274/2247: domain component'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
What you have to do it to include this schema file to your configuration by adding this to the beginning (assuming the file is at this path, adjust as needed):
include /etc/openldap/schema/core.schema
You probably also need other schema files, but this will solve this error.
I had the same problem with too minimal of a file, I added a few extra details and it works
#slapd.conf
#schemas to use
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
#log
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
########################################
##### dbm database definitions ####
########################################
database bdb
suffix dc=server,dc=com
rootdn cn=Manager,dc=server,dc=com
rootpw secret
#database directory
directory /var/lib/ldap
#end
According to this you might only be missing the pidfile location as it changed between versions but you will eventually add the rest anyway.
well you should delete defaults files before run your test:
example on CentOS:
rm -rf /etc/openldap/slapd.d/*
and in database directory, should have a DB_CONFIG file
all archives with ldap-user-granted (chown ldap:ldap)
include this files in #schemas to use
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/dyngroup.schema