＆QUOT; ModSecurity的访问被拒绝＆QUOT;在日志中。我不明白的告诉我..我应该关心？ [英] "ModSecurity Access Denied" in logs. I don't understand what its telling me.. Should I be concerned?
问题描述
我看到在我的关于访问日志以下三件事情被拒绝。他们两个有安全的关键。我真的不明白任何的他们的意思和周围有点谷歌搜索后，仍不能确定我是否应该予以关注或做任何事情。我在Apache上运行的Django与mod_wsgi的。
I am seeing the following three things in my logs about access being denied. Two of them have security as critical. I don't really understand any of what they mean and after googling around a bit, still am unsure if I should be concerned or do anything. I am running Django on Apache with mod_wsgi.
下面是三种：
的ModSecurity：访问与code 400（阶段2）拒绝。模式匹配^ \\\\ W +：/在REQUEST_URI_RAW。 [文件/usr/local/apache/conf/modsec-imh/01_base_rules.conf] [在线23] [ID960014] [味精代理访问尝试] [严重性关键] [标签 PROTOCOL_VIOLATION / PROXY_ACCESS] [主机名WWW。 MYSITE .COM] [URI/] [UNIQUE_IDVaM7bUYn @ 9YAACtkIA8AAABq]
ModSecurity: Access denied with code 400 (phase 2). Pattern match "^\\w+:/" at REQUEST_URI_RAW. [file "/usr/local/apache/conf/modsec-imh/01_base_rules.conf"] [line "23"] [id "960014"] [msg "Proxy access attempt"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/PROXY_ACCESS"] [hostname "www.MYSITE.com"] [uri "/"] [unique_id "VaM7bUYn@9YAACtkIA8AAABq"]
的ModSecurity：访问与code 501（阶段2）拒绝。模式匹配\"(?:\\\\b(?:(?:n(?:et(?:\\\\b\\\\W+?\\\\blocalgroup|\\\\.exe)|(?:map|c)\\\\.exe)|t(?:racer(?:oute|t)|elnet\\\\.exe|clsh8?|ftp)|(?:w(?:guest|sh)|rcmd|ftp)\\\\.exe|echo\\\\b\\\\W*?\\\\by+)\\\\b|c(?:md(?:(?:32)?\\\\.exe\\\\b|\\\\b\\\\W*?\\\\/c)|d(?:\\\\b\\\\W*?[\\\\\\\\/]|\\\\W*?\\\\.\\\\.)|hmod.{0,40}? ......在REQUEST_HEADERS：用户代理[文件/usr/local/apache/conf/modsec-imh/01_base_rules.conf] [在线100] [ID959006] [味精系统命令注入] [数据;邮件] [严重性关键] [标签WEB_ATTACK / COMMAND_INJECTION] [主机名WWW。 MYSITE .COM] [URI/robots.txt的] [UNIQUE_IDVaPVSUYn @ 9YAACtkNioAAABL ]
ModSecurity: Access denied with code 501 (phase 2). Pattern match "(?:\\b(?:(?:n(?:et(?:\\b\\W+?\\blocalgroup|\\.exe)|(?:map|c)\\.exe)|t(?:racer(?:oute|t)|elnet\\.exe|clsh8?|ftp)|(?:w(?:guest|sh)|rcmd|ftp)\\.exe|echo\\b\\W*?\\by+)\\b|c(?:md(?:(?:32)?\\.exe\\b|\\b\\W*?\\/c)|d(?:\\b\\W*?[\\\\/]|\\W*?\\.\\.)|hmod.{0,40}? ..." at REQUEST_HEADERS:User-Agent. [file "/usr/local/apache/conf/modsec-imh/01_base_rules.conf"] [line "100"] [id "959006"] [msg "System Command Injection"] [data "; mail"] [severity "CRITICAL"] [tag "WEB_ATTACK/COMMAND_INJECTION"] [hostname "www.MYSITE.com"] [uri "/robots.txt"] [unique_id "VaPVSUYn@9YAACtkNioAAABL"]
的ModSecurity：访问与code 406（阶段2）拒绝。模式匹配|在REQUEST_HEADERS\\\\％（[0-9A-FA-F] {2} U [0-9A-FA-F] {4}？！）：X-OPT转发。 [文件/usr/local/apache/conf/modsec-imh/01_base_rules.conf] [在线17] [ID950107] [味精URL编码滥用攻击企图] [严重性警告] [主机名WWW。 MYSITE .COM] [URI/static/images/MYIMAGE.png] [UNIQUE_IDVYnqMEYn @ 9YAAGtcKysAAAAT]
ModSecurity: Access denied with code 406 (phase 2). Pattern match "\\%(?![0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at REQUEST_HEADERS:X-Opt-Forward. [file "/usr/local/apache/conf/modsec-imh/01_base_rules.conf"] [line "17"] [id "950107"] [msg "URL Encoding Abuse Attack Attempt"] [severity "WARNING"] [hostname "www.MYSITE.com"] [uri "/static/images/MYIMAGE.png"] [unique_id "VYnqMEYn@9YAAGtcKysAAAAT"]
粗体部分在哪里我就编辑我的网站的东西。
任何帮助是AP preciated。谢谢！
The bold parts are where I edited things concerning my site. Any help is appreciated. Thanks!
推荐答案
运行的网站必然意味着你会得到像这些请求。网络是开放的，它的成本骗子/黑客/脚本小子没什么可写的脚本，并尝试，希望他们发现一个脆弱的一众网站或IP地址。这就像有一个电子邮件地址 - 很快你会得到垃圾邮件了。天色这种垃圾邮件是无害的，只是一个滋扰。有时候，你得到的东西，造成真正的伤害。
Running a website inevitably means you're going to get requests like these. The web is open and it costs scammers/hackers/script kiddies nothing to write a script and try numerous websites or IPs in the hope they find a vulnerable one. It's like having an email address - soon enough you'll get spam to it. Mostly this spam is harmless and just a nuisance. Occasionally you get something that causes real harm.
ModSecurity的是考察发送到您的服务器，块，然后根据一定的规则的Web请求的工具。这通常是通过写入规则来某些HTTP请求字段的比较为常规前pression完成。有一些免费的规则集可在网上和OWASP核心规则集（CRS）就是其中之一。它是用于搜索的普通攻击和任何规则ID 9XXXXX不同于
ModSecurity is a tool to examine web requests sent to your server and block then based on certain rules. This is usually done by writing rules to compare some of the HTTP request fields to a regular expression. There are some free rules sets available online and the OWASP Core Rule Set (CRS) is one of them. It is used to search for common attacks and any rule id 9XXXXX is from that.
ModSecurity的是具有许多优点的一个非常强大的工具来保护您的网站。然而，它并非没有缺点它也。一开始它让你意识到这样的请求 - 其中大部分是无害的，可能一直打你的网站没有问题了一段时间。然后，你可以在恐慌，当你看首次ModSecurity的日志文件，看到。在另一面，但更糟的是，它也可以阻止误报 - 合法的流量不应该被阻止。的方式类似垃圾邮件过滤器有时可以把一个真实的电子邮件中垃圾邮件文件夹。该CRS肯定需要调整针对特定的站点。
ModSecurity is a really powerful tool with many advantages to protect your website. However it's not without its downsides too. For a start it makes you aware of requests like these - most of which are harmless and have probably been hitting your site for a while with no issue. You can then get in a panic when you look at ModSecurity log files for first time and see that. On the flip side, but even worse, it can also block "false positives" - legitimate traffic that should not be blocked. Similar to the way a spam filter can sometimes put a real email in your spam folder. The CRS definitely needs tweaking for your particular site.
因此，与这样的背景下，让我们来看看你给了三个例子：
So with that background let's look at the three examples you gave:
第一条规则（960014）的颓势，可能是使用你的web服务器作为代理尝试的请求。骗子自己的服务器经常堵塞，所以他们喜欢通过其他服务器代理请求，从而将流量似乎来自你的IP，而不是他们的。 //在URL：当接收到一个字，后面是请求的规则被触发。这工作，因为请求不应该有这样的吧：www.example.com/page.html是一个合法的请求，但www.example.com/page.html/ http://www.example2.com 是不是一个合法的请求。然而，这很容易赶上误报这样的合法请求：www.example.com?referrer= http://www.google。 COM 。很多搜索引擎，广告，营销环节...等。可以使用那种格式而这些将停止由于这一规则的工作。个人而言，我不觉得这是规则非常有用。由默认的Apache具有抗试图使用你的web服务器作为代理，因此这个规则不会获得你很多，但可能会导致您的问题其自身的保护。我会关掉它。您可以在如何做到这一点到您的虚拟主机服务说话（通常添加一个SecRuleRemoveById 960014行.htaccess文件）。
The first rule (960014) is flagging a request that might be an attempt to use your webserver as a proxy. Scammer's own servers are often blocked, so they like to proxy requests via other servers so that traffic appears to come from your IP rather than theirs. The rule is triggered when a request is received with a word followed by :// in the URL. This works because a request should never have this in it: www.example.com/page.html is a legitimate request but www.example.com/page.html/http://www.example2.com is not a legitimate request. However this can easily catch false positives with legitimate requests like this: www.example.com?referrer=http://www.google.com. Many search engines, ads, marketing links...etc. may use that sort of format and these would stop working due to this rule. Personally I don't find this rule that useful. By default Apache has its own protection against attempts to use your webserver as a proxy so this rule doesn't gain you much but can cause you problems. I would turn it off. You can speak to your web host service on how to do this (usually add a "SecRuleRemoveById 960014" line to .htaccess file).
第二（959006）违背了用户代理找不可靠的请求非常复杂regexpr。一些CRS规则是很难理解，除非你在regexpr有个度！用户代理应该是你的浏览器和人人享有体面的浏览器返回一个良好的用户代理。此外，一些知道垃圾邮件工具使用特定的用户代理，这个规则可以很容易地阻止。不过这通常是很容易改变，因此，所以它看起来像一个正常的网页浏览器，这个规则真的只有拿起非常简单的错误的请求它可以发送一个很好的用户代理。再说也很少标记任何误报如此是因为一个好的规则。在这里，代理发送的用户是邮件（这样的一些规则有益写入显示器引起的问题，在日志中的价值 - 在数据字段在这种情况下）。 邮的用户代理肯定看起来嫌疑。现在，您可以指定在用户代理想要的任何东西，它应该不会造成问题（忽略试图操纵HTTP请求发送其他字段），所以这个规则并没有真正保护任何东西本身，但如果这请求发送类似的东西，在这一领域，那么它可能不是一个合法的请求，无论如何，他们可以试图请求其他位其他狡猾的请求 - 因此，为什么这一规则存在。鉴于有显示用户代理，我认为这条规则在这里做你很好地阻止错误请求，所以不要管它继续阻止。
The second (959006) runs a hugely complicated regexpr against the User Agent looking for dodgy requests. Some of the CRS rules are very difficult to understand unless you have a degree in regexpr! The User Agent should be your browser and all decent browsers return a good user agent. Additionally some know spam tools use a specific user agent that this rule can easily block. However that's usually easily changed so it can send a good user agent so it looks like a normal web browser so this rule really only picks up very simple bad requests. Then again it also rarely flags any false positives so is a nice rule because of that. Here the user agent sent was "; mail" (some rules like this are helpfully written to display the value that caused the issue, in the log - in this case in the "data" field). A user agent of "; mail" definitely looks suspect. Now you can specify anything you want in the user agent, and it shouldn't cause issues (ignoring attempts to manipulate the HTTP request to send other fields for now), so this rule doesn't really protect anything in itself, but if this requestor is sending something like that in that field, then it's probably not a legitimate request anyway and they could be trying other dodgy requests in other bits of the request - hence why this rule exists. Given the user agent shown there, I think this rule is doing you good here in blocking a bad request, so leave it alone to continue blocking.
最后一条规则看起来950107不良URL编码。网址连接codeS某些字符（如空格），所以像 HTTP请求：// WWW。 example.com?name=Joe 布罗格斯变成 HTTP：//www.example。 COM？NAME =乔％20Bloggs 这样的要求可以通过服务器处理。 URL编码有一个标准的已知的格式（基本上先从％，然后有一个十六进制值code（0-9或AF）），这样的要求是这样的：的 http://www.example.com?name=Joe%ZZBloggs 是无效的。在这种情况下不好比赛是上，我猜是通常用于通过代理处理的原始IP地址一个字段的X选择加入转发。想不出任何理由这个领域应该将此规则合法流量，所以再次我会说这是另一个骗子尝试自己的运气，这应该被阻止。
The last rule 950107 looks for bad URL encodings. A web address encodes some characters (like spaces) so a request like "http://www.example.com?name=Joe Bloggs" becomes "http://www.example.com?name=Joe%20Bloggs" so the request can be handled by servers. URL encodings have a standard known format (basically start with a % and then have a hexadecimal code (0-9 or a-f)) so a request like this: "http://www.example.com?name=Joe%ZZBloggs" is invalid. In this case the bad match was on the X-Opt-Forward which I'm guessing is a field usually used for the original IP address handled by a proxy. Can't think of any reason this field should flag this rule for legitimate traffic, so again I'd say this is another scammer trying his luck and this should be blocked.
很多采取在并希望帮助，但让我们知道，如果您有任何问题。
A lot to take in that and hope that helps but let us know if you have any questions.
这篇关于＆QUOT; ModSecurity的访问被拒绝＆QUOT;在日志中。我不明白的告诉我..我应该关心？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
