Aggregator

YubiKey 5 Series Launched, Google Chrome's Recent Questionable Privacy Practice, PlayOnLinux Alpha Version 5 Released, Android Turns Ten, and Fedora 29 Atomic and Cloud Test Day

4 hours 38 minutes ago

News briefs September 24, 2018.

Yubico announced the launch of the YubiKey 5 series this morning, which are the first multi-protocol security keys to support FIDO2/WebAuthn and allow you to replace "weak password-based authentication with strong hardware-based authentication". You can purchase them here for $45.

Google Chrome recently has begun automatically signing your browser in to your Google account for you every time you log in to a Google property, such as Gmail, without asking and without notification. See Matthew Green's blog post for more information on the huge privacy implications of this new practice.

PlayOnLinux released the alpha version of PlayOnLinux and PlayOnMac 5 ("Phoencis") over the weekend. The interface has been completely redesigned and is now decentralized, so if the website has issues, the program will still work. In addition, the script is now available on GitHub. This alpha version supports 135 games and apps. See the full list here.

Android celebrated its 10th birthday this weekend. See TechRadar, Engadget and TechCrunch for different takes on Android's history.

Fedora 29 Atomic and Fedora 29 Cloud development is wrapping up, and they now provide the latest versions of packages in Fedora 29, including all new features and bug fixes. Fedora Atomic Working Group and Cloud SIG are organizing a Test Day, Monday, October 1st. See the wiki page if you're interested in participating.

News Security YubiKey Google Chrome Privacy PlayOnLinux gaming Android Fedora
Jill Franklin

What is Istio?

5 hours 20 minutes ago

Learn how a service mesh can help to manage your microservice deployments.

ModSecurity and nginx

6 hours 50 minutes ago
by Elliot Cooper

nginx is the web server that's replacing Apache in more and more of the world's websites. Until now, nginx has not been able to benefit from the security ModSecurity provides. Here's how to install ModSecurity and get it working with nginx.

Earlier this year the popular open-source web application firewall, ModSecurity, released version 3 of its software. Version 3 is a significant departure from the earlier versions, because it's now modularized. Before version 3, ModSecurity worked only with the Apache web server as a dependent module, so there was no way for other HTTP applications to utilize ModSecurity. Now the core functionality of ModSecurity, the HTTP filtering engine, exists as a standalone library, libModSecurity, and it can be integrated into any other application via a "connector". A connector is a small piece of code that allows any application to access libModSecurity.

A Web Application Firewall (WAF) is a type of firewall for HTTP requests. A standard firewall inspects data packets as they arrive and leave a network interface and compares the properties of the packets against a list of rules. The rules dictate whether the firewall will allow the packet to pass or get blocked.

ModSecurity performs the same task as a standard firewall, but instead of looking at data packets, it inspects HTTP traffic as it arrives at the server. When an HTTP request arrives at the server, it's first routed through ModSecurity before it's routed on to the destination application, such as Apache2 or nginx. ModSecurity compares the inbound HTTP request against a list of rules. These rules define the form of a malicious or harmful request, so if the incoming request matches a rule, ModSecurity blocks the request from reaching the destination application where it may cause harm.

The following example demonstrates how ModSecurity protects a WordPress site. The following HTTP request is a non-malicious request for the index.php file as it appears in Apache2's log files:

GET /index.php HTTP/1.1

This request does not match any rules, so ModSecurity allows it onto the web server.

WordPress keeps much of its secret information, such as the database password, in a file called wp-config.php, which is located in the same directory as the index.php file. A careless system administrator may leave this important file unprotected, which means a web server like Apache or nginx happily will serve it. This is because they will serve any file that is not protected by specific configuration. This means that the following malicious request:

GET /wp-config.php HTTP/1.1

will be served by Apache to whomever requests it.

Go to Full Article
Elliot Cooper