An interesting article on Science Alert about how cellular biology is influenced by magnetic fields. This can trigger cellular reactions that, in theory, can influence biological behavior. It is a theory in how living things, like migratory birds, can detect Earth’s magnetic fields and navigate using them.
The past few days have been spent diagnosing various email delivery issues from the AWS web cluster that is running our WordPress plugin store as well as our SaaS locator platform. During this process email routing was pushed from the servers through the AWS Simple Email System. SNS notifications were enabled to monitor the progress and provide some insight as to what was happening on the send mail side of things.
Not far into the mission something odd was showing up. Email delivery notifications were being transmitted from our documentation server — a basic WordPress install with almost no plugins running and a simplified theme. Yet in the “delivered” stack of SNS notifications there were random email addresses being spammed every 30-60 seconds.
The Culprit? Jetpack
Turns out the documentation site has Jetpack installed. It also has the default settings for the publicize sharing enabled. This includes email sharing.
After a good bit of research it was found that the mailing subsytem was being exploited through the front end interface for sharing a post via email. The Postfix mail logs provide immediate evidence of this.Read More
Lesson learned — if you are using EFS on production systems you want to be using provisioned throughput mode.
But, before we get into that, let’s go over the details of this implementation…
We utilize AWS EC2 instances to run multiple WordPress sites hosted in different directories. The configuration is fairly standard: 2+ servers configured as part of an load-balanced cluster. The servers run from the same image meaning they use the same underlying software stack.
Part of that image includes a mounted EFS (Elastic File Storage) directory , used to share WordPress resources between all nodes in the cluster. The original architecture was designed to host not only the typically-shared wp-content/uploads folder of WordPress via this EFS mount but also the code. The thought was that sharing the code in this way would allow a system admin to easily update WordPress core, plugins, or themes from the typical wp-admin web login. Any code updates would immediately be reflected across all nodes.
EFS Web App Code Hosting – A Bad Idea
Turns out this is a bad idea for a few reasons. First of all, EFS volumes are mounted using the NFS4 (network file storage) protocol — this defines how the operating system handles file read/write operations for a network mounted drive. While NFS4 is fairly robust, the throughput of ANY network drive, even on a high speed AWS data center backbone, is much slower than a local drive such as an EBS volume.
However, the bigger problem comes to light if you happen to choose the default, and pushed as “the mode to use” by Amazon, EFS throughput mode known as “Burst mode”.
Internet enabled voting is a must IMO. Many that are afraid of the security risks and remote hacking have a very shallow, if any, understanding of the risks involved.
To claim physical (paper) voting is more secure is absurd. Every country that has used that system, including ours, has encountered fraud in some form.
Maybe this is the perfect catalyst for getting our Internet providers to finally enable IPV6. It would make external attacks a couple orders of magnitude more difficult. Not too mention providing direct 1:1 accountability to track every single device used to vote.