The mod_security configuration file is fairly easy to understand, thanks to the good work done by the development team, who left comments explaining each important part of the file.
Below is a table with the necessary permissions for each directory, if you want to use the default /opt, which is used within the modsecurity.conf or create in a location of your choice.
/opt/modsecurity root apache rwxr-x---
/opt/modsecurity/bin root apache rwxr-x---
/opt/modsecurity/etc root root rwx------
/opt/modsecurity/var root apache rwxr-x---
/opt/modsecurity/var/audit apache root rwx------
/opt/modsecurity/var/data apache root rwx------
/opt/modsecurity/var/log root root rwx------
/opt/modsecurity/var/tmp apache apache rwxr-x---
/opt/modsecurity/var/upload apache root rwx------
We can centralize our settings in modsecurity.conf or organize into separate files of According to our rules.
If the choice is the default, which is the only modsecurity.conf, we can insert the following lines into the httpd.conf
<IfModule security2_module>
Include conf.d/modsecurity.conf
</IfModule>
And if the choice is to separate the files by suggestive names or remember the rules, the example below should be followed.
** IMPORTANT TO REMEMBER THAT THE FILES ARE READ IN ORDER UP DOWN. **
<IfModule mod_security2.c>
Include /opt/modsecurity/etc/modsecurity.conf
Include /opt/modsecurity/etc/owasp_top10.conf
Include /opt/modsecurity/etc/geoip.conf
Include /opt/modsecurity/etc/myrules.conf
</IfModule>
**IMPORTANT SAY THAT IS JUST AN EXAMPLE, YOU SHOULD USE YOUR WAY WHERE IS YOUR RULES **
In this moment we first make use of the default configuration of mod_security, it's just using a configuration file.
Modsecurity.conf The file is separated into eight parts.
Rule engine initialization
Request body handling
Response body handling
Filesystem configuration
File uploads handling configuration
Debug log configuration
Audit log configuration
Miscellaneous
Rule engine initialization
This part is where we find the SecRuleEngine, is where we tell the mod_security what he should do if block or just log
This policy is sensitive, and it can tell mod_security, for example, to monitor a specific VirtualHost it and can also set different rules for each
SecRuleEngine, The directive accepts as a parameter:
On | Off | DetectionOnly
On - Processes the rules
Off - Not processes rules
DetectionOnly - Processes the rules, but does not perform the actions
Request body handling
This part we find some policies as SecRequestBodyAccess, SecRequestBodyLimit, SecRequestBodyNoFilesLimit, SecRequestBodyInMemoryLimit and SecRequestBodyLimitAction
SecRequestBodyAccess The directive, which tells mod_security if he can do the checking of requests from the body of the page.
When we enable this policy, it makes a complete buffer of the content of the requests, this buffer is used so that the rules of mod_security can make the reading of these data and decide whether or not to release . Here we find a problem, because mod_security usually use the RAM to make this buffer, which can degrade server performance, especially if we are sharing the mod_security and the web server on the same server.
SecRequestBodyAccess, The directive accepts as parameter:
On | Off
On - Does the buffer of requests
Off - Does not buffer the requests
We may use SecRequestBodyLimit, SecRequestBodyNoFilesLimit, SecRequestBodyInMemoryLimit to the way we configure this buffer is done.
SecRequestBodyLimit, sets a maximum size for the buffer and accepts as a parameter:
** This directive only works in the main configuration file, or to a VirtualHost
LIMIT_IN_BYTES
Whenever this limit is exceeded, the server had used the HTTP 413 code*
The SecRequestBodyNoFilesLimit directive also defines a size for the buffer, but it excludes the size of the files that were transported in requests.
This directive is useful for preventing denial of service (DoS) attacks because it prevents an attacker can make sending requests with a very large size. Cases the server will accept upload files, this directive must be set to a high value, so as not to undermine this functionality.
This directive accepts as a parameter:
NUMBER_IN_BYTES
Whenever this limit is exceeded, the server had used the HTTP 413 code *
The SecRequestBodyInMemoryLimit directive configures the maximum size that the request will be able to store in memory RAM, but when a request multipart/form-data exceeds this limit, the mod_security creates a temporary file on disk and it starts to be used.
The SecRequestBodyInMemoryLimit directive accepts the parameter
LIMIT_IN_BYTES
The SecRequestBodyLimitAction, which tells mod_security what to do when a request exceeds the configured settings in SecRequestBodyLimit policy. By default mod_security rejects requests larger than the set.
By default mod_security rejects requests larger than the set. This policy becomes a problem when we want to use mod_security in DetectionOnly way because she rejects or makes a partial rendering, which would be only the first part of the request.
SecRequestBodyLimitAction, The directive accepts as parameters:
Reject | ProcessPartial
Reject - It is the standard and rejects everything that exceeds the set limit.
ProcessPartial - Renders only the first part of the requests
Response body handling
Here we find directives as SecResponseBodyAccess, SecResponseBodyMimeType, SecResponseBodyLimit, SecResponseBodyLimitAction and they are very similar to the ones seen above.
SecResponseBodyAccess The directive allows the mod_security access the answers of the requests made. This policy helps terms control over data leaving these requests, thus preventing any sensitive data, get out of our environment.
**important to say that enabling this policy, we increase the consumption of very memory of our server, then it is good and assess the real need we use.
This directive accepts as a parameter:
Off | On
On - Does buffer the answers
Off - Does not buffer the responses
The SecResponseBodyMimeType directive, allows us to choose the type of MIME**, which will inspect file.
It accepts as a parameter:
** We can spend more than one type
MIMETYPE MIMETYPE
TheSecResponseBodyLimit directive, allows you to set the maximum size of the response buffer. Anything above that limit, you will get as the HTTP response code 500*.
** This setting only has an impact on MIME files that are cited in the previous policy
LIMIT_IN_BYTES
The SecResponseBodyLimitAction directive allows us to configure an action, if we have several web sites, behind the mod_security and some of these sites will have a larger than the size configured in the previous policy. This policy allows us to configure mod_security to read only the first part of the answer, the part that can fit in the limit we set in the previous policy.
The directive accepts as a parameter:
Reject | ProcessPartial
Reject - Rejects all exceed the value
ProcessPartial - Processes only the first part
Filesystem configuration
In this block we have the SecTmpDir and SecDataDir, which is where we set the directories for temporary files and persistent policy files.
The policy SecTmpDir, is where mod_security will save by default the temporary files to /tmp folder, comes configured if you want to change the folder, it is important to say that the folder to be set must be configured with write permission for the apache user. This is also the place you will use mod_security to the buffer if the memory runs out.
It accepts as a parameter:
Directory_path
The SecDataDir policy, is where mod_security, will record the persistent data, such as IP access or sessions.
It accepts as a parameter:
Directory_path
File uploads configuration handling
In this block we will find policies, SecUploadDir, SecUploadKeepFiles and SecUploadFileMode. And that's where the setting is made of where the mod_security will store files that are intercepted during upload.
The SecUploadDir policy will define where mod_security will store the intercepted files. Interestingly, this directory has access permission only for mod_security.
It accepts as a parameter:
Directory_path
The SecUploadKeepFiles directive, allows us to define, if we keep the file that has been processed or not. For this policy to work, we need the SecUploadDir policy, is configured.
It accepts as a parameter:
On | Off | RelevantOnly
On - Keeps all files
Off - Do not keep the files
RelevantOnly - Ira keeping only the relevant files considered
The SecUploadFileMode directive allows us to change the permissions of files that are sent to our server, because these files are have the octal 0600 permissions by default. If we want a third party to have access to these files, such as a virus, we need to change that policy.
It accepts as a parameter:
OCTAL_MODE
Debug log configuration
This block we set the Debug Log, which are very useful in order to solve a problem or understand. SecDebugLog Here we have the policies and SecDebugLogLevel
The SecDebugLog policy, is where we will define the way that we store these debug log.
It accepts as a parameter:
Directory_path
The SecDebugLogLevel policy, is where we will set the level of information that we have in our debug log. . For a production server, the recommendation is to leave in 3 to avoid the performance penalty and increased consumption of disk
It accepts as a parameter:
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
0 - Do not log the records
1 - Only errors (only the requests)
2 - Important
3 - Information
From 1-3, mod_security generates only one copy of the apache error logs.
4 - Details of transactions
5 - As the fourth , but with information from every part of the transaction
9 - It will generate all and in great detail logtuning..
is interesting we use 9 when our server this way on approval, so we can do some fine
Audit log configuration
In this part we will find policies that are responsible for making the analysis of our logs. The mod_security uses the term "audit logging", to refer to the transaction logs that are stored on our server. This are the logs that are marked by some rule or a request that has as an HTTP 500 response code
Here we have the following policies, SecAuditEngine, SecAuditLogRelevantStatus, SecAuditLogParts, SecAuditLogType, SecAuditLog and SecAuditLogStorageDir.
The SecAuditEngine policy, is responsible for the audit engine, which records the transactions that are completed. The mod_security can not record all transactions of errors, eg errors 400 and 404, which use different ways and that the mod_security does not support.
On | Off | RelevantOnly
On - Logall transactions
Off - Will not register anything
RelevantOnly - Will register only those transactions that are registered with warning, error or the HTTP code relevant, we can configure the SecAuditLogRelevantStatus policy.
ex. SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus The directive, which is can configure the HTTP response code, which we consider relevant for auditing purpose. . This directive is used only if the previous policy, SecAuditEngine, is set to RelevantOnly
It accepts as parameters:
REGEX
ex. SecAuditLogRelevantStatus "^ (5 ?:? | 4 (04))"
The SecAuditLogParts policy, is responsible for defining which part of the transaction policy will be recorded for audit. Each part of the transaction has an assigned letter, which are: A B C D E F G H I J K Z.
It accepts as a parameter
PARTLETTERS
A - Audit log header .
B - Request headers.
C - Request body (present only if the request body exists and ModSecurity is configured to intercept it).
D - Reserved for intermediary response headers; not implemented yet.
E - Intermediary response body (present only if ModSecurity is configured to intercept response bodies, and if the audit log engine is configured to record it).
F - Final response headers (excluding the Date and Server headers, which are always added by Apache in the late stage of content delivery).
G - Reserved for the actual response body; not implemented yet.
H - Audit log trailer.
I - This part is a replacement for part C. It will log the same data as C in all cases except when multipart/form-data encoding in used. In this case, it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not about the files. This is handy if you don’t want to have (often large) files stored in your audit logs.
J - This part contains information about the files uploaded using multipart/form-data encoding.
K - This part contains a full list of every rule that matched (one per line) in the order they were matched. The rules are fully qualified and will thus show inherited actions and default operators.
Z - Final boundary, signifies the end of the entry .
ex. SecAuditLogParts ABCFHZ
SecAuditLogType The policy, this policy define the type of audit logging mechanism that will be used.
It accepts as vestments:
Serial | Concurrent
Serial - Records are made in a single file, which was specified in SecAuditLog.Para casual use, this is the most suitable, however, can leave the server a bit slow since it can write to the file at any time
Concurrent - Is a report of a file for each transaction. Is recommended for cases where you have multiple transactions at the same time, these transactions will be recorded in parallel.
ie. SecAuditLogType Serial
The SecAuditLog directive, this directive sets the path where the file will be stored audit logging.
It accepts as a parameter:
Directory_path
ie. /var/log/mod_security/audit.log
The SecAuditLogStorageDir policy, this policy will be used only if the SecAuditLogType the configuration is set to Concurrent therefore here we set the path for storing the inputs generated by this configuration.
It accepts as a parameter:
Directory_path
ie. /var/log/mod_security/audit/
Miscellaneous
This part of the configuration file, is unlikely to have an impact on the above settings, but we will address them as part of the settings.
Here we find the SecArgumentSeparator, SecCookieFormat, SecUnicodeMapFile SecStatusEngine and policies, but we will speak only of two.
The SecCookieFormat directive, this directive sets the cookie format that will be used in a configuration context.
It accepts as vestments:
0 | 1
0 (Netscape) - Standard Version and more used. It is the default value
1 - Version 1 cookies
SecStatusEngine The directive, this directive, if enabled, will allow mod_security send some information to the development team SpiderLabs-.
The information sent is the versions of the following items:
Mod_Sec
- Web Server
- APR
- libxml2
- Moon
- PCRE
* For more information about this code, I recommend reading RFC 2616 // http://tools.ietf.org/html/rfc2616
* I recommend reading the book HTTP: The Definitive Guide // http: //www.amazon .com / HTTP-The-Definitive-Guide-Guides / dp / 1565925092
** In this link we can find different types MIMETYPE, http://www.iana.org/assignments/media-types/media-types.xhtml
Nenhum comentário:
Postar um comentário