rodsec 0.0.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/.gitignore +15 -0
- data/.rspec +2 -0
- data/.rvmrc +60 -0
- data/.travis.yml +5 -0
- data/Gemfile +4 -0
- data/LICENSE.txt +21 -0
- data/README.md +147 -0
- data/Rakefile +15 -0
- data/bin/console +10 -0
- data/bin/setup +9 -0
- data/examples/body.yml +5 -0
- data/examples/modsec.ru +40 -0
- data/ext/msc_intervention/extconf.rb +8 -0
- data/ext/msc_intervention/msc_intervention.cc +48 -0
- data/lib/rodsec.rb +18 -0
- data/lib/rodsec/modsec.rb +60 -0
- data/lib/rodsec/rack.rb +152 -0
- data/lib/rodsec/read_config.rb +80 -0
- data/lib/rodsec/rule_set.rb +69 -0
- data/lib/rodsec/string_pointers.rb +10 -0
- data/lib/rodsec/transaction.rb +168 -0
- data/lib/rodsec/version.rb +3 -0
- data/lib/rodsec/wrapper.rb +136 -0
- data/rodsec.gemspec +40 -0
- data/spec/config/crs-setup.conf +787 -0
- data/spec/config/modsecurity.conf +264 -0
- metadata +156 -0
@@ -0,0 +1,264 @@
|
|
1
|
+
# -- Rule engine initialization ----------------------------------------------
|
2
|
+
|
3
|
+
# Enable ModSecurity, attaching it to every transaction. Use detection
|
4
|
+
# only to start with, because that minimises the chances of post-installation
|
5
|
+
# disruption.
|
6
|
+
#
|
7
|
+
# SecRuleEngine DetectionOnly
|
8
|
+
# For Rodsec, we want interventions, ie we want to be told when to send back
|
9
|
+
# a 403 instead of a normal response
|
10
|
+
SecRuleEngine On
|
11
|
+
|
12
|
+
# -- Request body handling ---------------------------------------------------
|
13
|
+
|
14
|
+
# Allow ModSecurity to access request bodies. If you don't, ModSecurity
|
15
|
+
# won't be able to see any POST parameters, which opens a large security
|
16
|
+
# hole for attackers to exploit.
|
17
|
+
#
|
18
|
+
SecRequestBodyAccess On
|
19
|
+
|
20
|
+
# Enable XML request body parser.
|
21
|
+
# Initiate XML Processor in case of xml content-type
|
22
|
+
#
|
23
|
+
SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" \
|
24
|
+
"id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
|
25
|
+
|
26
|
+
# Enable JSON request body parser.
|
27
|
+
# Initiate JSON Processor in case of JSON content-type; change accordingly
|
28
|
+
# if your application does not use 'application/json'
|
29
|
+
#
|
30
|
+
SecRule REQUEST_HEADERS:Content-Type "application/json" \
|
31
|
+
"id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"
|
32
|
+
|
33
|
+
# Maximum request body size we will accept for buffering. If you support
|
34
|
+
# file uploads then the value given on the first line has to be as large
|
35
|
+
# as the largest file you are willing to accept. The second value refers
|
36
|
+
# to the size of data, with files excluded. You want to keep that value as
|
37
|
+
# low as practical.
|
38
|
+
#
|
39
|
+
SecRequestBodyLimit 13107200
|
40
|
+
SecRequestBodyNoFilesLimit 131072
|
41
|
+
|
42
|
+
# What do do if the request body size is above our configured limit.
|
43
|
+
# Keep in mind that this setting will automatically be set to ProcessPartial
|
44
|
+
# when SecRuleEngine is set to DetectionOnly mode in order to minimize
|
45
|
+
# disruptions when initially deploying ModSecurity.
|
46
|
+
#
|
47
|
+
SecRequestBodyLimitAction Reject
|
48
|
+
|
49
|
+
# Verify that we've correctly processed the request body.
|
50
|
+
# As a rule of thumb, when failing to process a request body
|
51
|
+
# you should reject the request (when deployed in blocking mode)
|
52
|
+
# or log a high-severity alert (when deployed in detection-only mode).
|
53
|
+
#
|
54
|
+
SecRule REQBODY_ERROR "!@eq 0" \
|
55
|
+
"id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
|
56
|
+
|
57
|
+
# By default be strict with what we accept in the multipart/form-data
|
58
|
+
# request body. If the rule below proves to be too strict for your
|
59
|
+
# environment consider changing it to detection-only. You are encouraged
|
60
|
+
# _not_ to remove it altogether.
|
61
|
+
#
|
62
|
+
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
|
63
|
+
"id:'200003',phase:2,t:none,log,deny,status:400, \
|
64
|
+
msg:'Multipart request body failed strict validation: \
|
65
|
+
PE %{REQBODY_PROCESSOR_ERROR}, \
|
66
|
+
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
|
67
|
+
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
|
68
|
+
DB %{MULTIPART_DATA_BEFORE}, \
|
69
|
+
DA %{MULTIPART_DATA_AFTER}, \
|
70
|
+
HF %{MULTIPART_HEADER_FOLDING}, \
|
71
|
+
LF %{MULTIPART_LF_LINE}, \
|
72
|
+
SM %{MULTIPART_MISSING_SEMICOLON}, \
|
73
|
+
IQ %{MULTIPART_INVALID_QUOTING}, \
|
74
|
+
IP %{MULTIPART_INVALID_PART}, \
|
75
|
+
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
|
76
|
+
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
|
77
|
+
|
78
|
+
# Did we see anything that might be a boundary?
|
79
|
+
#
|
80
|
+
# Here is a short description about the ModSecurity Multipart parser: the
|
81
|
+
# parser returns with value 0, if all "boundary-like" line matches with
|
82
|
+
# the boundary string which given in MIME header. In any other cases it returns
|
83
|
+
# with different value, eg. 1 or 2.
|
84
|
+
#
|
85
|
+
# The RFC 1341 descript the multipart content-type and its syntax must contains
|
86
|
+
# only three mandatory lines (above the content):
|
87
|
+
# * Content-Type: multipart/mixed; boundary=BOUNDARY_STRING
|
88
|
+
# * --BOUNDARY_STRING
|
89
|
+
# * --BOUNDARY_STRING--
|
90
|
+
#
|
91
|
+
# First line indicates, that this is a multipart content, second shows that
|
92
|
+
# here starts a part of the multipart content, third shows the end of content.
|
93
|
+
#
|
94
|
+
# If there are any other lines, which starts with "--", then it should be
|
95
|
+
# another boundary id - or not.
|
96
|
+
#
|
97
|
+
# After 3.0.3, there are two kinds of types of boundary errors: strict and permissive.
|
98
|
+
#
|
99
|
+
# If multipart content contains the three necessary lines with correct order, but
|
100
|
+
# there are one or more lines with "--", then parser returns with value 2 (non-zero).
|
101
|
+
#
|
102
|
+
# If some of the necessary lines (usually the start or end) misses, or the order
|
103
|
+
# is wrong, then parser returns with value 1 (also a non-zero).
|
104
|
+
#
|
105
|
+
# You can choose, which one is what you need. The example below contains the
|
106
|
+
# 'strict' mode, which means if there are any lines with start of "--", then
|
107
|
+
# ModSecurity blocked the content. But the next, commented example contains
|
108
|
+
# the 'permissive' mode, then you check only if the necessary lines exists in
|
109
|
+
# correct order. Whit this, you can enable to upload PEM files (eg "----BEGIN.."),
|
110
|
+
# or other text files, which contains eg. HTTP headers.
|
111
|
+
#
|
112
|
+
# The difference is only the operator - in strict mode (first) the content blocked
|
113
|
+
# in case of any non-zero value. In permissive mode (second, commented) the
|
114
|
+
# content blocked only if the value is explicit 1. If it 0 or 2, the content will
|
115
|
+
# allowed.
|
116
|
+
#
|
117
|
+
|
118
|
+
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
|
119
|
+
"id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
|
120
|
+
#SecRule MULTIPART_UNMATCHED_BOUNDARY "@eq 1" \
|
121
|
+
#"id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
|
122
|
+
|
123
|
+
|
124
|
+
# PCRE Tuning
|
125
|
+
# We want to avoid a potential RegEx DoS condition
|
126
|
+
#
|
127
|
+
SecPcreMatchLimit 1000
|
128
|
+
SecPcreMatchLimitRecursion 1000
|
129
|
+
|
130
|
+
# Some internal errors will set flags in TX and we will need to look for these.
|
131
|
+
# All of these are prefixed with "MSC_". The following flags currently exist:
|
132
|
+
#
|
133
|
+
# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.
|
134
|
+
#
|
135
|
+
SecRule TX:/^MSC_/ "!@streq 0" \
|
136
|
+
"id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
|
137
|
+
|
138
|
+
|
139
|
+
# -- Response body handling --------------------------------------------------
|
140
|
+
|
141
|
+
# Allow ModSecurity to access response bodies.
|
142
|
+
# You should have this directive enabled in order to identify errors
|
143
|
+
# and data leakage issues.
|
144
|
+
#
|
145
|
+
# Do keep in mind that enabling this directive does increases both
|
146
|
+
# memory consumption and response latency.
|
147
|
+
#
|
148
|
+
SecResponseBodyAccess On
|
149
|
+
|
150
|
+
# Which response MIME types do you want to inspect? You should adjust the
|
151
|
+
# configuration below to catch documents but avoid static files
|
152
|
+
# (e.g., images and archives).
|
153
|
+
#
|
154
|
+
SecResponseBodyMimeType text/plain text/html text/xml
|
155
|
+
|
156
|
+
# Buffer response bodies of up to 512 KB in length.
|
157
|
+
SecResponseBodyLimit 524288
|
158
|
+
|
159
|
+
# What happens when we encounter a response body larger than the configured
|
160
|
+
# limit? By default, we process what we have and let the rest through.
|
161
|
+
# That's somewhat less secure, but does not break any legitimate pages.
|
162
|
+
#
|
163
|
+
SecResponseBodyLimitAction ProcessPartial
|
164
|
+
|
165
|
+
|
166
|
+
# -- Filesystem configuration ------------------------------------------------
|
167
|
+
|
168
|
+
# The location where ModSecurity stores temporary files (for example, when
|
169
|
+
# it needs to handle a file upload that is larger than the configured limit).
|
170
|
+
#
|
171
|
+
# This default setting is chosen due to all systems have /tmp available however,
|
172
|
+
# this is less than ideal. It is recommended that you specify a location that's private.
|
173
|
+
#
|
174
|
+
SecTmpDir /tmp/
|
175
|
+
|
176
|
+
# The location where ModSecurity will keep its persistent data. This default setting
|
177
|
+
# is chosen due to all systems have /tmp available however, it
|
178
|
+
# too should be updated to a place that other users can't access.
|
179
|
+
#
|
180
|
+
SecDataDir /tmp/
|
181
|
+
|
182
|
+
|
183
|
+
# -- File uploads handling configuration -------------------------------------
|
184
|
+
|
185
|
+
# The location where ModSecurity stores intercepted uploaded files. This
|
186
|
+
# location must be private to ModSecurity. You don't want other users on
|
187
|
+
# the server to access the files, do you?
|
188
|
+
#
|
189
|
+
#SecUploadDir /opt/modsecurity/var/upload/
|
190
|
+
|
191
|
+
# By default, only keep the files that were determined to be unusual
|
192
|
+
# in some way (by an external inspection script). For this to work you
|
193
|
+
# will also need at least one file inspection rule.
|
194
|
+
#
|
195
|
+
#SecUploadKeepFiles RelevantOnly
|
196
|
+
|
197
|
+
# Uploaded files are by default created with permissions that do not allow
|
198
|
+
# any other user to access them. You may need to relax that if you want to
|
199
|
+
# interface ModSecurity to an external program (e.g., an anti-virus).
|
200
|
+
#
|
201
|
+
#SecUploadFileMode 0600
|
202
|
+
|
203
|
+
|
204
|
+
# -- Debug log configuration -------------------------------------------------
|
205
|
+
|
206
|
+
# The default debug log configuration is to duplicate the error, warning
|
207
|
+
# and notice messages from the error log.
|
208
|
+
#
|
209
|
+
#SecDebugLog /opt/modsecurity/var/log/debug.log
|
210
|
+
#SecDebugLogLevel 3
|
211
|
+
|
212
|
+
|
213
|
+
# -- Audit log configuration -------------------------------------------------
|
214
|
+
|
215
|
+
# Log the transactions that are marked by a rule, as well as those that
|
216
|
+
# trigger a server error (determined by a 5xx or 4xx, excluding 404,
|
217
|
+
# level response status codes).
|
218
|
+
#
|
219
|
+
SecAuditEngine RelevantOnly
|
220
|
+
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
|
221
|
+
|
222
|
+
# Log everything we know about a transaction.
|
223
|
+
SecAuditLogParts ABIJDEFHZ
|
224
|
+
|
225
|
+
# Use a single file for logging. This is much easier to look at, but
|
226
|
+
# assumes that you will use the audit log only ocassionally.
|
227
|
+
#
|
228
|
+
SecAuditLogType Serial
|
229
|
+
# SecAuditLog /var/log/modsec_audit.log
|
230
|
+
# For Rodsec, just be quiet, dammit. Maybe there's a better way to turn this off.
|
231
|
+
# But I haven't found it.
|
232
|
+
SecAuditLog /dev/null
|
233
|
+
|
234
|
+
# Specify the path for concurrent audit logging.
|
235
|
+
#SecAuditLogStorageDir /opt/modsecurity/var/audit/
|
236
|
+
|
237
|
+
|
238
|
+
# -- Miscellaneous -----------------------------------------------------------
|
239
|
+
|
240
|
+
# Use the most commonly used application/x-www-form-urlencoded parameter
|
241
|
+
# separator. There's probably only one application somewhere that uses
|
242
|
+
# something else so don't expect to change this value.
|
243
|
+
#
|
244
|
+
SecArgumentSeparator &
|
245
|
+
|
246
|
+
# Settle on version 0 (zero) cookies, as that is what most applications
|
247
|
+
# use. Using an incorrect cookie version may open your installation to
|
248
|
+
# evasion attacks (against the rules that examine named cookies).
|
249
|
+
#
|
250
|
+
SecCookieFormat 0
|
251
|
+
|
252
|
+
# Specify your Unicode Code Point.
|
253
|
+
# This mapping is used by the t:urlDecodeUni transformation function
|
254
|
+
# to properly map encoded data to your language. Properly setting
|
255
|
+
# these directives helps to reduce false positives and negatives.
|
256
|
+
#
|
257
|
+
SecUnicodeMapFile unicode.mapping 20127
|
258
|
+
|
259
|
+
# Improve the quality of ModSecurity by sharing information about your
|
260
|
+
# current ModSecurity version and dependencies versions.
|
261
|
+
# The following information will be shared: ModSecurity version,
|
262
|
+
# Web Server version, APR version, PCRE version, Lua version, Libxml2
|
263
|
+
# version, Anonymous unique id for host.
|
264
|
+
SecStatusEngine Off
|
metadata
ADDED
@@ -0,0 +1,156 @@
|
|
1
|
+
--- !ruby/object:Gem::Specification
|
2
|
+
name: rodsec
|
3
|
+
version: !ruby/object:Gem::Version
|
4
|
+
version: 0.0.1
|
5
|
+
platform: ruby
|
6
|
+
authors:
|
7
|
+
- John Anderson
|
8
|
+
autorequire:
|
9
|
+
bindir: exe
|
10
|
+
cert_chain: []
|
11
|
+
date: 2018-09-25 00:00:00.000000000 Z
|
12
|
+
dependencies:
|
13
|
+
- !ruby/object:Gem::Dependency
|
14
|
+
name: bundler
|
15
|
+
requirement: !ruby/object:Gem::Requirement
|
16
|
+
requirements:
|
17
|
+
- - "~>"
|
18
|
+
- !ruby/object:Gem::Version
|
19
|
+
version: '1.15'
|
20
|
+
type: :development
|
21
|
+
prerelease: false
|
22
|
+
version_requirements: !ruby/object:Gem::Requirement
|
23
|
+
requirements:
|
24
|
+
- - "~>"
|
25
|
+
- !ruby/object:Gem::Version
|
26
|
+
version: '1.15'
|
27
|
+
- !ruby/object:Gem::Dependency
|
28
|
+
name: rake
|
29
|
+
requirement: !ruby/object:Gem::Requirement
|
30
|
+
requirements:
|
31
|
+
- - "~>"
|
32
|
+
- !ruby/object:Gem::Version
|
33
|
+
version: '10.0'
|
34
|
+
type: :development
|
35
|
+
prerelease: false
|
36
|
+
version_requirements: !ruby/object:Gem::Requirement
|
37
|
+
requirements:
|
38
|
+
- - "~>"
|
39
|
+
- !ruby/object:Gem::Version
|
40
|
+
version: '10.0'
|
41
|
+
- !ruby/object:Gem::Dependency
|
42
|
+
name: rspec
|
43
|
+
requirement: !ruby/object:Gem::Requirement
|
44
|
+
requirements:
|
45
|
+
- - "~>"
|
46
|
+
- !ruby/object:Gem::Version
|
47
|
+
version: '3.0'
|
48
|
+
type: :development
|
49
|
+
prerelease: false
|
50
|
+
version_requirements: !ruby/object:Gem::Requirement
|
51
|
+
requirements:
|
52
|
+
- - "~>"
|
53
|
+
- !ruby/object:Gem::Version
|
54
|
+
version: '3.0'
|
55
|
+
- !ruby/object:Gem::Dependency
|
56
|
+
name: pry
|
57
|
+
requirement: !ruby/object:Gem::Requirement
|
58
|
+
requirements:
|
59
|
+
- - ">="
|
60
|
+
- !ruby/object:Gem::Version
|
61
|
+
version: '0'
|
62
|
+
type: :development
|
63
|
+
prerelease: false
|
64
|
+
version_requirements: !ruby/object:Gem::Requirement
|
65
|
+
requirements:
|
66
|
+
- - ">="
|
67
|
+
- !ruby/object:Gem::Version
|
68
|
+
version: '0'
|
69
|
+
- !ruby/object:Gem::Dependency
|
70
|
+
name: rack
|
71
|
+
requirement: !ruby/object:Gem::Requirement
|
72
|
+
requirements:
|
73
|
+
- - "~>"
|
74
|
+
- !ruby/object:Gem::Version
|
75
|
+
version: '2'
|
76
|
+
type: :development
|
77
|
+
prerelease: false
|
78
|
+
version_requirements: !ruby/object:Gem::Requirement
|
79
|
+
requirements:
|
80
|
+
- - "~>"
|
81
|
+
- !ruby/object:Gem::Version
|
82
|
+
version: '2'
|
83
|
+
- !ruby/object:Gem::Dependency
|
84
|
+
name: rake-compiler
|
85
|
+
requirement: !ruby/object:Gem::Requirement
|
86
|
+
requirements:
|
87
|
+
- - ">="
|
88
|
+
- !ruby/object:Gem::Version
|
89
|
+
version: 1.0.5
|
90
|
+
type: :development
|
91
|
+
prerelease: false
|
92
|
+
version_requirements: !ruby/object:Gem::Requirement
|
93
|
+
requirements:
|
94
|
+
- - ">="
|
95
|
+
- !ruby/object:Gem::Version
|
96
|
+
version: 1.0.5
|
97
|
+
description: A ruby ffi wrapper for ModSecurity that also provides a Rack middleware
|
98
|
+
email:
|
99
|
+
- panic@semiosix.com
|
100
|
+
executables: []
|
101
|
+
extensions:
|
102
|
+
- ext/msc_intervention/extconf.rb
|
103
|
+
extra_rdoc_files: []
|
104
|
+
files:
|
105
|
+
- ".gitignore"
|
106
|
+
- ".rspec"
|
107
|
+
- ".rvmrc"
|
108
|
+
- ".travis.yml"
|
109
|
+
- Gemfile
|
110
|
+
- LICENSE.txt
|
111
|
+
- README.md
|
112
|
+
- Rakefile
|
113
|
+
- bin/console
|
114
|
+
- bin/setup
|
115
|
+
- examples/body.yml
|
116
|
+
- examples/modsec.ru
|
117
|
+
- ext/msc_intervention/extconf.rb
|
118
|
+
- ext/msc_intervention/msc_intervention.cc
|
119
|
+
- lib/rodsec.rb
|
120
|
+
- lib/rodsec/modsec.rb
|
121
|
+
- lib/rodsec/rack.rb
|
122
|
+
- lib/rodsec/read_config.rb
|
123
|
+
- lib/rodsec/rule_set.rb
|
124
|
+
- lib/rodsec/string_pointers.rb
|
125
|
+
- lib/rodsec/transaction.rb
|
126
|
+
- lib/rodsec/version.rb
|
127
|
+
- lib/rodsec/wrapper.rb
|
128
|
+
- rodsec.gemspec
|
129
|
+
- spec/config/crs-setup.conf
|
130
|
+
- spec/config/modsecurity.conf
|
131
|
+
homepage: http://github.com/djellemah/rodsec
|
132
|
+
licenses:
|
133
|
+
- MIT
|
134
|
+
metadata:
|
135
|
+
allowed_push_host: https://rubygems.org
|
136
|
+
post_install_message:
|
137
|
+
rdoc_options: []
|
138
|
+
require_paths:
|
139
|
+
- lib
|
140
|
+
required_ruby_version: !ruby/object:Gem::Requirement
|
141
|
+
requirements:
|
142
|
+
- - ">="
|
143
|
+
- !ruby/object:Gem::Version
|
144
|
+
version: '0'
|
145
|
+
required_rubygems_version: !ruby/object:Gem::Requirement
|
146
|
+
requirements:
|
147
|
+
- - ">="
|
148
|
+
- !ruby/object:Gem::Version
|
149
|
+
version: '0'
|
150
|
+
requirements: []
|
151
|
+
rubyforge_project:
|
152
|
+
rubygems_version: 2.6.14
|
153
|
+
signing_key:
|
154
|
+
specification_version: 4
|
155
|
+
summary: Wrapper for ModSecurity with Rack middleware
|
156
|
+
test_files: []
|