All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
As I was doing my deep dive into an IoT camera, a question came up: why does it matter? Sure, any given device might not be secure, but how does that affect employees or our business?
I’m glad you asked!1. Consumer Routers Are Mostly Garbage
Every home internet connection needs a router and some sort of WiFi network. Otherwise, you’re stuck connecting a single device directly to a cable or DSL modem. Unfortunately, most routers have poor security. The CIA has used home router exploits for at least the past 10 years, and odds are good that non-state actors have been too.
- In general, router security is not a selling point, and the lowest-cost routers are the bulk of the market.
- In order to reduce costs, routers usually use older hardware, WiFi chipsets, and ship with Linux. Since the WiFi drivers are often proprietary and out of the kernel tree, even new devices often ship with an ancient version of Linux. That means that your shiny new router (like the recently released Netgear Nighthawk X10) might ship with a kernel from half a decade ago (according to their GPL code release), missing security improvements since then .
- Very few routers offer automatic updates, so even if manufacturers provided comprehensive security updates they would be ignored by the majority of users.
Sometimes, ISPs give or require home users to use routers provided by them, but they have a poor security track record too. In one instance, a router’s DNS settings could be changed, which would let an attacker redirect traffic to servers of their choice.
Why does this matter? In the end, every single bit of internet traffic goes through your router. If an attacker wants to sniff unencrypted traffic, or attempt to downgrade an encrypted connection, this is the place to do it. Your router should be the most secure device on your network, and instead it’s likely the least secure.Our security team recommends to our employees that their overall security starts with their router.
Try to find devices that offer some sort of automatic update and vendors with a good security record. Consider running an open-source router distribution like pfSense, OPNSense, or OpenWRT that makes it easier to keep up to date. Don’t trust your ISP’s equipment unless they’ve shown they are security conscious.2. Home Networks Have Untrusted Devices
If you have a family at home, odds are you’ve given out your WiFi password. After all, you want kids or guests to be able to access WiFi when they need it. But, have you checked those devices to make sure they’re secure? What are the odds that the laptop your kid’s friend brought over to do homework on has some sort of virus on it? Or, that your babysitter’s old unpatched Galaxy phone is infected with a rootkit? You wouldn’t want these devices plugged in at work, and they shouldn’t be on the same network as your work devices either.The easiest way to handle untrusted devices is to use the “guest network” functionality in your WiFi access point.
Usually, these networks limit traffic between devices, and only allow them to communicate out to the internet. Many access points allow multiple guest networks, so you could separate “mostly trusted” devices from “patient zero infection vector” devices .3. Security Includes Privacy Too
Imagine that after reading the previous point, you go out and setup a perfectly secure and segmented network. Then, a grandparent gives your kids internet connected teddy bears. Great! You put them on the kid’s WiFi network, and rest knowing that your work data is secure.
Until you realize that they left the toy in your office, and you had conference calls with enterprise clients talking about unannounced products, and that the teddy bear was uploading all recorded audio to an unprotected database.
One of the best parts of working from home is being able to create your own space, or multiple spaces to work in. But, in sharing that home, you open yourself up to potential leaks and vulnerabilities. Of course, in the above hypothetical, the odds of an attacker combing through those voice recordings and finding something useful is small. Then again, what if your contracts require client notification in the case of a suspected breach? Even if the real risk is small, the impact on your reputation could be huge.Treat your client data like your personal photo collection, your home budget, or your medical records.
Think not just about ways you can be directly hacked, but about ways data can be intercepted, and how you can limit those vulnerabilities.4. IoT Devices Punch Holes By Design
What is it that every IoT device markets as being the most important feature? Usually, it’s some combination of “cloud,” “app,” and “integration.” If it’s a security camera, the marketing will almost always show some picture of a person out travelling, viewing their kids at home. Door locks alerting you when they are unlocked. A thermostat detecting you driving home, and starting to warm up the house.
In other words, these devices need to have a two-way connection to the Internet—they need to send statuses out to the cloud, and receive commands from your phone or the cloud. That means they’ve opened a hole through your router.
It might be a surprise, but while your home router is probably the most important security device on your network, they all include methods for devices and applications to open up your network to the Internet—without any sort of authorization or controls. uPNP and NAT-PMP are the most common protocols for this. STUN is also used as it works even if uPNP and NAT-PMP are disabled on the router.
No matter how they do it, IoT devices for the home place accessibility over security almost universally. That is a fundamental conflict with many agency (and customer!) priorities, making every single IoT device employees own a potential threat to your operations.Prefer “smart” devices that work without an internet connection, or use a separate network entirely such as Zigbee.
As well, disable uPNP and NAT-PMP on your routers, and use a stateful firewall instead of relying on NAT to protect your home network.5. Hacked Devices Put Private Networks At Risk
I’m sure many are thinking, “it’s OK, we require the use of a VPN for all of our work.” That’s fine, and certainly a good practice. It stops direct attacks on your private services from the broader Internet, and ensures employee’s connections can’t be sniffed by malicious devices at home.
Or… does it?
Ask yourself: how many VPNs do you have for client work that use self-signed SSL certificates? How many intranet sites require you to click through and ignore HTTPS warnings in your browser? How many of your critical domains use DNSSEC? How many client devices are validating DNSSEC signatures?
What prevents a hacked “smart” electrical plug from hacking a router in turn, and then redirecting traffic from there? How likely are you to notice that the self-signed VPN certificate has changed?
VPNs are great, but they’re only a start. The connection process is still vulnerable to attack by other devices on the network. Ignore best practices in but one layer of the system, and the whole thing becomes vulnerable. All because that WiFi thermostat was on sale for $29.99.Don’t rely on VPNs as the sole method to protect your company.
Make sure all employees are aware of the risks that come with using work resources and VPNs at home, and that they understand the trust that comes with VPN access.6. Agencies Are Great Targets
How many different clients do you work with today? How many have you worked with in the last year? How many access credentials do you have “on ice,” that are active, but not in daily use?
Imagine a hacker is trying to gain access to an enterprise’s network or data. What’s easier: hacking their well monitored and well-staffed corporate networks, or hacking a remote employee or agency protected by a mere consumer-grade router? And, if the target is not a specific company, but simply a company in a given vertical, agencies are perfect victims. At least, if the agency doesn’t consider security in a holistic and comprehensive manner.Don’t fall into the “we’re too small to hack” trap.
Just as smart devices might be used as a vector to hack your laptop, your small agency might be used as a vector to hack a client.7. Enterprises are Great Targets, Too
Ok, so agencies are great targets for hacks, and we should all just give up.
Well, enterprises don’t always have great security either. I’ve worked with companies with hundreds of thousands of employees, who don’t have SSL on a single intranet site. I’ve also seen companies with APIs that have zero authentication, allowing unauthenticated POST requests to modify business critical data. Or, AWS root keys left in cleartext on company wikis or source code.
As agencies, we’re often hired to set the standard for our client’s teams. That means, when we see an SSL certificate fail, we click cancel and call support instead of forcing it through. We use best practices for APIs like request signing instead of plaintext passwords. We change passwords we see posted in Slack, and remind the team to use something like LastPass or GnuPG instead.
But, to do this effectively, we need to have our own security house in order. We need to not just communicate the best practices, but live them ourselves, so we can know we aren’t leading clients towards an unusable and burdensome set of restrictions.Bake good security practices into how you work with clients.
Follow the same security practices with your own teams, so when you make suggestions to clients you come from a place of experience.8. The Internet Is A Community
In the Drupal world, we’re always telling our clients how being a part of the community is the best way to build sites efficiently. A hacked web server doesn’t just affect our client’s and their users—it affects other, innocent users online. A server taking part in a DDoS might not be noticeable at all to the server admins—but the other end of the attack is having a very bad day.
For digital agencies, our livelihoods depend on a functional and reliable internet. If we ignore security in the name of hitting our next deadline, we hurt the commons we all need to thrive.Think about the downstream effects of a security breach.
Remember that the bulk of hacks these days aren’t about data exfiltration, but computing resources for DDoS attacks or spam. Be aware of the common resources your company has (hosting, email, domains, websites) that may be valuable to attackers in their own right simply because they can be used in other attacks.Technical Notes
 I compared their source to the upstream LTS 3.10.105 release, which showed that CVE-2016-3070 was patched in August in commit af110cc4b24250faafd4f3b9879cf51e350d7799. It doesn’t appear that fix is shipped with the Netgear router. It’s possible the fix isn’t required for this hardware, but do we really trust that they’ve done their due diligence for every single patch? It’s a much better practice to apply all security patches, instead of selectively deploying them. Even if they’ve backported security patches, the Linux kernel itself has added significant security features since then, such as Live patching, write-only protection to data, and merges from the grsecurity project.
 Another solution is to implement multiple “virtual networks” or VLANs with firewall rules to control traffic. Combined with a managed switch and appropriate access points, you can “tag” traffic to different networks. For example, let’s say you have a Chromecast you want to be able to use from both your work laptop and from phones guests have. A VLAN would let you create three networks (devices, work, and guest), and add rules that allow traffic from “work” and “guest to send traffic to “devices”, but not the other way around. Likewise, “work” could open a connection to a “guest” device, but “guests” wouldn’t initiate a connection to a “work” device. Obviously this requires some learning to set up, but is great for flexibility if you have more than just the simple “guest” scenario.
Header image is Broken Rusty Lock: Security (grunge) by Nick Carter.
This integrates the revisioning module with entitycache.Problems
There had been three problems:
- a) Entities loaded directly as revisions (even though the current revision is the live revision) and hence having no entity caching at all.
- b) Entities loaded as revisions, but that need the draft / latest revision.
- c) The whole cache was cleared by revisioning module by calling node_load($id, NULL, TRUE), which led to entity_load() clearing the whole persistent cache when any node was saved.
I always look forward to DrupalCon each year for a number of reasons. One of the reasons chief among them is the refreshing excitement of being immersed in the community. I always enjoy the encouragement and guidance our community offers. A number of the conversations I had during DrupalCon offered this same encouragement and guidance to push forward with a public release of a module I've been working on and maintaining privately. Following up on this advice, I'd like to proudly introduce my new module: YAML Content.
Provides client-side search within content panes for Panels Add content modal.
Unlike Quick search found at latest versions of Panels, the search works across all categories.Requirements
Development sponsored by Invotra.
I recently joined PreviousNext and was soon getting acquainted with contributing to Drupal core and contrib projects. A big part of the contribution workflow is working with patch files in the issue queue, so I wrote this post to help anyone who wants to know about patching in Drupal.
ZeroHammer is a simple comment moderation system that analyzes comments for spam domains, and auto-moderates offending posts. Here's a short list of what you can do with this module:
- Auto-block users that post spam comments.
- Replace spam comments with custom messages, for the lulz.
It is the sixth week of Google Summer of Code 2017. We were engaged in creating an abstraction for using ml-engine with Drupal. The core functions like file upload, ml-engine training jobs, deployment and prediction services etc were created during the first month of GSoC. Please refer the link for the code. This week started with few basic lessons on tensorflow. I continued the search to find the official collection of pre-trained tensorflow models. It didn't find any new result. I have posted three questions in Stack Overflow. One to find the pre-trained models, streaming data to Google Cloud Storage, and the other to know if ml-engine supports all types of tensorflow models.
To use multiple ml-engine projects simultaneously, we need to create a content entity. We propose to store ml-engine configurations as entity base fields and Tensorflow python code inputs as bundle fields. In the below-shown figure, there are few base fields for training and deployment.
This is the sketch of ml-engine entity. It has three parts. Training part includes determining the fields required for tensorflow code and ml-engine configuration. Users are given the scope to select fields custom to their tensorflow code. Deployment part has base fields to set its configuration. Prediction part is for selecting the prediction output data type.
figure 2 User creates their new projects through this interface. Each project is having its own set of training and deployment jobs.
Fields can be created to match the input requirement of the tensorflow code. The referred Drupal View will be converted to corresponding CSV file. All referenced files will be uploaded to Google Cloud and will be replaced with the URL. This provides a great flexibility on data types by creating an abstraction layer for the input.
The output corresponding to each model can vary depending on the design of the model. To provide an abstraction, we provide the option to select the returned data types for each project. For example, the response will be encoded as an integer if the selected type is an integer. If it is an image, the returned binary will be written to a jpg file and added to Drupal. For classification, the user will be able to select class corresponding to each index. This can provide a good level of abstraction in handling the prediction output. If needed users extend this module to add more data types.
Finally, to do prediction we have to select its field types. Below we have two screenshots showing how we match data to these fields.
figure 6: To map data to a field, we have to go to the node settings and select the ml-engine project. Now go to field settings > edit.
Select the ml-engine prediction input field and we are done. Similar to the option to match prediction input field, this page will have a checkbox to match the prediction output. If checked, predictions made are stored in this field when the node is saved.
In the coming week, we will be working on implementing this design.
Moderation Dashboard provides a per-user dashboard that contains useful blocks related to managing moderated content.
This module is meant as a jumping-off point for administrators to customize the dashboard to fit their content editor's needs. As a result, no update hooks will be provided between releases as users are expected to change the module's default configuration.
Since the dashboard is built entirely with Page Manager and Views, everything you see can be configured via the UI! Feel free to go crazy.
Have you ever wanted to .gitignore a file by branch?
The classic example for me here is versioning the generated styles.css file on master (which is deployed to production) but not on develop (which is used for pull requests).
Versioning the styles.css file can result in merge conflicts or PRs that are just messy.
Here's the script I used.
Read the comments for installation notes.
This module extends core PhpassHashedPassword check method by making an additional check following the CakePHP passwords hash methodology.
You would need it in the case of users migration from CakePHP do Drupal and resetting the passwords is not an option for you.
Sell your goods using PayGate PayHost as a payment gateway.
This blog includes two statements. One from Dries Buytaert, as Drupal Project Lead, and another from Megan Sanicki, as the Executive Director of the Drupal Association and the Drupal Association Board.
We recognize that events and conversations earlier this year surfaced many concerns and needs within the community. One in particular is related to Larry Garfield’s role within Drupal. After several conversations with Larry, and careful consideration, we can now provide an update to this situation, our decisions, and Larry’s role moving forward.
We thank you for your patience while we spent many hours meeting with Larry and outside experts to resolve this matter. We recognize that actions were taken quickly before, which resulted in poor communication, and we wanted to avoid this happening again. We made sure to provide the proper time and attention these conversations needed before releasing this follow-up post.
We know our poor communication in the past led to frustration with us and pain for others. For that, we are sorry. We want to learn from this and improve. We listened to the community’s request to provide more streamlined, clear, and easy-to-follow communication. So, this post includes a statement from Dries Buytaert, as Project Lead, followed by a statement from Megan Sanicki, Executive Director of the Drupal Association.Statement from Dries Buytaert, as Drupal Project Lead
I know there are many people out there still uneasy about where things were left off with regards to Larry's status and uncertainty around why he was asked to leave. I would like to personally clear up these things.
The actions that led me to ask Larry to resign involve a woman who attended Drupal community events with Larry, and was "allowed" to contribute by him. I originally characterized these actions as 'beliefs,' which was inaccurate on my part. To be clear, potential legal and ethical questions were raised by various people, including the Drupal Association lawyers, that this person could be vulnerable and may have been subject to exploitation, which raised the risk of substantial damage to the project.
Based on the legal and ethical risks to the Drupal project caused by Larry’s actions, both the Drupal Association and I needed to take action.
In balancing these questions and this risk, with Larry’s stated desire for privacy, the most obvious solution at the time was to ask him to resign. This was difficult. Larry has been a longtime contributor and colleague, and given the gravity of this situation, I did not communicate as clearly as I should have. When Larry chose not to resign, I took no immediate action with Larry’s role in the community in order to allow more time to better understand the situation and for mediation to occur.
Instead of continuing a dialogue and working towards a solution, Larry chose to end our discussion and share parts of the information surrounding this situation publicly. I understand why Larry blogged, and I support Larry’s — and every community member’s — right to speak out constructively when they disagree with those of us in leadership roles. However Larry’s blogs led people to think that I, and the Drupal Association, doxxed, bullied, and discriminated against him, which we did not. His blog posts led many to think that people who are into kink are not welcome in our community, which is not true. Larry's posts created material disruption to the project and the Association based on incomplete and inaccurate information. Even though Larry saw the negative impact he further inflamed the situation with additional blog posts.
Our current governance model lays out numerous positions that can be held within the project and who has the ability to appoint or remove people from them. Larry’s various roles and who governs them are listed in the table below. Most of Larry’s leadership roles are associated with the Drupal Association, but as project lead, I am responsible for assigning technical leadership positions within the project. Part of my job is to appoint and replace maintainers, to make sure the team functions well; and to make sure the leadership team is effective setting the technical direction of the project as well as collaborating with other members of the Drupal community to achieve our technical vision.
After talking to Larry and consulting other key contributors, I remain steadfast in my decision that it is best for Drupal that Larry should not continue to hold a technical leadership role. I've therefore decided to remove Larry as a core subsystem maintainer and as the PHP-FIG representative for Drupal. Larry will maintain his individual contributor roles which means he can participate in the development of Drupal as a regular member of the community.Statement from Megan Sanicki, Executive Director of the Drupal Association and the Drupal Association Board
As the Executive Director of the Drupal Association a key part of my job is to protect the Drupal Association and the project from risk and harm. The Drupal Association is the steward of two critical drivers for Drupal’s longevity: Drupal.org and DrupalCon. And we are charged with caring for those spaces. Should the sustainability of the Drupal Association’s be impacted, we would no longer be able to maintain Drupal.org, which would have devastating implications for the project.
As Larry stated in his blog post, he was in a relationship with a woman he describes as “acutely autistic” and “mentally handicapped”. They attended Drupal events together where, in Larry’s own words, he “allowed” her to contribute to Drupal. The Drupal Association Board and I learned about this information from other sources as well as from Larry himself before Larry’s blog post was issued.
I was concerned not only about this person’s well-being, but I also had legal concerns about her ability to give informed consent or whether she was being exploited. The Drupal Association recognizes that Larry did not use the accurate medical terms to describe this person and we also recognize that most vulnerable people have the ability to consent. However, in this case, given the information we received about this person, we were concerned that it was possible that she could not consent. I sought input from board members and from professional experts, including legal counsel, who expressed concern that Larry’s action in his leadership roles created possible legal risk to the organization.
I learned about these issues just as the DrupalCon Baltimore sessions were about to be announced, and in order to give myself time to evaluate the risks, I ended Larry’s role as track chair and removed his session for only DrupalCon Baltimore. Making a decision for just one event provided me the time to better understand the situation and how to address the risks and concerns with appropriate counsel and authorities. The Drupal Association can not and should not investigate or adjudicate legal matters. We referred the situation to our legal counsel and followed their advice by removing Larry from leadership roles and we referred the matter to authorities.
Larry's subsequent blog posts harmed the community and had a material impact on the Drupal Association. including membership cancellations from those who believed we doxed, bullied, and discriminated against Larry as well as significant staff disruption. Due to the harm caused, the Drupal Association is removing Larry Garfield from leadership roles that we are responsible for, effective today.
These roles include being a DrupalCon track chair, DrupalCon speaker, member of the Drupal Association Advisory Board, and a member of the Licensing Working Group. Larry will maintain his individual contributor roles that the Drupal Association governs, which includes attending DrupalCon and contributing on Drupal.org using his Drupal.org user profile. It is important to note that Dries recused himself from the Drupal Association board decisions on this matter to avoid as many conflicts of interests as possible.
As long as Larry does not harm or disrupt the project, he will continue to be a member of the community as an individual contributor. However, we reserve the right to remove Larry's individual contributor roles if that is not the case. Also, we recognize that situations can change over time, so the Drupal Association will revisit these decisions in two years.
I recognize that my communication to Larry and with the community did not provide transparency into this situation and I apologize for the pain and confusion that caused. Our advisors told us not to share these details in order to protect all parties pending evaluation from authorities. Also, when Larry shared these details during the appeal process, he asked us to keep them confidential. It is my hope that this statement provides the clarity that many have been requesting.What We Have Learned
Dries, Megan, and the Drupal Association Board of Directors hope that the community can stay focused on healing and the needed discussions about ways we can improve our community.
It is clear that we were unprepared for a challenge of this complexity. We struggled to move forward in a careful, timely, and clear fashion. We need to provide the community with clarity and understanding whenever possible. Many ideas are surfacing from the recent community discussions and we are looking at them to identify other ways to be better prepared for future challenges.
Another key take-away from this incident is that everyone in our community needs to be able to understand the answers to these questions:
- What is expected of me by the community?
- What can I expect from the community?
- How is Drupal governed?
- How can I participate in governance?
The best way for the community to get these answers is by working together to refine our community governance model. We support this work and we are eager to help the community achieve its vision.
We believe this community is a role model for the world on how to be a great open source community. Even at its messiest, we believe this community is strong and has much to share with other projects and communities. We consistently come together to solve hard problems. Even now, we are coming together to redefine our community governance and we are confident Drupal will become stronger because of it.
If you want to be part of creating a stronger and healthier community for the future, we encourage you to get involved in the discussions taking place on Drupal.org. Plus, you can go here to learn about the findings from the recent Community Discussions that were mediated by Whitney Hess along with the next steps that the community wants to take in evolving governance. We hope you will join this effort.Governance of Roles
As mentioned in Dries' statement, these are Larry's roles and who governs each one.Larry Garfield’s Role Role Type Who governs this role Technical Leader (Core Maintainer & PHP FIG) Leadership Role Project Lead DrupalCon Presenter Leadership Role Drupal Association DrupalCon Program Team / Track Chair Leadership Role Drupal Association Licensing Working Group Leadership Role Drupal Association Drupal Association Advisory Board Leadership Role Drupal Association DrupalCon Attendee Individual Contributor - subject to DrupalCon Code of Conduct Drupal Association Drupal.org user profile Individual Contributor - subject to Terms of Service Drupal Association
We are excited to share the news that we have a new addition to the Drupal Association team - thanks to Srijan.
Last year, we announced the reduction of our team size in order to make the Drupal Association more sustainable. In response, Srijan, a long time Drupal Association Supporter, hired Piyush Jain to work on marketing initiatives and has donated 100% of his time to the Drupal Association.
It’s an incredibly generous contribution and we are extremely grateful for Srijan’s support.Welcome Piyush
So, please meet Piyush. (In all honesty, he’s been on our team since January, but we’ve been a little slow in our introduction.) He has several years experience in the Drupal community from working at Srijan as well as helping organize Drupal Camp Delhi. We are fortunate to have someone talented, who understands the Drupal culture and is familiar with our programs.
Piyush hit the ground running, helping us promote DrupalCon Baltimore. Now he is working on DrupalCon Vienna, Drupal.org case studies, and Drupal Jobs. Piyush offers a great new perspective and is a valuable addition to the team.
Thank you Srijan and welcome Piyush!