I tire of this crap.

May 12 11:43:51 HD-MCP HD-MCP[30449]: SSL ACCEPT Error [http request] on [::ffff:31.184.193.154]
May 12 11:43:52 HD-MCP last message repeated 130 times

That would be in Russia.

Then there's this one:

May 12 11:42:15 HD-MCP HD-MCP[30449]: SSL ACCEPT Error [http request] on [::ffff:189.47.119.165]
May 12 11:42:15 HD-MCP last message repeated 169 times

That's Brazil.

May 11 22:01:36 HD-MCP HD-MCP[30449]: SSL ACCEPT Error [http request] on [::ffff:189.129.177.1]
May 11 22:01:36 HD-MCP last message repeated 220 times

And that's from our great friends the NAFTA folks -- Mexico.

Where's my "nuke the source of that crap until it glows" button?

No, they're not an "innocent" series of accidents.  Not with well north of 100 attempts each within a few seconds.  Nor are they isolated -- that's just a small sample.

Oh, if you want to know why you need something like HomeDaemon instead of software written in a "high level" (high-overhead) language, this sort of garbage would be why -- it laughs such attempts off, even on $35 hardware.

With a "bit" more overhead.... it won't be as non-disruptive of an experience for you.

My HomeDaemon-MCP controller has always "attracted" a certain number of "probes", nearly all of which result in a log entry that looks like this:

[10:18] SSL ACCEPT Error [http request] on [::ffff:103.254.156.xxx]

These are connections that are made to the controller and the SSL negotiation fails because the other end doesn't respond at all to it.  That is, it doesn't get back a bad negotiation or attempt to play games with the SSL protocol, it simply gets nothing, a bare HTTP request, or something similar (e.g. someone thinks it might be a Telnet server, for example.)

HomeDaemon-MCP contains its own web server; it does not rely on something like ngnix or Apache.  The reason for this is that the required set of capabilities is well-defined and it's much more-secure to write code that does what you need, along with interdicting attempts to be "bad" (and reporting them) than it is to rely on someone else's brain-fart which, due to the complexity of what it must handle, is inherently much larger and thus has a far larger attack surface.

In the last 48 hours or so the number of "probes" have exploded as apparently Russia and a handful of other locations (the Czech republic, for one) have decided to "ratchet up" attempted assaults on various "Internet of Things" devices.  I'm now seeing these reported not one or two at a time but by the hundreds, back-to-back.  There has also been a marked increase in the number of what appear to be "white hat" surveillance attempts on said devices, including mine, looking for potential vulnerabilities.  The fact that the "bad guys" know I'm here and how to find me isn't surprising in the main.  That the white hat guys are also hammering me is, because the presumption has to be that their primary means of finding me is an exhaustive port-scan on IP address ranges.

Why the "bad guys"?  Because I've been at this sort of stuff long enough, and am well-enough known from my days of running an ISP, that my presumption is that they know who I am and are at least passingly interested in trying to steal things -- like my software.  Maybe I'm wrong and they're just randomly looking too, but I wouldn't take that bet.

This appears to be related, according to the "white hat" folks, to this CERT alert -- and it's a NASTY one.

But HomeDaemon-MCP is laughing all of these attempted assaults off -- both the "white hat" probes and the far more-malicious "black hat" sort.

It's not at all impossible to write IOT code -- HomeDaemon-MCP is one such instance -- that is reasonably secure.

However, it's very hard to cheat and use libraries to do huge amounts of security-sensitive parts of the processing, including the web service part, and actually maintain security because the code isn't yours, even if you attempt to audit it you didn't write it and thus don't have a full understanding of it, and if there is a problem found you're reliant on someone else to fix it.  It gets even worse if you're writing in something like PHP.

That's why HomeDaemon-MCP doesn't do any of that and I took the time and effort to write it on the metal using "C", with the only outside dependency being the OpenSSL libraries.

A reasonably-full description of HomeDaemon-MCP can be found here; it speaks not only Z-Wave with an inexpensive USB "stick" but also can manage independent and fully-internal analog input monitoring using an extremely inexpensive ADC "bolt on" but also GPIO (digital) outputs.  If you have encryption-enabled Z-wave devices it will use AES encryption as well (e.g. door locks.)  It's fast, secure, and runs on extremely inexpensive hardware (the Pi2 and Pi3 computers) with the code itself and its entire working data set for a reasonably-large (~150 events) installation, plus a slave controller, requiring only 10MB of working RAM.  It consumes roughly 10-20% of a Pi2's CPU with it clocked at 600Mhz, or roughly "half-speed" and even with the FreeBSD operating system has nearly 3/4 of the 1Gb of RAM on the unit free.  In other words it's insanely economical in terms of resource consumption, is entirely self-contained in terms of security and it's also extraordinarily fast.

I've recently implemented an "app interface" on top of the standard, HTML-5 browser port that will make streaming-update apps (e.g. for Android) a trivial undertaking, and am starting development of a sample Android app to speak to it (which ought to be fun, since I need to teach myself Android app development in the process!)

Oh, and the license verification code (also certificate based using PKI) is built-in already -- it's literally ready to go, needing only the issuance of certificates to each customer for however long their license terms is.

So where is the firm or firms that want to offer a secure controller of this sort, whether as a packaged product or as an installed system complete with all the mark-up available to same?

If you're that firm email me at karl@denninger.net and let's talk.

Yes, it's for sale -- in source, all rights, and while it's not cheap the asking price is, for what it is, very reasonable.

I finally got my hands on one of these things....

Which one?  The apu2c0, which is a 2-Gigabit Ethernet, quad-core AMD, 2Gb RAM single board computer that is fanless, runs on 12v and has AESNI instructions in it along with a very nice assortment of options for storage and similar.

Specifically, it contains two mPCIe slots and one mSATA slot internally, plus an SD card slot -- all inside.  It also has an RTC (battery backed) so it's basically a "tiny PC."

It quite nicely runs a bone-stock AMD64-bit FreeBSD distribution right out of the box, but since it will boot from the SD card you have even more options -- like running NanoBSD (normal operation in "read-only" mode) which makes it incredibly "hardened" in terms of risk of corruption from power interruption and similar events.

And oh by the way, the Gigabit interfaces are the modern ones -- they attach on the igb driver, not the older em.  This means they have hardware-assisted checksumming for both IPv4 and V6, TSO and jumbo frame support plus the now-obligatory VLAN capability.

In short this damn thing is fast.

Since it can handle AES-NI internally it also makes a very dandy IPSEC gateway, should you decide you want to use one built into it (e.g. VPN.)

It boots off the serial port which is its console, so you need a null modem cable to configure it, assuming you want to change the defaults.  But you don't need to -- as it comes you can stuff an SD card or mSATA bootable device in it and it will find it and boot from it right up front.

The Pi3 is not a bad little firewall for $35.  But frankly, if you have any sort of "fast" connection you will saturate it's ability to move packets.  It's just not that fast.

For about $100, however, this thing is a beast that punches well above its weight and since it's cooled by a heat spreader that transfers the CPU heat to the aluminum case it's also fanless and damn near indestructible.  When it comes to packet forwarding and firewalling it is a screaming buy for anyone who wants a high-performance, rugged gateway box that you can stuff in a closet somewhere and have it "just work."  Since it has front-facing USB ports you can even get cute and put private keys on a USB stick, insert during boot and then yank it with appropriate configuration -- which means if someone steals it they get nothing.  (Of course this means it also can't come back online to run IPSEC unattended; that may or may not matter to you.)

There's only one "gotcha" -- it comes from Switzerland and the postal service will screw around with the package since the seller sends it registered mail.  This means it may well take 2-3 weeks to get it once you order it, but trust me -- it's worth it.

I like this thing.

A lot.

I have a bootable image for it containing all the typical firewall requirements in "NanoBSD" mode (but not the StrongSwan IPSEC package although I could certainly add it) that will come up, get an address on the first interface, and can then be logged into and configured as you wish -- but it's (quite) large; if someone has a place I can dump it who doesn't care about the size of the transfers involved in distributing it, or if you wish to toss me an SD card of 8Gb capacity or more in the mail with a SASE for its return I'll happily copy it on the card for you.  The compressed image is ~650Mb and expands to 6Gb in size, which is appropriate to write onto an 8Gb or larger full-size SD card.

Folks, let's make this easy.

Everyone wants to talk about how Podesta's email was penetrated, or the rest of the DNC, or that the RNC, allegedly, was not.

All the screamers are (still) out about  "Russia" and similar.

Let me restate -- while Podesta's email was apparently broken into via a "spearfishing" email (one with a reset password link embedded in it that didn't go to the real site, but rather to the person who was trying to steal) and which he was dumb enough to click and then provide his current password the real issue here isn't about this sort of attack at all.

The real issue is about the idiocy of such "email" systems or the use of any other sort of cloud provider for anything secure in the first place.

Let me explain.

I run my own email here.  It would be trivial for me to lock it down so that even if you stole my password it would be worthless.

How?

Simple, really.  You see on the same network I have a VPN gateway that does not accept passwords at all.  It only accepts a certificate.  Such a SSL certificate is (nominally) intended to sign and encrypt private emails, and can also be used as a secure identifier for a VPN.  It is, effectively, the same thing a server uses to secure web communications but with a different set of "intended use" flags set (client authentication and digital signature rather than SSL server authentication.)

All I'd have to do is change the configuration on the email system slightly so that only accesses that came from connected VPN clients could connect at all.

Now you'd have to steal a device and if you did, it would only work until I knew it was stolen (and revoked the key.)  No other means of getting in would work even with the password.

It is literally a 15 second configuration change on my Dovecot and Exchange servers to do this, and it would not impact my ability to exchange email with others one bit.

Modern smartphones (including Android, IOS and BlackBerry 10 handsets) can all use these certificates for an IPSEC/IKEv2 connection.  Such a connection can be "nailed" open as well, active even on cellular, or activated "on demand" by the user.  Modern commercial and freely available operating systems (Windows 7/8/10, MacOS, Linux and FreeBSD) can also use same.  Doing so positively encrypts all traffic coming into or leaving said device.

Such a system is extremely secure because only authorized devices, secured with a cryptographic key loaded on them, can see the service in question.  An unknown key is refused by the VPN gateway as is one that has been revoked. Only trusted certificates (which are loaded on the host in a certificate store) can connect.  I use this facility with other services here at Ticker Central so I can have my laptop with me and use it "as if I was at home" even from half the world away on an insecure, or even known to be monitored data link.

The only way to get packets onto the "private" network from the outside and thus be able to "see" the email store is to connect to the VPN and establish a tunnel and the only way to do that is to have a trusted certificate on the device in question.  No certificate, no connection, no access, password or no password -- period.

This sort of facility is essential if you intend to allow remote access to services that are themselves of questionable security (or worse) such as, for example, Windows file shares.

So why didn't the DNC do this?

Because it takes more than 30 seconds of thought to do it and in addition it means not using email providers like Google -- you have to do it yourself, in-house, or all these security steps are worthless since your certificates and such have to be where someone else, who is unvetted, can get at them.

In other words they were stupid, and so have been the others.  They chose the equivalent of an unlocked front door for their house, and then are surprised when someone walks in and takes all the beer out of the fridge.

Oh, and all the guns and money in the house too, along with the nice widescreen TV!

Just remember folks that these are the very same people who claim to be smart enough to run the country.

PS: All the cloud providers are unlocked houses.  Always. They have to be in order for a cloud service to work; it's not a choice, it's an inherent part of any public "cloud" architecture. Claims otherwise are like putting a 25 cent TSA lock on your suitcase and calling it "secure."  The reason you have not and will not see this discussed in the media, especially the "business media", is that the minute this fact reaches the level of general knowledge all of said "cloud providers" have their stock prices collapse.

Give me a break.

A task force of more than 30 major technology and communication companies said they have made progress but have not found a solution to eliminate "robocalls" or automated, prerecorded phone calls, but a top U.S. regulator urged faster action.

Throw some people in prison and you'll get their attention.  Yes, right here in the US, and yes, I'm talking about carrier executives.  Why?  We'll get to that:

Wheeler wrote major companies in July urging them to take new action to block robocalls, saying it was the top source of consumer complaints at the FCC. Scam artists often times based abroad try to appear to call from a bank or a government phone to trick consumers into disclosing confidential financial or account information.

How do they "appear" to call from a bank or government phone when they're not in the United States?

Ah, now see, there's the fraud and the US carriers are complicit in it.

Along with a call setup request (from one carrier to another) comes some information, which includes the "originating" number.  The carriers do exactly nothing to validate that for other than 800 (free to calling party) numbers.

But they could very trivially prevent, for example, foreign calls from appearing with US numbers.

How?  Refuse to route a call that comes from the UK unless the "originating" number is in the correct format including the country code prefix, for example.

That would stop instantly any of these calls that are originating outside of the United States.

As for those within the United States the FCC has jurisdiction, and can require that one of two things be the case:

1. The "originating" number be the actual originating number.  This will be the appropriate setting for all individual lines; simply do not allow an overridden number from a consumer account -- period.

2. For those that are overridden require, under penalty of law, that the party overriding accept both civil and criminal legal responsibility for the authenticity of their override under existing criminal fraud statutes.

There are very good reasons to allow such an override on outbound calls.  For example, at MCSNet we had outbound trunks that were all "rolled up" into high-capacity circuits (at the time DS1s); each of those trunks had a "real" phone number, but it was unpublished.  We then had DID mapping for certain people who needed "private lines" and in addition we had our "main" number (312) - 803-MCS1 that would ring into the PBX on the next available trunk in the group.  If you dialed out from our PBX those trunks (set up for bidirectional signalling) were configured to show 312-803-MCS1 as the "originating" number even though technically it was not.  That's fine, because we owned the originating number, it was "real", and it really was our number.

It would not be difficult at all to require that all such entities that purchase service from a telco provider in the United States and wish to provide "originating number" overrides do so under a contractual requirement, carrying criminal criminal penalties for lying, that any such number they put through be truthful and belong to the actual originating party of the call.

If you were to do this and at the same time hold carriers criminally responsible for accepting "foreign" calls that have originating numbers that violate the country code format of the originating nation, a software check they could easily implement, this problem would disappear instantly.

Of course there are "telco providers" (such as the SIP folks) that would scream about such a requirement -- but let's face reality here.  Enabling fraud as a business model makes you an accessory before the fact and recognizing that along with appropriate criminal sanction would go a long way to draining this swamp -- quickly and permanently.

Instead we "accept" a bunch of handwaving nonsense that comes from the FCC and various telcos.