mod-security-developers Mailing List for ModSecurity (Page 41)
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-developers — Development discussion about mod_security
You can subscribe to this list here.
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(12) |
Mar
(42) |
Apr
(68) |
May
(30) |
Jun
(50) |
Jul
(17) |
Aug
(3) |
Sep
(5) |
Oct
(7) |
Nov
(3) |
Dec
(4) |
| 2012 |
Jan
(11) |
Feb
(11) |
Mar
(37) |
Apr
|
May
(21) |
Jun
(21) |
Jul
(12) |
Aug
(41) |
Sep
(19) |
Oct
(31) |
Nov
(24) |
Dec
(10) |
| 2013 |
Jan
(12) |
Feb
(18) |
Mar
(3) |
Apr
(8) |
May
(35) |
Jun
(5) |
Jul
(38) |
Aug
(5) |
Sep
(2) |
Oct
(4) |
Nov
(11) |
Dec
(6) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(11) |
Apr
(18) |
May
(2) |
Jun
(1) |
Jul
(11) |
Aug
(5) |
Sep
|
Oct
(15) |
Nov
(13) |
Dec
(9) |
| 2015 |
Jan
(2) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(11) |
Oct
(14) |
Nov
(4) |
Dec
(1) |
| 2016 |
Jan
(11) |
Feb
(19) |
Mar
(20) |
Apr
(6) |
May
(3) |
Jun
(17) |
Jul
(5) |
Aug
|
Sep
(7) |
Oct
(2) |
Nov
(2) |
Dec
(12) |
| 2017 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(15) |
| 2018 |
Jan
(13) |
Feb
(2) |
Mar
(14) |
Apr
(9) |
May
|
Jun
(6) |
Jul
(3) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
(13) |
Dec
(1) |
| 2019 |
Jan
(2) |
Feb
(9) |
Mar
(28) |
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(10) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-25 13:57:15
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-67.
-------------------------------------
Resolution: Fixed
> Implement MATCHED_VAR/MATCHED_VAR_NAME as a collections, MATCHED_VARS/MATCHED_VARS_NAMES
> ----------------------------------------------------------------------------------------
>
> Key: MODSEC-67
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-67
> Project: ModSecurity
> Issue Type: New Feature
> Security Level: Normal
> Reporter: Brian Rectanus
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
>
> We need to be able to get to what VARS (targets) matched. This is hard to do in chains with MATCHED_VAR and MATCHED_VAR_NAME being overwritten. Additionally, it allows us to count the matched targets for anomaly scoring, etc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-25 13:57:14
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-213.
--------------------------------------
Resolution: Fixed
> Add macro expansion support for rsub
> ------------------------------------
>
> Key: MODSEC-213
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-213
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Affects Versions: 2.5.13
> Reporter: Breno Silva Pinto
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
>
> rsub s/%{MACRO}/%{MACRO}/g
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-25 13:55:11
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-212.
--------------------------------------
Resolution: Fixed
> Add a new variable - UNIQUE_ID
> ------------------------------
>
> Key: MODSEC-212
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-212
> Project: ModSecurity
> Issue Type: New Feature
> Security Level: Normal
> Components: Targets
> Affects Versions: 2.5.13
> Reporter: Ryan Barnett
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
>
> Need to have a new variable - UNIQUE_ID that holds the transactional hash created by mod_uniqueid. This will be useful for a number of different scenarios including -
> https://www.modsecurity.org/tracker/browse/CORERULES-67
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-25 13:55:11
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-170.
--------------------------------------
Resolution: Fixed
> Add Macro Expansion to other actions such as Tag
> ------------------------------------------------
>
> Key: MODSEC-170
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-170
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Actions
> Affects Versions: 2.5.12
> Reporter: Ryan Barnett
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
>
> Need to add macro expansion capabilities to other actions such as tag so that we can do things like this:
> tag:'http://www.owasp.org/index.php?title=ModSecurity_CRS_RuleID-%{rule.id}
> This would place the proper rule id in the tag data (url) when an alert is triggered.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-16 16:03:00
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto closed MODSEC-163.
------------------------------------
> Patch Information
> -----------------
>
> Key: MODSEC-163
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-163
> Project: ModSecurity
> Issue Type: Task
> Security Level: Normal
> Environment: Modsecurity Patch Information
> Reporter: Technical Support Infinitium
> Assignee: Brian Rectanus
> Priority: High
>
> Please kindly keep us update for All version of Modsecurity's Patches.
> Thanks!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-16 16:01:02
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto closed MODSEC-161.
------------------------------------
> Issues with SecFilterScanPOST On
> --------------------------------
>
> Key: MODSEC-161
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-161
> Project: ModSecurity
> Issue Type: Task
> Security Level: Normal
> Components: Configuration
> Environment: Oracle HTTP Server 10.1.2.0.2
> Reporter: babu ramasamy
> Assignee: Brian Rectanus
>
> I have used SecFilterScanPOST On for addressing the web vulnerabilities for my applications. It seems that after this settings in httpd.conf file i have noticed that the report server page is not opening in the OAS console. And at the same time there have been CPU spiking when user initiated a reports.
> I believe there is issue with this settings and causes issue to the report server in OAS.
> Are there any know issues reported with this settings and how to overcome this?
> Your immediate comments/feedback on this issue will be of helpful as this is a production issue for us.
> Thanks,
> R.Babu
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-16 16:01:00
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto closed MODSEC-113.
------------------------------------
Assignee: Breno Silva PInto (was: Brian Rectanus)
> Change copyright dates to 2010
> ------------------------------
>
> Key: MODSEC-113
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-113
> Project: ModSecurity
> Issue Type: Task
> Security Level: Normal
> Reporter: Brian Rectanus
> Assignee: Breno Silva PInto
> Fix For: 2.5.12
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-16 16:00:57
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto closed MODSEC-72.
-----------------------------------
Assignee: Breno Silva Pinto (was: Brian Rectanus)
> Modsecurity 2.5.9
> -----------------
>
> Key: MODSEC-72
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-72
> Project: ModSecurity
> Issue Type: Task
> Security Level: Normal
> Affects Versions: 2.5.9
> Environment: HP-UX
> Reporter: johny lint
> Assignee: Breno Silva Pinto
> Priority: High
>
> As per a security website the fix for the latest security bug is to upgrade to version 2.5.9 for Modsecurity , Is this security vulnerability there in 2.1.7? If yes, then there do we have a fix in 2.1.x ?Wanted to know if this is valid upgradation for 2.1.x series as well. Currently we have 2.1.7 , so should this be upgraded to 2.5.9 . Can we directly upgrade from 2.1.x to 2.5.x or will there be any issues?Or is 2.1.x code drop and 2.5.x code drops two differnet branches of Modsecurity?
> Regards.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-16 16:00:56
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto closed MODSEC-79.
-----------------------------------
Assignee: Breno Silva Pinto (was: Brian Rectanus)
> Add in new CRS 2.0 into ModSecurity src
> ---------------------------------------
>
> Key: MODSEC-79
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-79
> Project: ModSecurity
> Issue Type: Task
> Security Level: Normal
> Components: Rules
> Affects Versions: 2.5.9
> Reporter: Brian Rectanus
> Assignee: Breno Silva Pinto
> Fix For: 2.5.10
>
>
> Need to add in CRS 2.0 for packaging with 2.5.10.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-16 13:32:56
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-19.
-------------------------------------
Resolution: Not a Bug
> Final boundary missing with Docushare
> -------------------------------------
>
> Key: MODSEC-19
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-19
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.6
> Environment: purely a rule issue I think?
> Reporter: Jason Haar
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
> Attachments: dump.tgz, httpTx-215272.dat.bz2, sample.log.gz
>
>
> Docushare (from Xerox) has a "native" win32 client that allows users to "mount" Docushare servers - so they can drag-n-drop. I think it was sort of a precursor to WebDAV? From what I've seen, it reminds me a bit of a Windows subversion client app - TortoiseSVN
> Anyway, I am seeing modsec blocking users from using this native app. I see "ModSecurity: Multipart parsing error: Multipart: Final boundary missing" trigger, followed directly by 960912 - "Warning. Match of "eq 0" against "REQBODY_PROCESSOR_ERROR" required"
> I'll attach the modaudit dump of the event - after removing the content.
> [Sun Sep 14 09:08:57 2008] [error] [client 192.168.0.182] ModSecurity: Warning. Match of "eq 0" against "REQBODY_PROCESSOR_ERROR" required. [file "/etc/httpd/modsecurity.d/modsecurity_crs_20_protocol_violations.conf"] [line "31"] [id "960912"] [msg "Request Body Parsing Failed. Multipart parsing error: Multipart: Final boundary missing."] [severity "CRITICAL"] [hostname "hst.domain.com"] [uri "/docushare/dscgi/ds.py/ApplyUpload/File-287346"] [unique_id "dsx7wQoBPEEAADLnULsAAAAy"]
> [Sun Sep 14 09:09:27 2008] [error] [client 192.168.0.182] ModSecurity: Multipart parsing error: Multipart: Final boundary missing. [hostname "hst.domain.com"] [uri "/docushare/dscgi/ds.py/ApplyUpload/File-287347"] [unique_id "eDBmKQoBPEEAADLnULwAAAAy"]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-16 13:32:55
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-34.
-------------------------------------
Resolution: Cannot Reproduce
> docushare users generating "Multipart: Invalid boundary in C-T (malformed)" errors
> ----------------------------------------------------------------------------------
>
> Key: MODSEC-34
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-34
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.7
> Environment: CentOS5
> Reporter: Jason Haar
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
> Attachments: 20081027-203010--1HkuAoBPEEAACAe544AAAAa.gz
>
>
> We're seeing this several times a day on a backend docushare server with modsecurity running in monitor mode (ie non-blocking)
> [Mon Oct 27 20:30:09 2008] [error] [client 10.1.94.38] ModSecurity: Multipart parsing error (init): Multipart: Invalid boundary in C-T (malformed). [hostname "trl.trimble.com"] [uri "/docushare/dscgi/ds.py/ApplyUpload/Collection-59919"] [unique_id "-1HkuAoBPEEAACAe544AAAAa"]
> As with MODSEC-19, the client is the "Docushare client" instead of a Webbrowser. I'll attach the audit log I have (after I strip out the content), but assuming the issue is something to do with Content-Type values, they are:
> Content-Type: multipart/form-data; charset=UTF-8; boundary=354e650f45ec2927
> Content-Type: application/octet-stream
> Content-Type: text/xml;charset=UTF-8
> I have been unable to go production (block mode) with modsecurity on this Docushare backend due to their damn client that I'm tempted to just disable modsec if the User-Agent matches "DsAxess/*". Other than opening up a security risk, should the following achieve that?
> SecRule REQUEST_HEADERS:User-Agent "^DsAxess/" "allow, nolog, ctl:ruleEngine=Off,ctl:auditEngine=Off"
> I'm assuming in all this, that as this isn't a "rule" hit, in block mode this would mean these requests would be error'ing? i.e. I have to turn modsecurity totally off in order for these to work?
> Thanks
> Jason
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-15 23:08:53
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto closed MODSEC-145.
------------------------------------
> Make mlogc available outside ModSecurity
> ----------------------------------------
>
> Key: MODSEC-145
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-145
> Project: ModSecurity
> Issue Type: Task
> Security Level: Normal
> Components: Mlogc
> Reporter: denis
> Assignee: Breno Silva Pinto
> Priority: Wish
> Fix For: 2.6.0
>
>
> Hi! Were I can download mlogc without modsecurity? This is link dont work https://bsn.breach.com/downloads/mlogc/
> Thanks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-15 22:55:54
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-1.
------------------------------------
Resolution: Cannot Reproduce
The cleanup code is running as expected. However it is difficult to know what can happens when disk space if full. Many problems can occurs including bad operation of OS.
> Temporary files not cleaned up after errors
> -------------------------------------------
>
> Key: MODSEC-1
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-1
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.6
> Reporter: Brian Rectanus
> Assignee: Breno Silva Pinto
> Priority: Low
> Fix For: 2.6.0
>
>
> Under some error conditions (such as disk full, etc) temporary files (request body) are not removed from disk.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-11 19:16:40
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-30.
-------------------------------------
Resolution: Not a Bug
> mod_rewrite incompatibility
> ---------------------------
>
> Key: MODSEC-30
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-30
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.7
> Environment: CentOS 4.6 (Linux linux-dev 2.6.9-78.0.1.ELsmp #1 SMP Tue Aug 5 11:02:47 EDT 2008 i686 i686 i386 GNU/Linux)
> # /usr/local/apache2/bin/httpd -V
> Server version: Apache/2.2.10 (Unix)
> Server built: Oct 23 2008 09:05:23
> Server's Module Magic Number: 20051115:18
> Server loaded: APR 1.3.3, APR-Util 1.3.4
> Compiled using: APR 1.3.3, APR-Util 1.3.4
> Architecture: 32-bit
> Server MPM: Prefork
> threaded: no
> forked: yes (variable process count)
> Server compiled with....
> -D APACHE_MPM_DIR="server/mpm/prefork"
> -D APR_HAS_SENDFILE
> -D APR_HAS_MMAP
> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
> -D APR_USE_SYSVSEM_SERIALIZE
> -D APR_USE_PTHREAD_SERIALIZE
> -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
> -D APR_HAS_OTHER_CHILD
> -D AP_HAVE_RELIABLE_PIPED_LOGS
> -D DYNAMIC_MODULE_LIMIT=128
> -D HTTPD_ROOT="/usr/local/apache2"
> -D SUEXEC_BIN="/usr/local/apache2/bin/suexec"
> -D DEFAULT_PIDLOG="logs/httpd.pid"
> -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
> -D DEFAULT_LOCKFILE="logs/accept.lock"
> -D DEFAULT_ERRORLOG="logs/error_log"
> -D AP_TYPES_CONFIG_FILE="conf/mime.types"
> -D SERVER_CONFIG_FILE="conf/httpd.conf"
> # /usr/local/apache2/bin/httpd -M
> Loaded Modules:
> core_module (static)
> authn_file_module (static)
> authn_default_module (static)
> authz_host_module (static)
> authz_groupfile_module (static)
> authz_user_module (static)
> authz_default_module (static)
> auth_basic_module (static)
> filter_module (static)
> deflate_module (static)
> log_config_module (static)
> env_module (static)
> unique_id_module (static)
> setenvif_module (static)
> ssl_module (static)
> mpm_prefork_module (static)
> http_module (static)
> mime_module (static)
> status_module (static)
> autoindex_module (static)
> asis_module (static)
> cgi_module (static)
> negotiation_module (static)
> dir_module (static)
> actions_module (static)
> alias_module (static)
> rewrite_module (static)
> so_module (static)
> php5_module (shared)
> security2_module (shared)
> Syntax OK
> Reporter: Michael Caplan
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
> Attachments: modsec_debug.zip, rewrite.zip
>
>
> modsecurity outbound filtering rules (modsecurity_crs_50_outbound.conf) are not being applied if the incoming request goes through the following mod_rewrite recipe:
> RewriteEngine on
> RewriteCond %{SCRIPT_FILENAME} !-f
> RewriteCond %{SCRIPT_FILENAME} !-d
> RewriteRule ^(.*)$ index.php/$1
> Inbound modsecurity rules are seemingly applied fine, but all tests against the response body are not being executed. Running with modsecurity debug log set to 9, I see no evidence of any of the outbound rules being attempted.
> Brian Rectanus' initial thoughts:
> This looks like a bug. Those rewrite rule produce an internal request.
> When this happens, ModSecurity does not see the response on the main request that it is looking at (ie the MODSECURITY_OUT output filter is never called). The response seems to be attached to the internal request which is ignored.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-11 18:52:42
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-144.
--------------------------------------
Resolution: Fixed
> Make sure mod_security is working with latest Apache httpd trunk (2.3.x)
> ------------------------------------------------------------------------
>
> Key: MODSEC-144
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-144
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Build System, Core
> Reporter: Brian Rectanus
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
>
> Apache 2.3 is in the works and we need to make sure 2.6 works there.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-11 17:35:38
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-173.
--------------------------------------
Resolution: Fixed
> under high load (depending on IO speed), auditlog could loose entries due to race condition in apr_dir_make_recursive()
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: MODSEC-173
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-173
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Logging
> Affects Versions: 2.5.12
> Environment: using libapr-1.so.0.4.2 from apache httpd 2.2.16
> Reporter: Christoph Moench-Tegeder
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
> Attachments: msc_logging.c.diff
>
>
> When running multiple threads with apache, several audit log entries might be written at (more or less) exactly the same time. In this case apr_dir_make_recursive() can return APR_EEXIST (classical stat()/mkdir() race condition). In this case, writing the audit log entry will fail with the message "Failed to create subdirectories: File exists".
> To work around this issue, one should allow APR_EEXIST from apr_dir_make_recursive(), too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. P. (JIRA) <no...@mo...> - 2011-03-11 17:26:38
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Breno Silva Pinto resolved MODSEC-171.
--------------------------------------
Resolution: Fixed
> input_filter() modifies brigade and returns APR_SUCCESS, prevents additional input filters from running
> -------------------------------------------------------------------------------------------------------
>
> Key: MODSEC-171
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-171
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.12
> Reporter: Christoph Moench-Tegeder
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
> Attachments: apache2_io.c.diff
>
>
> In apache2/apache_io.c function input_filter() returns APR_SUCCESS (in case no error or block reason was found) (line 142) instead of passing the brigade down to the next filter using ap_pass_brigade(). The fix should be trivial (just replace the offending APR_SUCCESS with ap_pass_brigade(f->next, bb_out)).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Ryan B. (JIRA) <no...@mo...> - 2011-03-11 16:00:35
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Barnett closed MODSEC-33.
------------------------------
Resolution: Fixed
Updated the Reference Manual documentation - https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#inspectFile
> Improvements to Documentation
> -----------------------------
>
> Key: MODSEC-33
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-33
> Project: ModSecurity
> Issue Type: Improvement
> Security Level: Normal
> Components: Documentation
> Reporter: Brian Rectanus
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
>
> Some suggested documentation changes:
> * Need to at least document that using a non-gcc compiler may need manual Makefile tweaks due to gcc-specific options used. This really needs fixed so that non-gcc compilers can be used, but probably post-2.5.
> * @inspectFile has virtually no documentation relevant to get it to work without looking at source or an example.
> * Mention the directives for phase control in the "Processing Phases" section (access, limits, etc).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Breno S. <bre...@gm...> - 2011-03-11 15:57:50
|
Hi everybody, We need to check if the modsecurity 2.6.0 is compiling under a solaris box. Anybody with a sun box could try it ? thanks Breno |
|
From: Ryan B. (JIRA) <no...@mo...> - 2011-03-11 14:53:38
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Barnett closed MODSEC-46.
------------------------------
Resolution: Invalid Config
This has been addressed in the CRS by having all skipAfter actions use SecMarker locations instead of active ruleIDs.
> SecRuleRemoveById vs SecRuleUpdateActionById
> --------------------------------------------
>
> Key: MODSEC-46
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-46
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.7
> Environment: CentOS5
> Reporter: Jason Haar
> Assignee: Breno Silva Pinto
> Fix For: 2.6.0
>
>
> I have spent around two weeks trying to find out why one of our backend servers wasn't been protected by modsecurity, when others were. The only difference between the configs came down to some SecRuleRemoveById rules, and sure enough, when I commented them all out, the server started blocking things it was supposed to. In the end I had to disable them all, and one by one re-enable them until the problem re-appeared, to figure out the cause.
> It was rule 959005, and it was actually the line "SecAction phase:2,pass,nolog,skipAfter:959005" in modsecurity_crs_40_generic_attacks.conf that caused the problem. Basically disabling that one rule caused the skipAfter to trigger and skip all the remaining rules?
> Anyway, I see that back in Jan Ofer Shezaf had the same problem, and the solution mentioned for him worked for me too - use SecRuleUpdateActionById instead.
> I think that's a REAL GOTCHA. That's just plain too hard to remember. Most of your users won't have testbeds of attacks they try against their servers, and one day they'll disable one rule and won't even know they've effectively disabled modsecurity due to some skipAfter rule. I mean - there isn't even a relationship. You test rule "x", find it doesn't work when it should, and it ends up being an issue associated with rule Y.
> It seems to me I'd be better off just exclusively using SecRuleUpdateActionById to disable rules. If that is true, why bother having SecRuleRemoveById? Or alias SecRuleRemoveById to "SecRuleUpdateActionById NUMBER 'pass,nolog'"?
> Or, what about making SecRuleRemoveById not remove all traces of the rule, so that skipAfter can still act properly?
> Just my 2cents
> Jason
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Ryan B. (JIRA) <no...@mo...> - 2011-03-11 14:11:39
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Barnett closed MODSEC-154.
-------------------------------
Resolution: Won't Fix
User needed to check apxs perms.
> compilation --with-apxs usage trivial
> -------------------------------------
>
> Key: MODSEC-154
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-154
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Configuration
> Affects Versions: 2.5.12
> Environment: httpd - 2.2.14 centos
> Reporter: Shelton Computers
> Assignee: Breno Silva Pinto
>
> /usr/local/bin/apxs is the path to the apxs binary.
> Using ./configure --prefix=/usr/local --with-apxs=/usr/local/sbin/apxs results in configure script failing with:
> configure: looking for Apache module support via DSO through APXS
> configure: error: couldn't find APXS
> Using ./configure --prefix=/usr/local --with-apxs=/usr/local/sbin/ results in configure passing but make failing with:
> apache2]# make
> build/apxs-wrapper: line 15: /usr/bin: is a directory
> build/apxs-wrapper: line 15: exec: /usr/bin: cannot execute: Success
> make: *** [mod_security2.la] Error 126
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Ryan B. (JIRA) <no...@mo...> - 2011-03-10 21:46:57
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Barnett closed MODSEC-150.
-------------------------------
Resolution: Not a Bug
User just needs to update the modsec-clamscan.pl script to use the McaFee tool.
> ModSecurity an Mcafee Antivirus integration
> --------------------------------------------
>
> Key: MODSEC-150
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-150
> Project: ModSecurity
> Issue Type: Task
> Security Level: Normal
> Components: Operators
> Affects Versions: 2.5.6
> Environment: Linux RedHat 5.4
> Reporter: migliorini marina
> Assignee: Breno Silva Pinto
> Priority: Wish
> Attachments: modsec-clamscan.pl
>
>
> I saw that ModSecurity, through SecUploadApproveScript /path/to/script.sh function, lets you check file uploads for viruses by starting a script that triggers the virus scanner. We also saw that through this method ModSecurity can call ClamAV antivirus. But what about Mcafee antivirus? Do you know of any integration between Mcafee and ModSecurity? If yes have you got any documentation giving us some example of this integration?
> Thanks in advance
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Ryan B. (JIRA) <no...@mo...> - 2011-03-10 21:32:35
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Barnett closed MODSEC-166.
-------------------------------
Resolution: Fixed
We updated the link in the Reference Manual to point to the current CSV repo -
https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecGuardianLog
> SecGuardianLog documentation error, 404
> ---------------------------------------
>
> Key: MODSEC-166
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-166
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Documentation
> Affects Versions: 2.5.12
> Environment: N/A
> Reporter: Jason Martin
> Assignee: Breno Silva Pinto
> Priority: Low
>
> At http://www.modsecurity.org/documentation/modsecurity-apache/2.5.12/html-multipage/configuration-directives.html#N10689, the link to http://www.apachesecurity.net/tools/ is broken.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Ryan B. (JIRA) <no...@mo...> - 2011-03-10 21:28:34
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Barnett closed MODSEC-169.
-------------------------------
Fix Version/s: 2.5.13
Resolution: Fixed
This issue is fixed in 2.5.13
> Chain rule + Macro resolved Error...
> ------------------------------------
>
> Key: MODSEC-169
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-169
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Actions
> Affects Versions: 2.5.12
> Environment: OS : CentOS release 4.8 (Final) / CPU : AMD Phenom(tm) II X4 945 Processor
> Reporter: Choi Min Kuk
> Assignee: Breno Silva Pinto
> Priority: Low
> Fix For: 2.5.13
>
>
> Sorry, I don't english well.. because to directly question..
> Error,
> Using Chain Rule => Don't Macro Resovle..
> Example>
> SecRule REQUEST_URI "modtest" "chain,redirect:modsec_error.html?rq=%{REQUEST_HEADERS.host}%{REQUEST_URI}"
> SecRule REQUEST_URI "html"
> --- Result : Redirected : /modsec_error.html?rq=%{REQUEST_HEADERS.host}%{REQUEST_URI}
> I want result : /modsec_error.html?rq=hostname/request_uri
> But, not using chain action -> result : /modsec_error.html?rq=hostname/request_uri ..
> bottom...Modsecurity Debug log...
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][5] Rule 552af7e950: SecRule "REQUEST_URI" "@rx modtest" "log,auditlog,status:403,phase:2,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,redirect:http://help.onmaru.com/modsec_
> error.html?rq=%{REQUEST_HEADERS.host}%{REQUEST_URI},chain"
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] CACHE: Enabled
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] T (0) urlDecodeUni: "/test/modtest.html"
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] T (0) htmlEntityDecode: "/test/modtest.html"
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] T (0) lowercase: "/test/modtest.html"
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][4] Transformation completed in 19 usec.
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][4] Executing operator "rx" with param "modtest" against REQUEST_URI.
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] Target value: "/test/modtest.html"
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][4] Operator completed in 2 usec.
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][4] Rule returned 1.
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] Match -> mode NEXT_RULE.
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][4] Recipe: Invoking rule 552af7f608; [file "/etc/httpd/conf.d/virtual.conf"] [line "1255"].
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][5] Rule 552af7f608: SecRule "REQUEST_URI" "@rx html" "log,auditlog,status:403,phase:2,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,redirect:http://help.onmaru.com/modsec_err
> or.html?rq=%{REQUEST_HEADERS.host}%{REQUEST_URI}"
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] CACHE: Enabled
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] T (0) urlDecodeUni,htmlEntityDecode,lowercase: "/test/modtest.html" [cached hits=1]
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][4] Transformation completed in 6 usec.
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][4] Executing operator "rx" with param "html" against REQUEST_URI.
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] Target value: "/test/modtest.html"
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][4] Operator completed in 1 usec.
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] Resolved macro %{REQUEST_HEADERS.host} to "cmkmh.maru.net"
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] Resolved macro %{REQUEST_URI} to "/test/modtest.html"
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][4] Rule returned 1.
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][9] Match, intercepted -> returning.
> [17/Aug/2010:18:33:44 +0900] [cmkmh.maru.net/sid#552b385620][rid#552c4f2658][/test/modtest.html][1] Access denied with redirection to http://help.onmaru.com/modsec_error.html?rq=%{REQUEST_HEADERS.host}%{REQUEST_URI} using status 302 (phase 2). Pattern match "html" at REQ
> UEST_URI. [file "/etc/httpd/conf.d/virtual.conf"] [line "1254"]
> Look...Macro resolving at line 1255.. but redirect is line 1254...
> Can you help me?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Ryan B. (JIRA) <no...@mo...> - 2011-03-10 16:31:49
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Barnett closed MODSEC-201.
-------------------------------
Resolution: Won't Fix
As Brian showed, this type of functionality can be achieved through different SecRule methods (setvars and skipAfters)
> Expiration/activation date
> --------------------------
>
> Key: MODSEC-201
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-201
> Project: ModSecurity
> Issue Type: New Feature
> Security Level: Normal
> Components: Core
> Affects Versions: 2.5.13
> Reporter: Marc Stern
> Assignee: Breno Silva Pinto
>
> It would be very handy to be able to specify a date range when a rule should be active.
> The main interest is when using rules to "open" an application.
> For example: SecAction "ctl:ruleRemoveById=200111,date=20110213-20110215" to disable a rule for 2 days
> We could also used "timestamp" if we want to be able to specify a time on top of the date.
> One of the parameters could be optional "date=-20110215" (up to) or "date=20110213-" (from).
> This is a good practice in network firewalls to not forget to remove a rule used during tests or specific occasions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
10 messages has been excluded from this view by a project administrator.
