Misuse of CloudFront by hackers can get your CDN blocked by your server, this can be a problem. Unfortunately for security reasons you do not want to allow CloudFront to by pass mod security, as this can be exploited by Mod Security:
18.104.22.168 # lfd: (mod_security) mod_security (id:210410) triggered by 22.214.171.124 (US/United States/server-216-137-42-131.dfw3.r.cloudfront.net): 5 in the last 3600 secs – Thu Mar 12 22:13:57 2015
126.96.36.199 # lfd: (mod_security) mod_security (id:950103) triggered by 188.8.131.52 (US/United States/server-205-251-218-78.arn1.r.cloudfront.net): 5 in the last 3600 secs – Sun Mar 15 23:38:33 2015
184.108.40.206 # lfd: (mod_security) mod_security (id:220030) triggered by 220.127.116.11 (US/United States/server-54-240-145-159.fra6.r.cloudfront.net): 5 in the last 3600 secs – Mon Mar 16 07:07:34 2015
We are considering to make an effort to build something to allow Mod Security to block X-IP-ADDRESS header instead of the actual IP which belongs to the CDN, meanwhile the best thing you can do is to make sure while mod security blocks risky requests, it doesn’t become black listed.
Here is the full list of IP address ranges used by Amazon Cloud Front up to this date, add them to your “Firewall Allow IPs” list:
ColumbusSoft’s Free collection of multiple 3rd-Party and customer ModSecurity rule sets to add additional security with extra attention to WordPress, WHMCS, Joomla, Prestashop and etc.
In this release we have included the Comodo Web Application Firewall, a set of Free ModSecurity Rules from Comodo that provides powerful, real-time protection for your web applications, this is while cPanel/WHM has launched it’s own ModSecurity feature without the need to use ConfigServer to install mod_sec rules.
If you are running websites on Apache and Linux based web-servers with cPanel/WHM you might have seen the default OWASP Modsecurity Vendor that comes with cPanel.
But what if you need to add more security rules to address a wider range of exploits and vulnerabilities? While cPanel allow you to add other Modsecurity Vendor to WHM, you might have had a hard time finding any other Modsecurity Vendors that provide complementary rules. As of this writing we are the only 3rd Party Modsecurity Vendor providing rule sets to secure your server and web applications against SQL injection, XSS, file disclosure and other zero-day exploits that follow similar patterns.
Our Modsecurity Vendor rules are available publicly to be added to the Modsecurity Vendor Rules For cPanel/WHM 11.46 Release that includes a very eloquent feature to manage ModSecurity without the need of extra plugins such as the ConfigSever Modsecurity plugin.
3 Step Simple Installation1) cPanel/WHM > Security Center > ModSecurity™ Vendors 2) Click on "Add Vendor" and paste the following Vendor Configuration URL: http://columbussoft.net/api/modsecurity-rules/meta_ColumbusSoft.yaml 3) Click Load and then Save! *) You can install and load these rules for Free, but then after you will need to pay a convenience fee to get a license for enabling automatic updates. ($9/month)
This is our first and beta version, our collection is small now and other than some custom security rules, related to Wordpres, WPScan, Joomla and WHMCS, we have one major library from Comodo’s Free ModSecurity Rules which was the inspiration for this project. We waited several months for a COMODO Modsecurity Vendor to support the new cPanel/WHM ModSecurity Vendor feature, we were not able to find any third party ModSecurity Vendors other than the default OWASP ModSecurity Core Rule Set that ships with cPanel 11.46 Release and later.
The goal of this project is to utilize this great new features and interface by cPanel and add every useful rules that are out there and not shipped with cPanel.
What's New in Version 1.25: - WPScan default user-agent blocker - Multiple vulnerabilities in pfSense - CVE-2014-5115 - CVE-2014-4852 - CVE-2014-4533 - CVE-2014-4552 - CVE-2014-4554 - CVE-2014-4555 - CVE-2014-4556 - CVE-2014-4557 - CVE-2014-4563 - CVE-2014-4564 - CVE-2014-4565 - CVE-2014-4566 - CVE-2014-4594 - CVE-2014-4595 - CVE-2014-4596 - CVE-2014-5183 - CVE-2014-5184 - CVE-2014-5187 - CVE-2014-5194 - CVE-2014-5186 - CVE-2014-4575 - CVE-2014-4584 - CVE-2014-4585 - CVE-2014-4587 - CVE-2014-4604 - CVE-2014-4605 - CVE-2014-4606 - CVE-2014-4939 - CVE-2014-4940 - CVE-2014-4941 - CVE-2014-5180 - CVE-2014-5190 - CVE-2014-5196 - CVE-2014-5022 - CVE-2014-5181 - CVE-2014-5182 - CVE-2014-5193 - CVE-2014-5199 - CVE-2014-5201 - CVE-2014-5202 - Extra WHMCS protection rule - Extra WordPress protection rule
- CVE-2013-3727 [SQLi] Kasseler CMS
- CVE-2013-3728 [XSS] Kasseler CMS
- CVE-2014-1222 [Dir.Traversal] Vtiger CRM before 6.0.0 Security patch 1
- CVE-2014-4002 [XSS] Cacti 0.8.8b
- CVE-2014-4524 [XSS] WP Easy Post Types plugin before 1.4.4 for WordPress
- CVE-2014-4526 [XSS] efence plugin 1.3.2 and earlier for WordPress
- CVE-2014-4527 [XSS] EnvialoSimple: Email Marketing and Newsletters plugin before 1.98 for WordPress
- CVE-2014-4534 [XSS] HTML5 Video Player with Playlist plugin 2.4.0 and earlier for WordPress
- CVE-2014-4537 [XSS] Keyword Strategy Internal Links plugin 2.0 and earlier for WordPress
- CVE-2014-4538 [XSS] Malware Finder plugin 1.1 and earlier for WordPress
- CVE-2014-4549 [XSS] WooCommerce SagePay Direct Payment Gateway plugin before 0.1.6.7 for WordPress
- CVE-2014-4560 [XSS] ToolPage plugin 1.6.1 and earlier for WordPress
- CVE-2014-4574 [XSS] WebEngage plugin before 2.0.1 for WordPress
- CVE-2014-4581 [XSS] WPCB plugin 2.4.8 and earlier for WordPress
- CVE-2014-4582 [XSS] WP Consultant plugin 1.0 and earlier for WordPress
- CVE-2014-4583 [XSS] WP-Contact (wp-contact-sidebar-widget) plugin 1.0 and earlier for WordPress
- CVE-2014-4586 [XSS] wp-football plugin 1.1 and earlier for WordPress
- CVE-2014-4591 [XSS] WP-Picasa-Image plugin 1.0 and earlier for WordPress
- CVE-2014-4593 [XSS] WP Plugin Manager (wppm) plugin 1.6.4.b and earlier for WordPress
- CVE-2014-4942 [Information] The EasyCart (wp-easycart) plugin before 2.0.6 for WordPress
- CVE-2014-4944 [SQLi] BSK PDF Manager plugin 1.3.2 for WordPress
- CVE-2014-4600 [XSS] WP Ultimate Email Marketer plugin 1.1.0 and earlier for WordPress
- CVE-2014-4601 [XSS] Wu-Rating plugin 1.0 12319 and earlier for WordPress
- CVE-2014-4602 [XSS] XEN Carousel plugin 0.12.2 and earlier for WordPress
- CVE-2014-5192 [SQLi] Sphider
- CVE-2014-5337 [Information] The WordPress Mobile Pack plugin before 2.0.2 for WordPress
- CVE-2014-5343 [XSS] Attack in Feng Office
- CVE-2014-5344 [XSS] Mobiloud plugin before 2.3.8 for WordPress
- CVE-2014-5345 [XSS] Possible XSS Attack in Disqus Comment System plugin before 2.76 for WordPress
- CVE-2014-5347 [CSRF/XSS] Disqus Comment System plugin before 2.76 for WordPress
- CVE-2014-5368 [Dir.Traversal] WP Content Source Control plugin 3.0.0 and earlier for WordPress
- Possible Shell Upload Vulnerability in extplorer plugin for Joomla!
- Blocking execution of an uloaded shell in Joomla!
If you’re using Route 53 health checks, you must ensure that your router and firewall rules allow inbound traffic from the IP addresses used by Route 53’s health checkers, so that Route 53 can access the endpoints that you specify in your health checks.
As we have explained earlier in our forum post [ https://forums.aws.amazon.com/ann.jspa?annID=1838 ], we are adding new IP ranges to the existing ranges.
The following is the list of existing IP ranges currently used by Route53 health checking service:
In addition to the list above, the following is the list of new IP ranges from which Route 53 will be conducting health checks:
Please ensure that the router / firewall rules for all of your endpoints that you are health checking with Route 53 are configured to allow incoming traffic from both existing and new IP ranges.