Tag: security

Content-Security-Policy: block-all-mixed-content

If you are running a secure website, it’s a good idea to prevent non-secure assets from being included on your page. This can often happen through the use of content management system, or even through website vulnerabilities. A simple change in HTTP headers will help browsers to defend against them.


Content-Security-Policy: block-all-mixed-content

Most modern browsers, except MSIE, currently support this approach.
– Firefox 48+

REFERENCES

Content-Security-Policy: upgrade-insecure-requests;

As the web has been shifting to HTTPS for security and performance reasons, there are many methods to migrate users. One simple method is via the use of the Content-Security Header.


Content-Security-Policy: upgrade-insecure-requests;

Most modern browsers, except MSIE, currently support this approach.
– Chrome 43+

REFERENCES

Clear Ubuntu ‘bash’ history

After a lot of use, your history file can become full of a lot of old commands… once in a while, it can be useful (and safer) to clean them up.

NOTE: this can be especially important if you have ever used a password as a command line parameter as it is stored without encryption in a text file.

Preferred:

cat /dev/null > ~/.bash_history && history -c && exit

Also useful:

history -c
history -w

REFERENCES:

Install Fail2Ban on Ubuntu to protect services

Many common adminstrative services such as VPN and SSH are exposed on known port numbers, unfortunately this makes it easy for hackers to use tools to attempt to access the systems. Use of countermeasures such as Fail2Ban can block them after a few failed attempts.

Installation Steps:

  1. sudo apt-get install fail2ban
  2. sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
  3. sudo vi /etc/fail2ban/jail.local
  4. Update:
    destemail & sender
  5. OPTIONAL:
    Splunk:
    sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/fail2ban.log -index main -sourcetype Fail2Ban

    Splunk (manual):
    sudo vi /opt/splunkforwarder/etc/apps/search/local/inputs.conf

    [monitor:///var/log/fail2ban.log]
    disabled = false
    index = main
    sourcetype = Fail2Ban

  6. sudo service fail2ban restart

REFERENCES:

Squid3 Proxy on Ubuntu

Using a personal proxy server can be helpful for a variety of reasons, such as:

  • Performance – network speed and bandwidth
  • Security – filtering and monitoring
  • Debugging – to trace activity

Here are some simple steps to get you started,  obviously you will need to further “harden” security to make it production ready!


sudo apt-get install squid3


cd /etc/squid3/
sudo mv squid.conf squid.orig
sudo vi squid.conf

NOTE: the following configuration works, but will likely need to be adapted for your specific usage.


http_port 3128
visible_hostname proxy.EXAMPLE.com
auth_param digest program /usr/lib/squid3/digest_file_auth -c /etc/squid3/passwords
#auth_param digest program /usr/lib/squid3/digest_pw_auth -c /etc/squid3/passwords
auth_param digest realm proxy
auth_param basic credentialsttl 4 hours
acl authenticated proxy_auth REQUIRED
acl localnet src 10.0.0.0/8 # RFC 1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC 1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC 1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
#acl SSL_ports port 443
#http_access deny to_localhost
#http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access allow authenticated
via on
forwarded_for transparent

Create the users and passwords:

sudo apt-get install apache2-utils (required for htdigest)
sudo htdigest -c /etc/squid3/passwords proxy user1
sudo htdigest /etc/squid3/passwords proxy user2

Open up firewall port (if enabled):

sudo ufw allow 3128

Restart the server and tail the logs:

sudo service squid3 restart
sudo tail -f /var/log/squid3/access.log

OTHER FILE LOCATIONS:

/var/spool/squid3
/etc/squid3

MONITORING with Splunk…

sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/squid3/access.log -index main -sourcetype Squid3
sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/squid3/cache.log -index main -sourcetype Squid3

REFERENCES:

Java Dependency Vulnerability scanning with Maven victims-enforcer

One of the OWASP guidelines for secure applications is to not use components with known vulnerabilities. Unfortunately it can be a very difficult and time consuming task to keep up with these manually, automation can save you countless hours!

See https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities.

NOTE: victims-enforcer can be used in conjunction with the OWASP dependency scanner. I have only found it to be problematic in ‘tycho’ builds.


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<dependencies>
<dependency>
<groupId>com.redhat.victims</groupId>
<artifactId>enforce-victims-rule</artifactId>
<version>1.3.4</version>
<type>jar</type>
</dependency>
</dependencies>
<executions>
<execution>
<id>enforce-victims-rule</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<rule implementation="com.redhat.victims.VictimsRule">
<!--
Check the project's dependencies against the database using
name and version. The default mode for this is 'warning'.

Valid options are:

disabled: Rule is still run but only INFO level messages and no errors.
warning : Rule will spit out a warning message but doesn't result in a failure.
fatal : Rule will spit out an error message and fail the build.
-->
<metadata>warning</metadata>

<!--
Check the project's dependencies against the database using
the SHA-512 checksum of the artifact. The default is fatal.

Valid options are:

disabled: Rule is still run but only INFO level messages and no errors.
warning : Rule will spit out a warning message but doesn't result in a failure.
fatal : Rule will spit out an error message and fail the build.
-->
<fingerprint>fatal</fingerprint>

<!--
Disables the synchronization mechanism. By default the rule will
attempt to update the database for each build.

Valid options are:

auto : Automatically update the database entries on each build.
daily : Update the database entries once per day.
weekly: Update the database entries once per week.
offline : Disable the synchronization mechanism.
-->
<updates>daily</updates><!-- was: auto -->

</rule>
</rules>
</configuration>
</execution>
</executions>
</plugin>

Vulnerability database is sourced from: https://victi.ms with backing from RedHat.

REFERENCES:

OWASP Dependency Vulnerability Scanning of Java JARs with Maven

One of the OWASP guidelines for secure applications is to not use components with known vulnerabilities. Unfortunately it can be a very difficult and time consuming task to keep up with these manually, automation can save you countless hours!

See https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities.

NOTE: OWASP dependency scanner can be used in conjunction with the victims-enforcer.

Add to your projects pom.xml:

<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>1.3.4</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>

Each time you build, the plug-in will verify the assets against the list of known vulnerable libraries and report them in your output.

Vulnerability database is populated from: https://nvd.nist.gov.

NOTES:

  1. The example above is a very simple implementation, see the documentation for additional functions.
  2. The first use of the plug-in can take a long time as the vulnerability library must be installed locally before initial use.
  3. Similar functionality is available for Ant builds, if desired.

REFERENCES:

RetireJS javascript libary vulnerability scanning with Maven

It’s important to note that even though your site is using a vulnerable library, that does not necessarily mean your site is vulnerable. It depends on whether and how your site exercises
the vulnerable code. That said, it’s better to be safe than sorry.

I identified this method of using the asset after reading the instructions for the Burp/Gulp scanner from h3xstream after the following section caught my eye:
https://github.com/h3xstream/burp-retire-js#maven-plugin-, it contained a small reference to Maven and even showed output but no configuration for use. A couple of attempts later I came up with the following:

Add to pom.xml:

<build>
<plugins>
<plugin>
<groupId>com.h3xstream.retirejs</groupId>
<artifactId>retirejs-maven-plugin</artifactId>
<version>2.1.0</version>
<executions>
<execution>
<id>scanProjectJavascript</id>
<phase>install</phase>
<goals>
<goal>scan</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

After adding this to your pom.xml, the console output for each build will contain information regarding each vulnerable JavaScript library.

One small problem exists in the current version, use behind corporate firewalls can often be blocked, resulting in an error in the console and use of an older version of the vulnerability library to be used in scans.

Error example:

[ERROR] Exception while loading the repository (Most likely unable to access the internet) java.net.UnknownHostException: raw.githubusercontent.com

See the following for updates:
https://github.com/h3xstream/burp-retire-js/issues/8

See https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities.

REFERENCES:

Firefox 41+ extension signing

In the never-ending quest for browser security, Firefox has started implementing safeguards to only allow signed extensions. I found this out after upgrading to Firefox 41 as my installed version of “Deque FireEyes” stopped working. Thankfully, there is a workaround in Firefox 41, but it goes away in Firefox 42.

  • Firefox 40: warning only!
  • Firefox 41: workaround, via:

    about:config:
    xpinstall.signatures.required = false
  • Firefox 42: BLOCKED! unless signed

REFERENCES:

HTTP Strict Transport Security (HSTS)

The HTTP Strict Transport Security feature lets a web site inform the browser that it should never load the site using HTTP, and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.

Example Use case:
If a web site accepts a connection through HTTP and redirects to HTTPS, the user in this case may initially talk to the non-encrypted version of the site before being redirected, if, for example, the user types http://www.foo.com/ or even just foo.com.

Problem:
This opens up the potential for a man-in-the-middle attack, where the redirect could be exploited to direct a user to a malicious site instead of the secure version of the original page.

Risk:
For HTTP sites on the same domain it is not recommended to add a HSTS header but to do a permanent redirect (301 status code) to the HTTPS site.

Bonus:
Google is always “tweaking” their search algorithms, and, at least at present time, gives greater weight to secure websites.


# Optionally load the headers module:
LoadModule headers_module modules/mod_headers.so

<VirtualHost *:443>
# Guarantee HTTPS for 1 Year including Sub Domains
Header always set Strict-Transport-Security "max-age=31536000; includeSubdomains; preload"
</VirtualHost>

Then you might (optionally, but recommended) force ALL HTTP users to HTTPS:

# Redirect HTTP connections to HTTPS
<VirtualHost *:80>
ServerAlias *
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
#RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]
</IfModule>
</VirtualHost>

That’s it…

REFERENCES: