After much search and finding refrences like these that deem this impossible, even by AWS support, we have figured out how to set the default time zone for every session.
The reason AWS doesn’t support this is because it messes with the Replication/Multi-AZ and other aspects of the proprietor MySQL architecture on RDS.
Amazon RDS doesn’t allow you to change timezone, It keeps same UTC time zone across all regions.
The time_zone variable in the parameter group is read only, however if you have had to deal with these limitations you might be familiar with the init_connect command, the only problem is that if you use init_connect to change the time you can totally mess up your database when the rdsadmin user does DBA procedures on your MySQL database.
You can change the time zone on each connection or session by making a procedure in default mysql database and call this function on each init connection as long as the session does not belong to the SUPER privileged, automatically created and necessary rdsadmin user.
1- Create the procedure where -4 is the time difference with UTC
CREATE DEFINER=`mysql`@`%` PROCEDURE `fix_time`()
IF CURRENT_USER()<>’rdsadmin@%’ THEN
SET SESSION time_zone =’-4:00′;
2- Update your custom parameter group to call this stored procedure at the beginning of each session:
You can create/edit Parameter Groups from the AWS RDS web console, or use aws-cli like this to set the init_connect to CALL fix_time():
aws rds modify-db-parameter-group --db-parameter-group-name parameter_group_name --parameters "ParameterName=init_connect, ParameterValue=CALL mysql.fix_time, ApplyMethod=immediate"
3- Finally make sure your instance uses this parameter group, reboot an Valla!
Amazon CloudFront now allows you to set two new values, a Default TTL (Time To Live) and a Max time-to-live, so that you can control how long CloudFront caches your objects in each CDN node. This dramatically increases your control over the cache duration which previously only allowed you to set the Minimum TTL. Learn more about setting cascading cache rules for CloudFront here.
You can now set a TTL without setting cache control headers on each object at the origin, If you can’t set cache-control headers at your origin that was the case for many people who were using a third-party CMS.
Override cache-control headers set by your origin so that they don’t rely on the cache-control headers set by your origin specially when you don’t control the origin server, you can now easily override the cache-control headers by setting the same value for Max TTL, Min TTL and Default TTL.
Ensure that TTLs are always within a range you specify when setting both a Min TTL and a Max TTL, you can override origin configurations that might cause objects to be cached for longer or shorter periods than you intended.
There are no additional charges for configuring Min TTL, Max TTL, or Default TTL. You can learn more about these new features by reading the Specifying How Long Objects Stay in a CloudFront Edge Cache section on the Amazon CloudFront Developer Guide.
Google has just changed their search algorithm and how it will be ranking websites. Starting today the websites that are not either responsive, or have an alternative mobile website version that displays by identifying mobile devices, will be penalized in their SEO ranking, the mobile-friendly websites equipped with big fonts and big clickable elements and set Viewports, responsive to resizes to fit the mobile and tablet screens will rank higher.
Google announced this algorithm change back in February. These changes are not small either, Google announced that they will “have a significant impact in our search results.” Google want to return relevant, high quality search results that are optimized for the viewer device.
With over 60% of search traffic pouring in from mobile and tablets, small businesses – especially ones dependent on local search – need to ensure they’ve made the necessary changes so that their sites aren’t penalized by Google’s new ranking system. Columbus Software clients have already been optimized as early as 2008 and all websites have been responsive since 2012. New customers however can be assisted, we can fix the issue by writing responsive CSS 3 Media based queries to create a mobile fit-able version of your website by the end of weekend for only $150. Act now before you sink down in search!
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:
188.8.131.52 # lfd: (mod_security) mod_security (id:210410) triggered by 184.108.40.206 (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
220.127.116.11 # lfd: (mod_security) mod_security (id:950103) triggered by 18.104.22.168 (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
22.214.171.124 # lfd: (mod_security) mod_security (id:220030) triggered by 126.96.36.199 (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.
We have finished the first version of the Prestashop Module to load the AWS SDK Loader. The purpose of this module is to allow developers and site owners to use and develop custom scripts and modules that work with the Amazon Web Services PHP SDK, with the separation of concerns and preventing conflict between multiple modules as a result of each loading the SDK independently.
Here are some of the features of the AWS SDK Module for Prestashop:
- Load The Aws SDK onto every PHP page with the option to choose the SDK to load in the back office, front office, or both.
Load only the Classes you need for your application for performance optimization and security concern, for instance you can only choose to load the code for Amazon S3.
Allow other modules to use the AWS SDK without conflict or the need to load and maintain the SDK individually.
All patches and updates will be automatic with backward compatibility for dependent modules.
With a single click install you will be able to use AWS SDK on anypage by simply using the following syntax and declaring the namespace:
// Instantiate the service builder
$aws = Aws::factory(‘/path/to/your/config.php’);
// Instantiate S3 clients for example
$s3v2 = $aws->get(‘s3’);
We have developed the Google Chrome plugin for our live chat bar software, that can be accessed here: https://chrome.google.com/webstore/detail/live-chat-bar/olngcdbhbjgipfjobdcnaadldibbeacf
We are getting very close to finishing the Live Chat Bar Software as a Service. You can view more details on our Live Chat Bar website: livechatbar.com
This software will show you every visitor that comes to your website instantly with their location and device. You can instantly send them a message or wait for them to use the live chat bar in the bottom corner of your website. This software a full feature chat support feature, including XMPP support, Google Talk, Skype, Instant Email notifications.
ColumbusSoft has submitted the PrestaShop Amazon Web Services Module to the Official PrestShop Addons site.
This Module will allow you to load the AWS SDK for PHP, to be used by other modules or custom scripts without any conflicts as a result of each loading the SDK separately. Once enabled, you can access the AWS SDK from any php file in Prestashop.
We have developed this free module in the process of the Amazon S3 Bucket Upload Module that we are currently building for prestashop. All developers can take advantage of this module as a requirement.
This module has the following benefits:
1- Access the AWS SDK for php anywhere in presta shop with the same syntax offered by the SDK and examples: https://github.com/aws/aws-sdk-php
2- Install and use Multiple AWS Modules without conflict.
3- PrestaShop users can write custom code and scripts in PrestaShop php files by simply delaring the AWS namespace.
4- This Module allows other developers to create their own AWS modules that will run alongside other AWS Modules without any conflict as it is not possible to load the AWS-SDK twice, so modules can require this Module as a requirement before installation. For example the AWS S3 Bucket Module by ColumbusSoft.
5- Developers do not have to worry about applying AWS SDK upgrades and backwards compatibilities, a good seperation of concerns.
1- Access the AWS SDK for php anywhere in presta shop with the same syntax offered by the SDK and examples: https://github.com/aws/aws-sdk-php
2- Use Amazon S3 Bucket, and use Amazon S3 Stream Wrapper: http://docs.aws.amazon.com/aws-sdk-php/guide/latest/feature-s3-stream-wrapper.html
3- Use AWS CloudFront, Transcoder and anyother AWS Solution to wish to implemend.
Minimum requirements – To run the SDK, your system will need to meet the minimum requirements, including having PHP 5.3.3+ compiled with the cURL extension and cURL 7.16.2+ compiled with OpenSSL and zlib.
This Module will allow you to load the AWS SDK for PHP, to be used by other modules or custom scripts that need this SDK without any conflicts as a result of each module loading its own SDK. Once this module is enabled, you can access the AWS SDK from any php file in Prestashop as you would normally by declaring the namespace,
This module should be used for all AWS Modules to allow them to work simultaneously and efficiently. You can use with the same naming conventions and syntax AWS developers are used to.
Check out the Amazon S3 Module For Presta Uploads.