USB Data-Blocker aka USB Condom

I was recently reading Kevin Mitnick’s “The Art of Invisibility” and found that he’d also recommended these devices. I’ve been using them for several years as it was always unnerving to plug in a mobile device into a work computer to recharge only to see that there was a request to mount them. Additionally, my laptop would occasionally want to tether data via my cell phone. In an effort to block data transfer and leakage, something was required. These simple and cheap devices allow for power but no data to be transferred via the USB port.

WARNING: there’s always the possibility that any USB device could be compromised, including these… keep them in sight and under your control at all times.

REFERENCES:

“Referrer-Policy” HTTP Header

A relatively new HTTP Header that is supported by most modern browsers (except MSIE) is the “Referrer-Policy” header. There have been previous attempts to implement similar protections through use of the ‘rel’ (or ‘rev’) attributes on links to external websites. The latest approach takes a different approach and prevents leaking of internal URLs, and in some cases parameters, to external websites. This is important from a security perspective as you might maintain some sensitive information in your page urls, that would otherwise be inadvertently shared with an external website.

Clearly, you’ll need to determine your own level of security based upon your needs. Example: ‘no-referrer’ would be the most strict and would prevent the browser from sending the ‘Referer'(sic) header even to your own websites pages.

Example header values:

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

Implementation can be accomplished in many ways, the most simple being and addition to your HTTP server configuration similar to the one shown below for Apache 2.x:

Header always set Referrer-Policy strict-origin

REFERENCES:

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

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:

Blocking access to files by extension in Apache

Usually, you might have a simple rule to prevent users from accessing sensitive files such as “.htaccess“, that rule might look like:

<FilesMatch "^\.ht">
Order deny,allow
Deny from all
Satisfy all
</FilesMatch>

You can also use this capability to prevent other file extensions. For example, if you wanted to block common image formats extensions, you might add the following:

<FilesMatch "\.(gif|png|jpg|ico)$">
Order allow,deny
Deny from all
Satisfy all
</FilesMatch>

Some other file extensions to consider, *.bak, *.old, *.inc

REFERENCES:

Conditional Comments cause CSS to block

Here’s an odd one…. I’ve found that if you use the common method of using Conditional Comments to separate MSIE specific CSS, you’ve likely added a performance problem without knowing it… that is, in addition to the network connection and time required for the different CSS files.

It turns out that the standard use of this approach blocks the other downloads until the main CSS is loaded.

The solution is both simple and painless to implement…. a quick solution to this is to add an empty conditional comment early on, that is, before the main content (CSS) is loaded.. This works for all approaches, such as those where comments surround the <body> or various <link>, <style> or <script> tags.

UPDATE:
Personally, I like to do this immediately after the DOCTYPE and before the <html> tag. Additionally, since IE10 dropped support for this technique, I’ll just target IE 9 and below for any developer that comes after me.


<!DOCTYPE html>
<!--[if lte IE 9]><![endif]-->
<html lang="en">
...

REFERENCES:

Preventing portions of a webpage from printing

A colleague asked me about my solution for this just the other day, here’s the quick solution.

  1. Add a CSS class attribute to the items.  Assuming they are <div>’s for header and footer, they would look like my example below, but you can add the ‘no-print’ class to anything you don’t want printed.
  2. Add a stylesheet with media=”print” to change the visibility and/or display attributes of that class.
  3. With a little more work, you could add a ‘no-screen’ solution too… this would be advantageous in cases where you may need to mask an account number or SSN.

<html>
<head>
<title>Example</title>
<link media=”print” href=”print.css” type=”text/css” rel=”stylesheet” />
</head>
<body>
<div class=”no-print”>This is your header</div>
<div>this is the body</div>
<div class=”no-print”>this is your footer</div>
</body>
</html>

print.css could then contain:

.no-print { display:none; }

Cheers!