rodsec 0.0.1

Sign up to get free protection for your applications and to get access to all the features.
@@ -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: []