Product Review: Sync Stop

As I get ready for my trip to Vegas to attend WISPAPALLOZA 2017 the following product becomes relevant.  Security, namely Identity Theft, is becoming more and more of something we have to deal with.  Much like pickpockets, digital Identity theft is a real thing.

This is where the SyncStop by Xipiter comes in.  This is a simple device.  It allows you to charge your phone on any USB enabled connection, but does not allow syncing by cutting off access to the data pins of the USB connection at the hardware level.

If you travel alot I would suggest investing in a few of these.  Let’s face it, we try and find an outlet anywhere we can when it comes to charging our phones.  Hackers know this.  A cleverly designed “public charge station” could be easily compromised to feed your data back to a remote server in just a few minutes and you would probably never notice.

WPA is not encrypting your customer traffic

There was a Facebook discussion that popped up tonight about how a WISP answers the question “Is your network secure?” There were many good answers and the notion of WEP vs WPA was brought up.

In today’s society, you need end-to-end encryption for data to be secure. An ISP has no control over where the customer traffic is going. Thus, by default, the ISP has no control over customer traffic being secure.  “But Justin, I run WPA on all my aps and backhauls, so my network is secure.”  Again, think about end-to-end connectivity. Every one of your access points can be encrypted, and every one of your backhauls can be encrypted, but what happens when an attacker breaks into your wiring closet and installs a sniffer on a router or switch port?What most people forget is that WPA key encryption is only going on between the router/ap and the user device.  “But I lock down all my ports.” you say.  Okay, what about your upstream? Who is to say your upstream provider doesn’t have a port mirror running that dumps all your customer traffic somewhere.  “Okay, I will just run encrypted tunnels across my entire network!. Ha! let’s see you tear down that argument!”. Again, what happens when it leaves your network?  The encryption stops at the endpoint, which is the edge of your network.

Another thing everyone hears about is hotspots. Every so often the news runs a fear piece on unsecured hotspots.  This is the same concept.  If you connect to an unsecured hotspot, it is not much different than connecting to a hotspot where the WPA2 key is on a sign behind the cashier at the local coffee shop. The only difference is the “hacker” has an easier time grabbing any unsecured traffic you are sending. Notice I said unsecured.  If you are using SSL to connect to a bank site that session is sent over an encrypted session.  No sniffing going on there.  If you have an encrypted VPN the possibility of traffic being sniffed is next to none. I say next to none because certain types of VPNs are more secure than others. Does that mean the ISP providing the Internet to feed that hotspot is insecure? There is no feasible way for the ISP to provide end to end security of user traffic on the open Internet.

These arguments are why things like SSL and VPNs exist. Google Chrome is now expecting all websites to be SSL enabled to be marked as secure. VPNs can ensure end-to-end security, but only between two points.  Eventually, you will have to leave the safety and venture out into the wild west of the internet.  Things like Intranets exist so users can have access to information but still be protected. Even most of that is over encrypted SSL these days so someone can’t install a sniffer in the basement.

So what is a WISP supposed to say about security? The WISP is no more secure than any other ISP, nor are then any less secure.  The real security comes from the customer. Things like making sure their devices are up-to-date on security patches.  This includes the often forgotten router. Things like secure passwords, paying attention to browser warnings, e-mail awareness, and other things are where the real user security lies. VPN connections to work. Using SSL ports on e-mail. Using SSH and Secure RDP for network admins. Firewalls can help, but they don’t encrypt the traffic. Does all traffic need encrypted? no.

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.

Check to see if your systems are 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.

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:.


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:,

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.