Dirty Cow is Coming – Update your *nix boxes

Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel.

This is an old vulnerability but appears to be something being exploited regularly.  In otherwords, keep your stuff up-to-date.

https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails

https://dirtycow.ninja/

Check to see if your systems are vulnerable:
https://github.com/dirtycow/dirtycow.github.io/wiki/Check-if-your-system-is-vulnerable

Homeland Security US-Cert e-mail on Network infrastructure

A few days ago Homeland Security published an e-mail on threats to network devices and securing them.  Rather than cut and paste I exported the e-mail to a PDF. Some good best practices in here.

TA16250A The Increasing Threat to Network Infrastructure Devices and Recommended Mitigations

SHA-1 Certificates EOL

The SHA-1 cryptographic hash algorithm has been known to be considerably weaker than it was designed to besince at least 2005 — 9 years ago. Collision attacks against SHA-1 are too affordable for us to consider it safe for the public web PKI. We can only expect that attacks will get cheaper.

That’s why Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.

https://googleonlinesecurity.blogspot.ro/2015/12/an-update-on-sha-1-certificates-in.html

Protecting your Mikrotik from DNS Amplification

There are several reasons and benefits to using your Mikrotik as a DNS caching server.  Queries to the client are just a tad faster, which makes the overall user experience seem snappier.  It also allows you to quickly change upstream DNS servers in the even of an outage, attack, etc.

There are two main avenues to think about when protecting Mikrotik from DNS.

The first is the incoming port 53 requests to the router.  You only want your customers to have access to query the Mikrotik.  In a simple scenario we have this:.

basic

ether1 is our upstream ISP connection.  Customers are other ports.  In this case if we want to block all port 53 requests from the outside world we specify the WAN interface to drop in the following code:

/ip firewall filter
add chain=input in-interface=ether1 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether1 protocol=tcp dst-port=53 action=drop

This will still allow your Mikrotik to send out DNS queries because they are sourced from a non reserved port. We are simply blocking the Mikrotik from not answering port 53 requests on the external interface.

In a later post we will talk about what to do if you have multiple wan interfaces or multiple exit paths on your router (say running OSPF)

BGP lockdown hints

As I am preparing talks for the upcoming WISPAPALOOZA 2014 in Las Vegas I am making some notes on advanced BGP.  If you are running BGP, and want to lock it down a little here are some general hints.  If you want more attend my session in Vegas or look here afterwords for the full rundown.

General Hints for BGP filter.

1.Filter all all the bogon addresses unless you have a specific need. If you have to ask you probably don’t have a need so filter it. Bogons are:
10.0.0.0/8,
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16

2.Don’t accept your own IP space from upstreams.  There should be no reason someone is advertising your own IP space back to you that is not a downstream customer.  I mean dowstream as to someone you have assigned your own IP space to.

3.Limit the maximum number of prefixes your router will accept.

4.Most ISPs don’t announce anything less than a /24.  Configure your filters to not accept anything smaller than a /24 unless you have a specific need to do so.

5. Separate iBGP from eBGP.

6.Understand the defaults for the platform you are using.