Tag Archives: security

what is “plan b” for iot security?

Schneier has a recent article on security concerns for IoT (internet of things) devices – IoT Cybersecurity: What’s Plan B?

We can try to shop our ideals and demand more security, but companies don’t compete on IoT safety — and we security experts aren’t a large enough market force to make a difference.

We need a Plan B, although I’m not sure what that is. Comment if you have any ideas.

There are loads of great comments on the post.

Here’s the start of some of my thoughts:

There are a host of avenues which need to be gone down and addressed regarding device security in general, and IoT security in particular.

Any certification program could be good .. right up until the vendor goes out of business. Or ends the product line. Or ends formal support. Unless we go to a lease model for everything, you’re going to have unsupported/unsupportable devices out there.

We can’t have patches ad infinitum because it’s not practical: every vendor EOLs products (from OSes to firearms to DB servers to cars, etc).

A few things which would be good:

  • safe/secure by default from the vendor – you have to manually de-safe it to use it (like a rifle which only becomes usable/dangerous/operable when you load a cartridge and put the safety off)
  • well-known, highly-publicized support lifecycles (caveating the vendor going out of business)
  • related to the above, notifications from the device as it nears end of support
  • notifications from the device as well as the vendor that updates/patches are available
  • liability regulations – and an associated insurance structure – affecting businesses which choose to offer IoT devices across a few levels:
    1. here it is :: you deal with it || no support, no insurance, whatever risk is there is your problem
    2. patches / updates for 1 year || basic insurance / guarantee of operation through supported period, as long as you’re patched up to date
    3. patches / updates for 3 years ||
    4. patches / updates for 5 years || first-level business offering || insurance against hacks / flaws that have been disclosed for more than 90 days so long as you have patched
    5. patches / updates for 10 years || enterprise / long-term support || “big” insurance coverage (up to a year, so long as you’re yp-to-date) || proactive notifications from the vendor to customers regarding flaws, patches, etc

There are probably other things which need to be considered.

But there’s my start.

how did i never know about .ssh/config?

I’m sure folks have tried to explain this to me before, but it wasn’t until today that it finally clicked – using .ssh/config will save you a world of hurt when managing various systems from a Linux host (I imagine it works on other platforms, too – but I’ve only started using it on CentOS).

Following directions I found here, I started a config file on a server I use as a jump box. In it I have an entry for my web server, and I’ll be adding other frequently-accessed servers to it as time goes on.

Thanks, nerderati, man pages … and whomever else tried to explain this to me before but I didn’t grok.

improve your entropy pool in linux

A few years ago, I ran into a known issue with one of the products I use that manifests when the Red Hat Linux server it’s running on has a low entropy pool. And, as highlighted in that question, the steps I found 5 years ago didn’t work for me (turns out modifying the t parameter from ‘1’ to ‘.1’ did work (rngd -r /dev/urandom -o /dev/random -f -t .1), but I digress (and it’s no longer correct in CentOS 7 (the ‘t’ option, that is))).

In playing around with the Mozilla-provided SSL configurator, I noticed a line in the example SSL config that referenced “truerand”. After a little Googling, I found an opensource implementation called “twuewand“.

And a little more Googling about adding entropy, and I came across this interesting tutorial from Digital Ocean for “haveged” (which, interestingly-enough, allowed me to answer a 6-month-old question on Server Fault about CloudLinux).

Haveged “is an attempt to provide an easy-to-use, unpredictable random number generator based upon an adaptation of the HAVEGE algorithm. Haveged was created to remedy low-entropy conditions in the Linux random device that can occur under some workloads, especially on headless servers.”

And twuewand “is software that creates hardware-generated random data. It accomplishes this by exploiting the fact that the CPU clock and the RTC (real-time clock) are physically separate, and that time and work are not linked.”

For workloads that require lots of entropy (generating SSL keys, SSH keys, PGP keys, and pretty much anything else that wants lots of random (or strong pseudorandom) seeding), the very real problem of running out of entropy (especially on headless boxes or virtual machines) is something you can face quite easily / frequently.

Enter solutions like OpenRNG which are hardware entropy generators (that one is a USB dongle (see also this skh-tec post)). Those are awesome – unless you’re running in cloud space somewhere, or even just a “traditional” virtual machine.

One of the funny things about getting “random” data is that it’s actually very very hard to get. It’s easy to describe, but generating “truly” random data is incredibly difficult. (If you want to have an aneurysm (or you’re like me and think this stuff is unendingly fascinating), go read the Wikipedia entry on “Cryptographically Secure Pseudo Random Number Generator“.)

If you’re in a situation, though, like I was (and still am), where you need to maintain a relatively high quantity of fairly decent entropy (probably close to CSPRNG level), use haveged. And run twuewand occasionally – at the very least when starting Apache (at least if you’re running HTTPS – which you should be, since it’s so easy now).

can you disable encryption on a windows server?

This was asked recently on Server Fault.

I’m asking if there’s a way to prevent files from being encrypted. I’m referring to some extent to ransomware, but specifically I want the following scenario:

  • Windows File server w/ shares (on the E: drive)

I want a way to tell the above server “don’t allow files on the E: drive to ever be encrypted by anyone or any software/process.”

And, of course, the answer to this question is “no”, as I and others said:

No, you cannot prevent files from being encrypted. How is the OS supposed to know if a file is encrypted vs being of some format it doesn’t “know” about?

You can disable OS-level encryption, and perhaps some programs from running via GPO, but that cannot stop every program, nor users uploading already encrypted files.

What you want to do is ensure users are only putting files where they are supposed to – and no where else.

But more interesting is why you would even ask something like this: is it because you really only want “plaintext” files on the share? (Even when the “plaintext” is a binary format (like an EXE, PNG, etc?) I suppose there could be “value” is disallowing even the concept of encrypted files .. but since encrypted files look like files (albeit ones that are not readably openable).

And I think this really belies an exceptionally-poor understanding of what encryption is – and what it is not. Encryption is meant to protect (or hide) specific content (the “specific content” might be the entirety of your phone or hard drive, or an email, or a trade secret, etc) from eyes who shouldn’t be allowed to see what is happening. Yes, there is ransomware that will encrypt or obfuscate files or file systems and demand payment to be decrypted – but attempting to solve for that corner case by attempting to disallow even the concept of encrypted data is highly misguided: the way to prevent/mitigate ransomware is by a combination of good system management practices, solid IDS and IDP software/appliances, sane anti-virus policies, and general good user behavior. (And, maybe, by using OSes less targeted by ransomware authors.)

dave winer is wrong

Or maybe he’s right. But for the wrong reason.

Over on Medium, which is where I saw his post, Dave said:

“The problem of requiring HTTPs in less than 140 chars: 1.Few benefits for blog-like sites, and 2. The costs are prohibitive.

There’s actually a #3 (sorry) — 3. For sites where the owner is gone the costs are more than prohibitive. There’s no one to do the work.”

While this was more-or-less true-ish in times gone by, with the advent of truly-free SSL (and not merely the manual free edition you could get from StartSSL) from Let’s Encrypt (see my how-to), automated, hands-off maintenance of your SSL-iness is possible (and encouraged).

There are, potentially, good reasons for saying SSL won’t be required. But blaming costs, upkeep, and “few benefits” are not among them. If anything, SSL-ifying your blog will help with some (not all) attacks launched against self-hosted/-managed services where login data can be otherwise captured in plaintext.

Dave, I like you. But you’re wrong on this one.