Computer Internet network security News

The new version of apache 2.5.9 have facility of disabling the modsecurity web applicationfirewall. The new version is available on internet. This will help in avoiding crashing the firewall while processing http packets.

It also fixes a potential Dos vulnerability in which pdf documents request shows. Apache administrators who use ModSecurity are advised to update to version 2.5.9 as soon as possible.

ModSecurity, Server security apache 2.5.9, Computer firewall

The filter inheritance scheme in ModSecurity follows the rules outlined below.

• By default, all filters, together with their per-rule action lists, are inherited by child contexts.
• The default action list is also inherited by child contexts.
• Action lists, defined in the SecFilterSignatureAction directive (per-ruleset actions), are never inherited by child contexts.

It is possible to customize this scheme by using one or more of the directives SecFilterInheritance, SecFilterInheritanceMandatory, SecFilterImport, SecFilterRemove or by setting the per-rule action “mandatory” on a specific filter or filter chain.

SecFilterInheritance
Controls the inheritance of rules from the parent context. By default, its value is On. By setting it to Off in a context, eg virtualhost, none of the filters defined in parent contexts is inherited. This directive needs to be explicitly set in every context in which you do not want to inherit any rules. For example:

<Directory /path/to/some/dir>
    SecFilterInheritance Off
</Directory>

SecFilterImport

This directive works in conjuction with SecFilterInheritance and has a meaning only if the latter has been set to Off
in a particular context. It accepts a space-delimited list of rule IDs
and can be used to explicitly import filters from parent contexts.

 For example:

<Directory /path/to/some/dir>
    SecFilterInheritance Off
    SecFilterImport 1001 1002 1003
</Directory>

SecFilterRemove

This directive is the exact opposite of SecFilterImport. It has a meaning only if SecFilterInheritance
has not been disabled in a particular context and works only for
filters that have not been marked for mandatory inheritance (see
below). It accepts a space-delimited list of rule IDs and can be used
to explicitly disable inherited filters. For example:

<Directory /path/to/some/dir>
    SecFilterRemove 10 11 12
</Directory>

SecFilterInheritanceMandatory

Controls the inheritance of rules for the child contexts. By default, its value is Off. By setting it to On
in a context, eg virtualhost, all of the filters defined in this
particular context will be inherited by force by child contexts,
despite the fact that filter inheritance might be disabled in those
child contexts. This directive needs to be explicitly set in every
context whose filters need to be always in-effect in subcontexts.

For example:

 <Virtualhost 192.168.0.1:80>
	SecFilterInheritanceMandatory On
	SecFilter ".*admin.*" "id:10"
	<Directory /path/to/some/dir/in/this/vhost>
		SecFilterRemove 10
	</Directory>
</Virtualhost>

ModSecurity ModSecurity, modsecurity-filter

Modsecurity supports writing filters in the ways outlined below. For further information refer to the documentation.

Simple Input Filter Syntax:

• SecFilter KEYWORD [ACTIONS]
  SecFilter !KEYWORD [ACTIONS]

Advanced Input Filter Syntax:

SecFilterSelective LOCATION KEYWORD [ACTIONS]
SecFilterSelective LOCATION !KEYWORD [ACTIONS]

Advanced output Filter Syntax:

SecFilterSelective OUTPUT KEYWORD [ACTIONS]
SecFilterSelective OUTPUT !KEYWORD [ACTIONS]

ModSecurity ModSecurity, sytax

It is possible to use Apache’s custom logging feature in order to log requests, which matched a ModSecurity filter, on a per-virtualhost basis. The key for this to work is the fact that ModSecurity defines the environment variable mod_security-relevant whenever a rule is matched.

So, by adding the following statement in the virtualhost context, Apache will record information about ModSecurity’s activity for the specific virtualhost.

This statement is original from source

<IfModule mod_security.c>
    CustomLog /path/to/logs/modsec_custom_log \
        "%h %l %u %t \"%r\" %>s %b %{mod_security-message}i" \
        env=mod_security-relevant
</IfModule>

ModSecurity apache, ModSecurity, virtualhost

ModSecurity installation consists of the following steps:

1. ModSecurity 2.x works with Apache 2.0.x or better.
2. Make sure you have mod_unique_id installed.
3. (Optional) Install the latest version of libxml2, if it isn’t already installed on the server.
4. Unpack the ModSecurity archive
5. Edit Makefile to configure the path to the Apache ServerRoot directory. You can check this by identifying the ServerRoot directive setting in your httpd.conf file. This is the path that was specified with the “–install-path=” configuration flag during compilation (for example, in Fedora Core4: top_dir = /etc/httpd).
6. (Optional) Edit Makefile to enable ModSecurity to use libxml2 (uncomment line DEFS = -DWITH_LIBXML2) and configure the include path (for example: INCLUDES=-I/usr/include/libxml2)
7. Compile with make
8. Stop Apache
9. Install with make install
10. (Optional) Add one line to your configuration to load libxml2: LoadFile /usr/lib/libxml2.so
11. Add one line to your configuration to load ModSecurity: LoadModule security2_module modules/mod_security2.so
12. Configure ModSecurity
13. Start Apache
14. You now have ModSecurity 2.x up and running.

For any kind of mod security details you can refer to

http://www.modsecurity.org/

ModSecurity Data Security, installation-modsecurity, installing-modsecurity, mod-security, ModSecurity

need basically 2 things:

• The source for mod_security
• A basic set of rules, which will be packaged in the RPM

Once you have these files, you’ll just need to unpack the tarball:

[gallegosja@gallegosja gallegosja]$ tar -xvzf mod_security-1.8.4.tar.gz

go to the apache 2 module (you can enter the apache1 directory for the module for apache 1.x too) inside the recently unpacked directory and run apxs (you will need root permissions to do this):

[gallegosja@gallegosja gallegosja]$ cd mod_security-1.8.4/apache2/
[gallegosja@gallegosja apache2]$ sudo /usr/sbin/apxs -cia mod_security.c
/bin/sh /usr/lib/apr/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -g -pipe -march=i386 -mcpu=i686 -DAP_HAVE_DESIGNATED_INITIALIZER -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -pthread -I/usr/include/apr-0 -I/usr/include/httpd  -c -o mod_security.lo mod_security.c && touch mod_security.slo
/bin/sh /usr/lib/apr/build/libtool --silent --mode=link gcc -o mod_security.la -rpath /usr/lib/httpd/modules -module -avoid-version    mod_security.lo
/usr/lib/httpd/build/instdso.sh SH_LIBTOOL='/bin/sh /usr/lib/apr/build/libtool' mod_security.la /usr/lib/httpd/modules
/bin/sh /usr/lib/apr/build/libtool --mode=install cp mod_security.la /usr/lib/httpd/modules/
cp .libs/mod_security.so /usr/lib/httpd/modules/mod_security.so
cp .libs/mod_security.lai /usr/lib/httpd/modules/mod_security.la
cp .libs/mod_security.a /usr/lib/httpd/modules/mod_security.a
ranlib /usr/lib/httpd/modules/mod_security.a
chmod 644 /usr/lib/httpd/modules/mod_security.a
PATH="$PATH:/sbin" ldconfig -n /usr/lib/httpd/modules
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/lib/httpd/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 755 /usr/lib/httpd/modules/mod_security.so
[activating module `security' in /etc/httpd/conf/httpd.conf]
[gallegosja@gallegosja apache2]$

Restart your apache web server…

[gallegosja@gallegosja apache2]$ sudo /sbin/service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]
[gallegosja@gallegosja apache2]$

This just restarted your apache server, and placed a file in /etc/httpd/conf.d/mod_security.conf with a set of general rules… very general rules. You will need to change several of these rules and activate/deactivate some of them, you might find this conf file a little bit more useful

Where?

The mod_security.conf file is located in the conf.d directory of the apache configuration directory, and the logs (if you downloaded the .conf file provided above) in /var/log/httpd/audit_log, otherwise you can define in the .conf file where to dump the logs

The configuration file contains a very basic set of rules and although they’re quite useful for a simple site, more complex rules might be in order for your site’s specific needs. If you need more information on how you can create new rules or modify existing rules, read the documentation in the /usr/share/doc/mod_security-1.8.4 directory or read it online at the project’s home page.

ModSecurity ModSecurity

When ModSecurity receives request or response information, it makes a copy of this data and places it into memory. It is on this data in memory that transformation functions are applied. The raw request/response data is never altered. Transformation functions are used to transform a variable before testing it in a rule.

Note

The default transformation function setting is – lowercase, replaceNulls and compressWhitespace (in this order).

The following rule will ensure that an attacker does not use mixed case in order to evade the ModSecurity rule:

SecRule ARG:p "xp_cmdshell" "t:lowercase"

multiple tranformation actions can be used in the same rule, for example the following rule also ensures that an attacker does not use URL encoding (%xx encoding) for evasion. Note the order of the transformation functions, which ensures that a URL encoded letter is first decoded and than translated to lower case.

SecRule ARG:p "xp_cmdshell" "t:urlDecode,t:lowercase"

One can use the SetDefaultAction command to ensure the translation occurs for every rule until the next. Note that translation actions are additive, so if a rule explicitly list actions, the translation actions set by SetDefaultAction are still performed.

SecDefaultAction t:urlDecode,t:lowercase

The following transformation functions are supported:

ModSecurity ModSecurity

ModSecurity installation consists of the following steps:

ModSecurity ModSecurity

Ajax security is a major issue for next generation Web applications. The techniques discussed in
this article can give a head start to security professionals to improve the security posture of Web
applications. Web 2.0 applications try to integrate various sources, including untrusted
information sources, at one place. This trait of Web 2.0 applications adds new attack vectors to
the landscape. The advantage of Ajax fingerprinting with XHR is twofold: one, it gives a clear idea
about the origin of a request and, two, it makes it harder for automated attacks and crawler
modules to launch discovery techniques. With Web application firewalls becoming an important
part of Web application defense, one can leverage this mechanism to defend the web

ModSecurity ModSecurity

ModSecurity can also act immediately to prevent attacks from reaching your web applications. There are three commonly used approaches:

1. Negative security model. Negative security model monitors requests for anomalies, unusual behaviour, and common web application attacks. It keeps anomaly scores for each request, IP addresses, application sessions, and user accounts. Requests with high anomaly scores are either logged or rejected altogether.
2. Positive security model. When positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This approach works best with applications that are heavily used but rarely updated.
3. Known weaknesses and vulnerabilities. Its rule language makes ModSecurity an ideal external patching tool. External patching is all about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organisations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is produced.

ModSecurity ModSecurity

While not perfect, Mod Security does offer some form of protection that as they say, is better than nothing. While there will certainly be a small level of performance hit, in the four odd weeks that I’ve been using it, I have not really noticed any significant performance degradation.

On a side note with regards to the audit_log file, do note that setting the SecAuditEngine to On instead of RelevantOnly can result in a very HUGE log clogging up your system especially for high traffic sites. With the parser in place, I had over a million records in the database in less than 2 weeks (and we all know MySQL really starts to drag at this point without some serious SQL optimization). You have been warned.

ModSecurity ModSecurity

Whenever a filter catches a request, then an action, or better, a list of actions is performed. The general syntax for action lists is (no spaces are allowed between actions):

"primary_action,secondary_actions,flow_action or parameter:value action"

For example:

SecFilterDefaultAction "deny,log,status:406"

Action lists can be defined in three places:

1. SecFilterDefaultAction directive: Whenever a user-defined rule, which follows this directive, is matched, then these default actions are performed, unless they are overridden by a per-ruleset or per-rule action list (see below).
2. SecFilterSignatureAction directive: This directive may appear several times in the configuration and is used in order to specify a per-ruleset action list. A ruleset consists of all the rules that immediately follow the SecFilterSignatureAction directive. Action lists that are defined in this directive are merged with the default action list. Note that this merging procedure may result in action overriding. It depends on the type of the actions used. See the documentation for more information on this. Also, note that this action list will not be inherited by child contexts.
3. SecFilter and SecFilterSelective directives: These directives accept an optional action list to be performed whenever the rule is matched. These are per-rule actions. Actions defined in these directives are merged with the actions that are defined in the other two directives above. Note that this merging procedure may result in action overriding. It depends on the type of the actions used. See the documentation for more information on this.

Another action-related directive is SecFilterActionsRestricted. When it is set to On, all the per-rule actions, except for the metadata actions (id, msg, rev, severity), are ignored. This is particularly useful when importing 3rd party rules, which also contain per-rule action lists, but you want to define your own action-list to be performed when any of these rules is matched.

In short, the most commonly used actions and what they actually do on a filter match are outlined below:

pass

Do nothing and continue on with the next rule. Useful when running ModSecurity in detect-mode.

allow

Allow the request, but do not continue the request or server-response analysis.

deny

Deny the request and return the error document which corresponds to the defined status code (see below).

log

Log to the Apache error log and to the adit log if the audit engine is enabled.

nolog

Log nothing to the Apache error log or to the audit log.

status

(status:CODE): Specifies the HTTP error code that will be returned if the request is rejected.

redirect

(redirect:URL): Redirect to specified page. Always overrides the status and deny actions.

exec

(exec:/path/to/script): Execute the specified script. This action is always performed in addition to the primary action (if one is defined). The script must write its output to stdout.

Also, a flow action, which affects the order in which the rules are processed, may be defined:

skipnext

(skipnext:N): Skips next N rules on filter match.

chain

Combine two or more filters together. The last filter is the one that will affect the request, but in order to reach the last filter, all previous chained filters must be matched.

One of the most useful features of ModSecurity is that metadata (rule id, revision number, a text message, severity information) may be defined for each filter. This metadata is defined as parameter:value, where action can be one of id, rev, msg, severity. For example:

SecFilter ".*admin.*" id:3,severity:1

Finally, a filter or a chain of filters can be explicitly marked for inheritance in child contexts with the mandatory action. For example:

SecFilter ".*admin.*" mandatory

or

SecFilter ".*admin.*" mandatory,chain
SecFilter ".*login.*"

For more information refer to the ModSecurity documentation.

ModSecurity ModSecurity