Month: April 2017

Open Hub Scheduled Downtime

There are two periods of scheduled downtime for the Open Hub over the next week or so.

The first will start tomorrow, Friday, April 28, when Black Duck’s IT team starts a network update project in our production data center. There may be a series of service interruptions through this weekend. We do not expect that the Open Hub will be down for any long period of time should it be unavailable, although these service interruptions will be unpredictable.

The other service interruption will start on Friday, May 5 at 8 PM EDT. We will be taking the Open Hub offline at this time in order to perform a significant architecture upgrade. Unfortunately, this work cannot be done during the IT work window because the network upgrade will mean, by definition, that the network and some systems will be unavailable.

We’re really excited by this architecture upgrade, which we’re calling the FIS – OH Database Split (FODS) project.  This work is separating our back end that provides the Fetch, Import, and SLOC operations from the Analysis and UI operations. This is the culmination of a significant amount of work over more than a year as we took incremental steps to mitigate production risk, expand our capabilities and scalability, and improve our website performance. To do this, we need to pull the site offline to make a backup, restore it to two systems, and then run a series of scripts to update the schemas for the new two database architecture, then all the applications need to be deployed and verified before we bring the entire set of systems back online. We expect that all this work will take the majority of the weekend and the Open Hub will be unavailable throughout this work.

As always, thank you so very much for being a member of the Open Source Software community and a part of the Open Hub.

Uirouter Scoped Packages

Scoped NPM packages

In March of 2017, NPM started offering free orgs (Thanks, npm loves you, we love you too!)

We’re taking advantage of the free org feature to publish scoped packages.
We created the @uirouter org and are in the process of moving all our published packages to scoped pakages.

How to use scoped packages

In your package.json, simply replace the old npm package with the scoped @uirouter package.
For example, if you currently depend on angular-ui-router and ui-router-visualizer:

  "dependencies": {
    "angular-ui-router": "latest",
    "ui-router-visualizer": "latest",

replace the package name with the scoped @uirouter package:

  "dependencies": {
    "@uirouter/angularjs": "latest",
    "@uirouter/visualizer": "latest",

Old and new (scoped) package names

This table shows the previous npm package names, and the new scoped package names

Package Old package Scoped package
UI-Router for AngularJS (1.x) angular-ui-router @uirouter/angularjs
UI-Router for Angular (2.x and higher) ui-router-ng2 @uirouter/angular
UI-Router for React ui-router-react @uirouter/react
UI-Router Visualizer ui-router-visualizer @uirouter/visualizer
UI-Router Core ui-router-core @uirouter/core
UI-Router Reactive Extensions ui-router-rx @uirouter/rx
UI-Router ng1-to-ng2 (hybrid support) ui-router-ng1-to-ng2 @uirouter/angular-hybrid
Sticky States plugin ui-router-sticky-states @uirouter/sticky-states
Creating Servers/Devices using a FQDN

Creating Servers/Devices using a FQDN

In the version 3.10 release of our cloud platform, we introduced support for creating back-end devices (servers) using a Fully Qualified Domain Name (FQDN) instead of an IP address. While it is always best to use an IP address instead of a domain name, there are some instances where a FQDN is the only option, for instance in order to direct traffic to an AWS Elastic Load Balancer.

Creating a new device with a FQDN is pretty straightforward. On the left navigation of the Configuration Builder, simply click on the link to Create New Server, as shown below.

create new server or device

In the dialog box that opens, you can now choose to use a FQDN instead of an IP, as shown in the image below:

FQDN device

When you save your device, nothing happens initially. We don’t even try to resolve the FQDN to an IP until you add your first port. But when you do add a port, we will resolve DNS and route traffic to the resolved IP accordingly, whether it is an IPv4 address or IPv6 address. Every time we begin sending traffic to a device after a short period of inactivity, or every 15 seconds (whichever is sooner) we will resolve the DNS again to ensure that the IP address we have is still accurate.

A few more important notes:

  • Use an IP address if you can because it is more reliable. a FQDN relies on DNS, and if for any reason authoritative DNS for your FQDN is down, we will be unable to resolve the IP and send traffic. If you can remove DNS as a point of failure, we highly recommend it simply as a best practice.
  • The FQDN must resolve to a single IP address. If it resolves to more than one, it will not work, or it may work but one of the IPs will be selected arbitrarily.
  • You can change a device from FQDN to IP and vice-versa at any time by simply editing it in the server dialog.
  • This is not a masking feature. That is, we do not proxy traffic to the FQDN like a URL. We use the FQDN to determine what the current IP address is.

The post Creating Servers/Devices using a FQDN appeared first on Total Uptime®.

PHP 7.1 Now Available

PHP 7.1 Now Available

Php 7.1If you are one of our customers that uses our Advanced Hosting Platform, you’ll be pleased to know Register4Less has now added PHP version 7.1.   PHP is one of the most popular programming languages used on the web today.  Sites like Facebook, WordPress, Twitter and Wikipedia all run using PHP.

The cPanel default (and native) version of PHP is 5.6.  Switching to version 7.1 should make your website load more quickly, thanks to the optimizations that have been made in 7.1.

To make the switch for your website, do the following:

  • Log in on for your domain that’s using the advanced hosting.
  • Open up the cPanel (Paid Hosting > Manage Advanced Hosting)
  • In the Software section, look for “Select PHP Version” and click the link or icon.
  • You may want to note the current version you are using in case you need to revert if your website has problems with PHP 7.1.  It’s probably 5.6 though.
  • From the drop down menu, select 7.1 and click the Set as Current button.
  • Click on “Use Defaults” at the bottom of the page to use defaults PHP modules.

You’ll want to test your site to make sure everything is functioning correctly.  For WordPress sites, some plugins are not yet compatible with PHPp 7.1, so you may want to try 7.0 if things are not working correctly, or revert back to the version you took note of earlier.

Web Application Firewall Quick-Start Guide

Total Uptime’s Web Application Firewall (WAF) is an extremely powerful tool to protect web applications at the edge of the Internet as opposed to right inside your datacenter. The WAF shields your network and applications from the ever increasing number of application-layer attacks and can also aid with compliance, like PCI, by helping to prevent information disclosure.

A common request we receive is: “Where do I start with configuring the many options in the WAF?”  We’ve developed this quick-start guide. All of the settings below will provide immediate protection, but will not have adverse affects.

  1. Deny URL. If you have any directories on your site that you wish to protect from public access, this is a good one to activate. For example, with a WordPress site, do you really want anyone on the Internet to reach your /wp-admin/ directory? To block this directory, create a new URL entry and set the Deny URL to /wp-admin(/.*)?$  This will block all access to that directory and anything deeper as well. Create as many entries as needed to block the various directories or even specific pages you want to protect.
  2. Cookie Consistency. This check examines cookies returned by users to verify that they match the cookies that your website set for that user. If a modified cookie is found, it is stripped from the request before the request is forwarded to the web server. Simply enable this feature for protection. No advanced configuration is needed for most clients.
  3. Buffer Overflow. This check prevents attacks against insecure operating-system or web-server software that can crash or behave unpredictably when it receives a data string that is larger than it can handle. Proper programming techniques prevent buffer overflows by checking incoming data and either rejecting or truncating overly long strings. Many programs, however, do not check all incoming data and are therefore vulnerable to buffer overflows. This setting is also easy to check and forget since we’ve configured the advanced settings to reasonable default values already.
  4. Credit card. This check prevents unwanted information disclosure of cardholder data. Are you PCI compliant, or do you need to be? This setting is a huge help. Check the box and under the advanced tab, choose which credit cards to block and whether you want to X them out or simply stop the page from loading. This feature is an easy way to prevent a data leak.
  5. CSRF Form Tagging. The Cross Site Request Forgery (CSRF) Form Tagging check tags each web form sent by a protected web site to users with a unique and unpredictable FormID, and then examines the web forms returned by users to ensure that the supplied FormID is correct. This check protects against cross-site request forgery attacks. This check applies only to HTML requests that contain a web form, with or without data. It does not apply to XML requests.The CSRF Form Tagging check prevents attackers from using their own web forms to send high volume form responses with data to your protected web sites. This check requires little configuration. Simply check the box to automatically enable this protection.
  6. HTML Cross-Site Scripting (XSS). To prevent misuse of the scripts on your protected web sites to breach security, the HTML Cross-Site Scripting check blocks scripts that violate the same origin rule, which states that scripts should not access or modify content on any server but the server on which they are located. Any script that violates the same origin rule is called a cross-site script, and the practice of using scripts to access or modify content on another server is called cross-site scripting. The reason cross-site scripting is a security issue is that a web server that allows cross-site scripting can be attacked with a script that is not on that web server, but on a different web server, such as one owned and controlled by the attacker. Caution: Many companies have a large installed base of JavaScript-enhanced web content that violates the same origin rule. If you enable the HTML Cross-Site Scripting check on such a site, you have to generate the appropriate exceptions so that the check does not block legitimate activity. You can also enable the “Transform cross-site scripts” checkbox on the advanced page using the “more” link for a gentler approach for older sites.
  7. HTML SQL Injection. Many web applications have web forms that use SQL to communicate with relational database servers. Malicious code or a hacker can use an insecure web form to send SQL commands to the web server. The application firewall HTML SQL Injection check provides special defenses against injection of unauthorized SQL code that might break security. If the application firewall detects unauthorized SQL code in a user request, it either transforms the request, to render the SQL code inactive, or blocks the request. The application firewall examines the request payload for injected SQL code in three locations: 1) POST body, 2) headers, and 3) cookies.A default set of keywords and special characters provides known keywords and special characters that are commonly used to launch SQL attacks. You can add new patterns, and you can edit the default set to customize the SQL check inspection. The application firewall offers various action options for implementing SQL Injection protection. The WAF profile also offers the option to transform SQL special characters to render an attack harmless. This may be a desirable initial setting to prevent significant impact to an existing site. Simply check “Transform SQL special characters” under the “more” link in the advanced page.
  8. XML Denial of Service. Running an XML-based API? Consider enabling this feature and activating the element checks on the advanced section based on your knowledge of your API to protect against attacks that attempt to overwhelm your servers.
  9. XML SQL Injection. A XML SQL attack can inject source code into a web application such that it can be interpreted and executed as a valid SQL query to perform a database operation with malicious intent. For example, XML SQL attacks can be launched to gain unauthorized access to the contents of a database or to manipulate the stored data. XML SQL Injection attacks are not only common, but can also be very harmful and costly. This is an easy feature to implement. Simply check the box. No advanced configuration is necessary.

Of course, we’re here to help! If we can provide any guidance or configuration assistance, simply reach out to us by creating a support case.

The post Web Application Firewall Quick-Start Guide appeared first on Total Uptime®.