Comcast Business Class gateway forwarding port 22 for SSH

For as long as I’ve had Comcast, and other providers for that matter, I’ve been able to configure my internet gateway/router to allow port 22 (SSH) access to an internal machine. It came as a surprise to me earlier this week that I was blocked when I tried to use their web admin console to change the internal forwarding to a newer machine. As usual, Technical Support was less that helpful and said that it was not possible to do so, and never should have been as Comcast uses that port to administer the gateway. To make matters more disturbing, I was told that I could not have similar SSH access to the gateway, and that replacing their hardware, while permitted, would prevent my use of a static IP.

Back to the solution, as I know that I had only setup this forwarding about a year ago, and it was working only minutes before I tried to change it, I knew that the configuration was possible if I could figure out how it was being blocked. The message in the web console was a javascript alert(); and gave me a starting point. I opened up Firefox and used Firebug to look for the message. Here are a few interesting findings from:

http://HOSTNAME/user/feat-firewall-port-forward-edit.asp

var RemoteManagementPortsCgiBase = “8080,8080,1\|8181,8181,1\|2323,2323,1\|22,22,1\|”;

msg += “Public Port Range conflict with Remote Management Ports.\n”;

if (msg.length > 1)
{
alert(msg);
return false;
}
return true;
}

If you even a little bit of javascript (or simple computer programming for that matter), the solution is clear…. if the ‘msg’ value is empty you will not see the alert or be prevented from making the change you desire.

Lesson to be learned by the Comcast developers (or most likely = subcontractors), always validate submitted form data in your application code, NEVER rely upon javascript alone to verify user entered data!

I also find it interesting that they are also preventing 8080, 8081 and 2323… perhaps that’s their other back doors in these gateways for their access. The same approach should work for those ports if you need it!

Content-Security-Policy HTTP Header

There’s yet another new means to ‘help’ client User-Agents with preventing XSS on your websites.

In it’s simplest form you can simply use the following HTTP Header(s), the second one is for earlier versions of Webkit (Chrome/Safari):

Content-Security-Policy: default-src 'self'
Webkit-CSP: default-src 'self'

You can also add to the above to permit assets to load from other sources.
For example, if you were to permit javascript files from example.com you could include:

Content-Security-Policy: default-src 'self'; script-src http://example.com

Additionally, while failures are noted in the client’s browser console (that most users are not aware of), you can have them sent back to your server by adding a ‘report-uri’ attribute with an appropriate handler:

Content-Security-Policy: default-src 'self'; report-uri http://example.com/csp-report.php

REFERENCES:

Device Fingerprinting

Often it can be beneficial to ‘more’ uniquely identify your users. For applications this is trivial, but in a web browser this can be accomplished via only a few attributes.

  • HTTP – User-Agent, IP Address, Content types and languages accepted.
  • HTTPS/SSL – the keys and encryption methods available to a specific user may vary for each client configuration.
  • HTML5 – local storage and capabilities supported.
  • Geolocation – this is included in HTML5, but also supported in many clients without full HTML5 support, or via browser extensions.
  • JavaScript – Installed version – and many DOM attributes/capabilities such as timezone, installed plugins, screen sizes and fonts from the browser can be detected.
  • Java (Applet) – Installed version – this can often be used to get additional information regarding the client system directly from the VM or Operating System itself. (* Persistent Cookies possible)
  • Flash – Installed version – this can often be used to get additional information regarding the client system directly from the Operating System itself. (* Persistent Cookies possible)
  • Silverlight (for Microsoft Windows) – – Installed version and additional information from Operating System?
  • GoogleGEARS (deprecated) – Installed version and additional information from Operating System such as Geolocation

REFERENCES:

Automatically update Java on Ubuntu Linux

With the rate of updates and security patches for Java, administration of your Ubuntu machines can become tedious. There’s a better way… allow it to check for and update with your other software. The steps are easy…


sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java7-installer

NOTE: You can also install java8 in the same manner with:
sudo apt-get install oracle-java8-installer

NOTE: The Java Control Panel can sometimes be hard to locate, it will be at the following:
/usr/lib/jvm/java-7-oracle/bin/ControlPanel

REFERENCES:

Install MySQL database on Ubuntu and add new user.

Installing MySQL on Ubuntu requires only a few simple steps.

  1. sudo apt-get install mysql-server
  2. sudo netstat -tap | grep mysql
  3. sudo vi /etc/mysql/my.cnf
  4. sudo service mysql restart

To look for some simple performance and security suggestions:

  1. sudo apt-get install mysqltuner
  2. mysqltuner

Adding a new user is equally easy…

  1. mysql --user=root --password=mypassword mysql
  2. CREATE USER 'myusername'@'%' IDENTIFIED BY 'mypassword';
    GRANT ALL PRIVILEGES ON *.* TO 'mydatabase'@'%' WITH GRANT OPTION;
    FLUSH PRIVILEGES;

NOTE: This allows access to the user from ALL hosts, it can be limited by replacing the '%' with a specific hostname (such as ‘localhost’ if desired) for security.

REFERENCES:

Morfeus scanner

I was scanning my server log files the other day and found that this old “bot” is still making the rounds. It help’s to shut the door on this with some configuration. It’s specifically looking for PHP vulnerabilities and is easily identified by the expletive in it’s User-Agent HTTP request headers.

REFERENCES:

X-XSS-Protection HTTP Header

This HTTP Header is a feature added by MSIE8 to force it to restrict some XSS vectors that can be disabled by the user. Generally you can add it into your webserver configuration.

X-XSS-Protection: 1; mode=block

REFERENCES:

crossdomain.xml

Adobe FlashPlayer 7 added several security features. I first became aware of this one as I saw a large number of HTTP 404 errors for a file named ‘crossdomain.xml’ in my webserver logs. (see also clientaccesspolicy.xml)

If you use flash on your website, I’d suggest adding an appropriate copy of this file to limit your exposure to some potential security issues.

Restricted domains

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.example.com" />
<allow-access-from domain="example.com" />
</cross-domain-policy>

Open to all domains (not recommended, but fully backward compatible)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

REFERENCES:

Cloudflare CDN (Content Delivery Network)

Best practices for web applications often call for the use of a CDN. Those of you that have worked with YSlow! are likely very accustomed to seeing warnings for this reason. I’ve found that CloudFlare is very easy to setup, and for basic services costs absolutely nothing. In addition to the obvious performance advantages of using a CDN to offload much of your network traffic, it also has the advantage of improved security.

CDN’s work by caching a copy of your static content at several locations around the world, making it closer and faster for your users.

Implementation takes only minutes as it requires that you:

  1. create a (free) account,
  2. retrieve your existing DNS values from your current provider,
  3. determine direct vs. CDN “cloud” routing for each subdomain,
  4. change your DNS records to point to the CloudFlare DNS servers

Some additional advantages I’ve seen since implementing:

  • Site remains available in limited capability to users during server outages or upgrades.
  • Simplified network configuration as all requests can be sent outside of the LAN for users local to the servers
  • IPv6 dual-stack support

REFERENCES:

X-Content-Type-Options: nosniff

To prevent XSS/CSRF exploits in MSIE8 and newer, it’s often best to close as many attack vectors as possible. An easy one to implement is an HTTP Header to prevent MSIE from “sniffing” the content to change it when incorrect.

Example: we would not want an HTML page intentionally served with ‘text/plain’ to be rendered as HTML.


X-Content-Type-Options: nosniff
Content-Type: text/plain

This could be added programatically to pages in your application, via a servlet or servlet filter or added to the httpd.conf file.

Apache2 example: httpd.conf

<IfModule headers_module>
Header set X-Content-Type-Options nosniff
</IfModule>

REFERENCES: