Prev: FM radio in mobile phones
Next: Black box inventor David Warren dies at 85
From: D Yuniskis on 23 Jul 2010 03:55
Oliver Betz wrote:
> I have no advice.

That's pretty obvious!
From: D Yuniskis on 23 Jul 2010 04:39
Hi Robert,

robertwessel2(a)yahoo.com wrote:
> OK, I was about to scold you for not understanding the requirements,
> but you at least acknowledge them.

Of course! The problem is, most IT departments operate far too
independently of their corporate user bases. And, because
"technology" is so "technical", management tends to take a
hands-off attitude towards it (deferring to the "IT professionals"
more than they usually *should*). They forget that they serve
two roles -- protecting the corporate infrastructure *and*
facilitating the use of that infrastructure! They fixate on
the former at the expense of the latter.

I see this starting to change and traditional IT departments are
losing glamour and becoming "PC support" entities -- with the
other bits of "smart technology" being handled by "higher tech"
departments with more technical expertise (e.g., instrumentation,
etc.). As more and more technology creeps into traditional
commercial infrastructure, the torch will pass to these new
groups (as the IT folks often aren't skilled in the related
technologies that are being "instrumented" -- and, these devices
tend to require less "hand-holding" than PC users do)

> One of the great frustrations in
> my life when wearing my network admin hat are protocols that
> deliberately go out of their way to make themsleves hard to block. I

I'm not sure that is a characteristic of the well-defined
protocols. Rather, an "unexpected consequence"? Most of them
can be (ab)used for other purposes -- which is what makes getting
around firewalls so easy. They tend to be designed to make
doing "something" easy -- and, that often facilitates doing
*other* things easily, too.

> *won't* block legitimate/necessary traffic, but by making things hard
> for me, you've merely pissed me off. Not to mention that devices that
> actively try to hack around firewalls are often difficult to restrict
> - I may choose to trust IBM, and I may choose to allow the support
> processor on the server have Internet access, but you can be darn sure
> that I know exactly which servers at IBM and which local devices are
> allowed to communicate. OTOH, what morons though that SOAP using HTTP
> as a transport was a good idea?

The problem is defining what constitutes *legitimate* use of a
particular protocol? E.g., if a user types into his/her browser:
http://www.coconspirator.com/account/balances/engineering/12334533.02
or http://www.myfriend.com/our/company/stock/is/about/to/split/so/buy/now
is this something that your firewall *should* filter? I.e., you've
just passed something through a firewall that, in all honesty, is
probably completely bogus (but the firewall doesn't know that!)

>> They *can't* be "infected" with virii or other malware. They
>> can't be (intentionally) corrupted by outsiders or disgruntled
>> employees. They're communications are predictable and repeatable.
>> I.e., they are probably *the* most well-behaved, predictable devices
>> in the entire organization. Yet, they are the most "feared"
>> because they are the *blackest* of boxes. (FUD)
>
> And here you're wrong. Let's (for sake of discussion) assume that
> whatever this device is doing over the Internet happens by
> establishing a TCP connection. Now, can you *prove* (and not just to

Don't use TCP. Too heavy and too buggy. It doesn't afford
us anything (that was part of the original design goal -- do
everything connectionless).

> yourself), that there is *no* buffer overflow that a malicious server
> (assuming the real one, which is obviously outside your customer's
> control, has been subverted) could take advantage of? Any of the

Yes. The code has been thoroughly tested and deployed for several
years without incident. The sources are maintained in escrow.
This safeguards against supplier going out of business *and* to
support any litigation against supplier in the event malice or
damage is suspected. The design and implementation have been
reviewed, in detail, by supplier and customer to ensure both
agree on the design's fitness for the specification and application.
If you've worked in any industry that takes these issues seriously
(e.g., Pharma), you'd understand the measures that are taken before
a product is "released". We're not talking about a hundred dollar
toy you can pick out of a Black Box catalog...

> other myriad attacks that have happened against both the TCP/IP stack
> and the applications running on them? Or what about if an adjacent
> device on the network gets subverted, and starts blasting away at your
> box (and such a subverted device has a number of additional possible
> attacks, including ones based on load, that are not possible for the
> subverted external server).

All you can do to this device is fill the (external) pipe and prevent
"other" packets from making it to the device. You can't bring the
network stack to its knees by tying a 100MHz oscillator to the
interface connector (figuratively speaking). Unexpected/incorrect
packets just get discarded. We're not talking about a "desktop PC
stack" that tries to accommodate any potential application. Rather,
this is a stack tailored *to* the actual protocol being used.
Everything is very rigidly defined so that the outside world can go
to hell without consequences -- things keep working "as best they
can" with the information they have to date.

> And then there is the issue of firmware updates. Given that you have
> a device with a network port, it would be most unusual in this day and
> age if you didn't have some mechanism for doing a firmware update.
> And trojaned firmware updates have occurred, both from the real vendor
> (deliberately and otherwise) and via a third party. A number of years
> ago someone started distributing a fake BIOS update for PCs, and
> managed to brick a fair number of PCs from a large vendor. And if the
> device physically supports a firmware update, once you get hacked in,
> even from outside, you can do one, and then not even a reboot will
> clear the device.

Firmware updates are signed. Before an update will "take",
you have to physically be present at the device to activate
a switch. When the update is complete, the switch must be
restored before the device will resume operation (i.e., you
can't leave the switch "active"). Updates are VERY expensive
(because of the time and effort required to test and validate
the code, etc.) so they are infrequent -- and, as such, can be
"inconvenient". (this is actually a blessing for all involved)

> David Brown's advice is good. Just make the Internet requirements
> part of the requirements for the device. If the network admin decides
> it's too risky to attach to one network, he can put it on another. Or
> justify to his CEO why they can't use this device.

If you've read any of my posts over the past few decades, you'd
realize I am a *huge* advocate of formal specifications!

The interface is specified in *gory* detail. Not only the addresses
and ports used but the packet formats *and* timing information
(i.e., what to expect in terms of packet frequency, response times,
end-to-end "propagation delay", timeouts, etc.). These are parts
of the overall specification so they are freely available. Things
are written very carefully (i.e., a specification should be
viewed as a *contractual* obligation between all parties involved)
so that you stick to the *letter* of the spec (no hand-waving about
the "spirit" of the spec -- treat it like a legal contract).

In one case (I mentioned in another post), a "failure" was traced
to an IP address hard-coded in the firewall rules. When the IT
dude tried to cover his backside by claiming that he had followed
the spec, we pointed out that the spec didn't define a *numeric*
IP address. It had very clearly indicated that traffic would be
routed to "foo.com". The fact that *he* had opted to resolve
foo.com on the day he wrote the filter rules was *his* failure
(little "nits" like this are essential when it comes to deciding
who pays air fare, meals, lodging, etc. for the service call :> )

> And frankly, if the network admins are incompetent, you're screwed, in
> the sense that you're not going to be selling product, but sometimes
> those are the breaks.

That's where you're wrong. The network administrators don't make
the purchasing/deployment decisions. And, they don't sign the
checks. They're just grunts that can either facilitate the process
or hinder it. This is why it is desirable to have solutions that
work *despite* them: when you can unplug the CEO's PC and plug in
your device and *show* it working, it makes it hard for the IT
folks to *not* make the system work elsewhere -- the CEO has already
*seen* it work ON THEIR PREMISES! (if you, instead, have to arrange
for their firewall to be configured a particular way *before* you
can do that demonstration, then you are at their mercy -- *did* they
really write the correct rules that you requested? Is there other
infrastructure in the way that they have forgotten to mention??)

> So stick with something simple. Like David suggested, require DHCP,
> DNS and HTTP, and be done with it. HTTP on a non-standard port, or
> HTTPS may make some people happier (although not everyone), so those
> might be a config option.

We often sit on networks that are "deeply embedded" in organizations
(so the traffic that gets in/out is considerably restricted). We make
less demands on the network/firewall than you've suggested. Part of
the design philosophy has been to leave a very small footprint. This
is reflected in the resources that we use (message sizes, frequency,
etc.)

You'd be surprised at just how *little* you need to get through
*most* firewalls! :> I suspect there are techniques similar to
the ones we currently use that could also be used (hence the
purpose of this post) equally well. (I'm engaged in a conversation
elsewhere that may have turned up a very different approach!)

> And think about what your device actually requires. Is it reasonably
> for the device to run for extended periods *without* Internet access?

Different devices have different capabilities and expectations.
Since network connectivity is never "guaranteed" to be available,
everything knows how to operate in the absence of that. But, the
effects of prolonged absence vary with the device and application.
When the network *is* available, we can add *lots* of value (i.e.,
this is what makes things so attractive to customer)!

> Can you get by with just email? It might be easier to get access to
> an email server (and if the device is only *sending* messages, that
> can be a relatively easy option to get past security). Or can you

Email (SMTP/POP/IMAP) seems to be abhorred even more than HTTP!
I guess folks have a harder time keeping their mail servers up
and running. The store-and-forward nature of email also means
it isn't "current" (it's easier to deal with *no* data than it
is to try to figure out how to compensate/adjust late data).
If you expect incoming mail, then you leave yourself vulnerable
to "strangers" forging messages that *are* obligingly passed along
to you -- more work for you to discard them (else you have to hope
customer can filter individual email accounts, etc. -- this puts
a big requirement on the customer... "big footprint")

> provide dial-up as an option (obviously that's only meaningful if the
> device is not otherwise network connected)?

Dial-up requires a phone line at each node. And, getting an
analog modem is more expensive than a network interface.
Also, many firms have digital PBX's -- analog modems don't
work with these (*poof*!). Designing for specific digital
PBX's is costly (and the PBX vendors often are uncooperative
as well as disavow any performance guarantees for "foreign
devices" on *their* "networks")

> But I would beseech you to *not* actively hack around firewalls. No
> matter how tempting the horde of incompetent morons tending firewalls
> may make the idea.

I don't see anything "wrong" with the (ab)uses we are taking
of existing protocols. Statistically, you'd never be able to
identify the increase in traffic, any potential decrease in
reliability or availability, etc. Folks who don't *know*
we are there would be hard pressed to *discover* our presence.
Those that *do* know might not *like* what we're doing (because
it is "wrong" in some semantic sense or is a personal afront)
but it works quite well.

Remember, we're not streaming video, etc. "Small/infrequent
messages" as I said in the original post.

I suspect most of these issues will be going away, soon, as more
of this goes wireless. It seems that the wired networks in most
places will just find use supporting desktop machines and the
IT folks who babysit them. That "fabric" is already in place
and working. Not much to be gained by replacing it with
wireless technologies.

Everything else will move off the cable (since running cable is
costly). This puts extra burdens on those devices (to safeguard
their gazintas and cumzoutas) -- but, any prudent design does this
already (i.e., you wouldn't assume you were safe from hostile
hosts just because you sat behind a firewall!) As I see it, the
biggest challenge will be the variability in the level of
connectivity associated with these new technologies (and designing
in the face of them).
First  |  Prev  | 
Pages: 1 2 3 4
Prev: FM radio in mobile phones
Next: Black box inventor David Warren dies at 85