Home Blog Page 462

How Containers and Microservices Change Security

Cloud-native applications and infrastructure require a radically different approach to security. Keep these best practices in mind.

Today organizations large and small are exploring the adoption of cloud-native software technologies. “Cloud-native” refers to an approach that packages software within standardized units called containers, arranges those units into microservices that interface with each other to form applications, and ensures that running applications are fully automated for greater speed, agility, and scalability.

Because this approach fundamentally changes how software is built, deployed, and run, it also fundamentally changes how software needs to be protected. Cloud-native applications and infrastructure create several new challenges for security professionals, who will need to establish new security programs that support their organization’s use of cloud-native technologies.

Read more at InfoWorld

Why Use Docker with R? A DevOps Perspective

There have been several blog posts going around about why one would use Docker with R.
In this post I’ll try to add a DevOps point of view and explain how containerizing
R is used in the context of the OpenCPU system for building and deploying R servers.

1: Easy Development

The flagship of the OpenCPU system is the OpenCPU server:
a mature and powerful Linux stack for embedding R in systems and applications.

Read more at R-bloggers

 

A Chat with Chef about the DevOps Movement and Habitat Builder

Last week at our annual user conference, Node.js Interactive, we announced several new members to the Node.js Foundation. One of the members that joined is Chef. Chef works with more than a thousand companies around the world to deliver their vision of digital transformation.

We sat down with the team at Chef to talk about how Node.js fits within the DevOps movement, why they joined the Node.js Foundation, and also about a new offering from the group called Habitat Builder.

Read more at Node.js

 

Tips to Secure Your Network in the Wake of KRACK

The KRACK attacks vulnerability is now more than 48 hours old and has been discussed in detail on a number of technology-related sites, so I won’t repeat the technical details of the attack here. To summarize:

  • A flaw in the WPA2 wireless handshake protocol allows attackers to sniff or manipulate the traffic between your device and the wi-fi access point.

  • It is particularly bad for Linux and Android devices, due either to ambiguous wording in the WPA2 standard or to misunderstanding during its implementation. Effectively, until the underlying OS is patched, the vulnerability allows attackers to force all wireless traffic to happen without any encryption at all.

  • This vulnerability can be patched on the client, so the sky hasn’t fallen and the WPA2 wireless encryption standard is not obsoleted in the same sense that the WEP standard is (do NOT “fix” this problem by switching to WEP).

  • Most popular Linux distributions are already shipping updates that fix this vulnerability on the client, so apply your updates dutifully.

  • Android will be shipping fixes for this vulnerability Very Soon. If your device is receiving Android security patches, you will receive a fix before long. If your device is no longer receiving such updates, then this particular vulnerability is merely another reason why you should stop using old, unsupported Android devices.

That said, from my perspective, Wi-Fi is merely another link in the chain of untrusted infrastructure and we should altogether avoid treating it as a trusted communication channel.

Wi-Fi as untrusted infrastructure

If you’re reading this article from your laptop or your mobile device, then your chain of communication probably looks something like this:

Blank Network Diagram - Basics.png

The KRACK attack targets the link between your device and the Wi-Fi access point, which is probably a router either in your home, your office, your neighborhood library, or your favorite cafe.

Blank Network Diagram - Where Kracks happen (1).png

In reality, this diagram should look something like this:

Blank Network Diagram - Everywhere (1).png

Wi-Fi is merely the first link in a long chain of communication happening over channels that we should not trust. If I were to guess, the Wi-Fi router you’re using has probably not received a security update since the day it got put together. Worse, it probably came with default or easily guessable administrative credentials that were never changed. Unless you set up and configured that router yourself and you can remember the last time you updated its firmware, you should assume that it is now controlled by someone else and cannot be trusted.

Past the Wi-Fi router, we enter the zone of generally distrusting the infrastructure at large — depending on your general paranoia levels. Here we have upstream ISPs and providers, many of whom have been caught monitoring, altering, analyzing, and selling our personal traffic in an attempt to make additional money off our browsing habits. Often their own security patching schedules leave a lot to be desired and end up exposing our traffic to malicious eyes.

On the Internet at large, we have to worry about powerful state-level actors with ability to manipulate core networking protocols in order to carry out mass surveillance programs or perform state-level traffic filtering.

HTTPS Protocol

Thankfully, we have a solution to the problem of secure communication over untrusted medium, and we use it every day — the HTTPS protocol encrypts our Internet traffic point-to-point and ensures that we can trust that the sites we communicate with are who they say they are.

The Linux Foundation initiatives like Let’s Encrypt make it easy for site owners worldwide to offer end-to-end encryption that helps ensure that any compromised equipment between our personal devices and the websites we are trying to access does not matter.

Blank Network Diagram - HTTPS (1).png

Well… almost does not matter.

DNS remains a problem

Even if we dutifully use HTTPS to create a trusted communication channel, there is still a chance that an attacker with access to our Wi-Fi router or someone who can alter our Wi-Fi traffic — as is the case with KRACK — can trick us into communicating with the wrong website. They can do so by taking advantage of the fact that we still greatly rely on DNS — an unencrypted, easily spoofed protocol from the 1980s.

Blank Network Diagram - LOL DNS.png

DNS is a system that translates human-friendly domain names like “linux.com” into IP addresses that computers can use to communicate with each other. To translate a domain name into an IP address, the computer would query the resolver software — usually running on the Wi-Fi router or on the system itself. The resolver would then query a distributed network of “root” nameservers to figure out which system on the Internet has what is called “authoritative” information about what IP address corresponds to the “linux.com” domain name.

The trouble is, all this communication happens over unauthenticated, easily spoofable, cleartext protocols, and responses can be easily altered by attackers to make the query return incorrect data. If someone manages to spoof a DNS query and return the wrong IP address, they can manipulate where our system ends up sending the HTTP request.

Fortunately, HTTPS has a lot of built-in protection to make sure that it is not easy for someone to pretend to be another site. The TLS certificate on the malicious server must match the DNS name you are requesting — and be issued by a reputable Certificate Authority recognized by your browser. If that is not the case, the browser will show a big warning that the host you are trying to communicate with is not who they say they are. If you see such warning, please be extremely cautious before choosing to override it, as you could be giving away your secrets to people who will use them against you.

If the attackers have full control of the router, they can prevent your connection from using HTTPS in the first place, by intercepting the response from the server that instructs your browser to set up a secure connection (this is called “the SSL strip attack”). To help protect you from this attack, sites may add a special response header telling your browser to always use HTTPS when communicating with them in the future, but this only works after your first visit. For some very popular sites, browsers now include a hardcoded list of domains that should always be accessed over HTTPS even on the first visit.

The solution to DNS spoofing exists and is called DNSSEC, but it has seen very slow adoption due to important hurdles — real and perceived. Until DNSSEC is used universally, we must assume that DNS information we receive cannot be fully trusted.

Use VPN to solve the last-mile security problem

So, if you cannot trust Wi-Fi — and/or the wireless router in the basement that is probably older than most of your pets — what can be done to ensure the integrity of the “last-mile” communication, the one that happens between your device and the Internet at large?

One acceptable solution is to use a reputable VPN provider that will establish a secure communication link between your system and their infrastructure. The hope here is that they pay closer attention to security than your router vendor and your immediate Internet provider, so they are in a better position to assure that your traffic is protected from being sniffed or spoofed by malicious parties. Using VPN on all your workstations and mobile devices ensures that vulnerabilities like KRACK attacks or insecure routers do not affect the integrity of your communication with the outside world.

Blank Network Diagram - VPN.png

The important caveat here is that when choosing a VPN provider you must be reasonably assured of their trustworthiness; otherwise, you’re simply trading one set of malicious actors for another. Stay far away from anything offering “free VPN,” as they are probably making money by spying on you and selling your traffic to marketing firms. This site is a good resource that would allow you to compare various VPN providers to see how they stack against each other.

Not all of your devices need to have VPN installed on them, but the ones that you use daily to access sites with your private personal information — and especially anything with access to your money and your identity (government, banking sites, social networking, etc.) must be secured. VPN is not a panacea against all network-level vulnerabilities, but it will definitely help protect you when you’re stuck using unsecured Wi-Fi at the airport, or the next time a KRACK-like vulnerability is discovered.

Learn more in “A SysAdmin’s Essential Guide to Linux Workstation Security” from The Linux Foundation. Download the free ebook and checklist now!

Blockchain and the Web Are Coming Together, Says Berners-Lee

Sir Tim Berners-Lee is a famous computer scientist and academic who invented the World Wide Web in 1989—so when he talks about new technologies it’s worth paying attention.

Today, one of the topics on his mind is blockchain, a revolutionary way of creating permanent, tamper-proof records across a disparate network of computers.

Blockchain is most famously associated with the digital currency bitcoin but the technology is increasingly being used for record keeping by banks and retailers. It will also come to be used by more ordinary citizens in the near future, says Berners-Lee.

Read more at Fortune

Salesforce Offers 5 Tips for Open Source Program Success

Salesforce learned early on that open source projects stay healthy when they have a diverse community of stakeholders that have an interest in making the software succeed.

Apache Phoenix started at Salesforce as its own open source Phoenix project. But it didn’t find success until people from outside Salesforce also got invested and the project no longer depended on the needs and desires of one company. In a true community effort, people from other companies joined in and said, ‘this is useful for us and we want to contribute,’” says Ian Varley, a Software Architect at Salesforce who recently led the open source program there. In the end, this diverse community is what allowed it to become an Apache project and incorporate new features that the company’s own engineers could never have dreamed up.

Read more at The Linux Foundation

How to Implement Cloud-Native Computing with Kubernetes

Kubernetes and containers can speed up the development process while minimizing programmer and system administration costs, say representatives of the Open Container Initiative and the Cloud Native Computing Foundation. To take advantage of Kubernetes and its related tools to run a cloud-native architecture, start with unappreciated Kubernetes features like namespaces.

Kubernetes is far more than a cloud-container manager. As Steve Pousty, Red Hat’s lead developer advocate for OpenShift, explained in a presentation at the Linux Foundation’s Open Source Summit, Kubernetes serves as a “common operating plane for cloud-native computing using containers.”

What does Pousty mean by that? Let’s review the basics.

Read more at HPE Insights

Image Processing on Linux

I’ve covered several scientific packages in this space that generate nice graphical representations of your data and work, but I’ve not gone in the other direction much. So in this article, I cover a popular image processing package called ImageJ. Specifically, I am looking at Fiji, an instance of ImageJ bundled with a set of plugins that are useful for scientific image processing.

The name Fiji is a recursive acronym, much like GNU. It stands for “Fiji Is Just ImageJ”. ImageJ is a useful tool for analyzing images in scientific research—for example, you may use it for classifying tree types in a landscape from aerial photography. ImageJ can do that type categorization. It’s built with a plugin architecture, and a very extensive collection of plugins is available to increase the available functionality.

The first step is to install ImageJ (or Fiji). Most distributions will have a package available for ImageJ. If you wish, you can install it that way and then install the individual plugins you need for your research.

Read more at Linux Journal

Proxy Models in Container Environments

Inline, side-arm, reverse, and forward. These used to be the terms we used to describe the architectural placement of proxies in the network.

Today, containers use some of the same terminology, but they are introducing new ones. That’s an opportunity for me to extemporaneously expound* on my favorite of all topics: the proxy.

One of the primary drivers of cloud (once we all got past the pipedream of cost containment) has been scalability. Scale has challenged agility (and sometimes won) in various surveys over the past five years as the number one benefit organizations seek by deploying apps in cloud computing environments.

Read more at DZone

Watch Keila Banks, Mitchell Hashimoto, and Jan Kizska Live at Open Source Summit Europe

Join 2000 technologists and community members next week as they convene at Open Source Summit Europe and Embedded Linux Conference Europe in Prague. If you can’t be there in person, you can still take part, as The Linux Foundation is pleased to offer free live video streaming of all keynote sessions on Monday, Oct. 23 through Wednesday, Oct. 25, 2017.  So, you can watch the event keynotes presented by Google, Intel, and VMware, among others.

The livestream will begin on Monday, Oct. 23 at 9 a.m. CEST (Central European Summer Time). Sign up now! You can also follow our live event updates on Twitter with #OSSummit.

Read more at The Linux Foundation