Frackin script kiddies!!

[Jarod Wilson]

On Tue, Aug 3, 2010 at 8:40 PM, Richard Pieri <richard.pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> On Aug 3, 2010, at 6:04 PM, Jarod Wilson wrote:
>>
>> Maybe. But really, if you don't trust ssl for something like access to
>> mythweb, why on earth would you trust it for accessing your financial
>> information?
>
> Maybe I'm not being clear?  The financial information isn't stored on the public-facing server.  It's behind one-way firewalls or it's being transmitted on encrypted links after I've authenticated myself to the system and vice-versa.  Emphasis on authenticated.

Sorry, why does where the data is stored matter? With the online
banking I've seen, you still connect to a site via ssl first. No
authentication yet. Then you authenticate. Then you can see all your
financial information. How is this ultimately any different that
having to authenticate and then seeing data that is on the same
machine? Only difference I see is that perhaps the bank is a bit
smarter about blocking brute-force attacks -- i.e., your login is
disabled after X number of attempts. If that's the case, then ssl +
http auth + and a scheme that disables login after X failed attempts
looks like it would be pretty much of equal strength. Sure, *if*
someone cracks the auth scheme without actually authenticating, the
banks are safer.

> Broken record time: encryption without authentication is weak security.

Ah, but you've *almost* admitted that its at least better than *no*
security... ;)

>> Regardless of multi-tiered presences, the edge systems can still be
>> used to launch outbound attacks, which I thought you yourself said
>> earlier in this thread was what made a system critical.
>
> No, they can't because they are also behind a public-facing firewall that blocks outbound connections (with certain limited exceptions like DNS queries to a limited number of name servers).  Web connections from the outside are allowed into the web server, and application connections from the inside are allowed into the web server, but nothing gets out of the web server except on previously established inbound connections.

You're not saying the firewalls are impervious to flaws and
misconfiguration, are you? :)

> Point of order: not easily.  Any security can be circumvented given sufficient effort, even a properly designed one-way DMZ.  The idea is not to make it impossible.  The idea is to make it so damned difficult that the attacker gives up.

If your data is that important to hide, sure. Does anyone really want
my television recordings that badly? I mean, they can probably find
all of them on the 'tubes already in user-friendly torrent form with
the commercials already cut out.

> Second point of order: once an attacker gains access to the web server there is all kinds of nasty he can do.  This is why we have things like Tripwire, rkhunter, and read-only filesystems that detect or prevent tampering.

I don't think we ever actually discussed anything actually running on
the host, only encryption and authentication. I *do* have such things
in place, so that in the unlikely event someone actually breaches the
box, there's a good chance I'll notice. Quickly.

>> If someone gets past auth-digest, they can use mythweb to delete my
>> recordings, they don't have "full access to everything on the inside"
>
> They potentially have access to every machine on your home network

Um. They potentially have access to every machine on your home network
if there's a single path to any public network.

> unless you've built yourself a two-tier or three-tier DMZ around the MythTV server, which I highly doubt

Nope, I most certainly haven't. And I'm sorry if I offend anyone, but
if anyone is running a three-tier DMZ around their MythTV server, they
need to get bent.

> since you claim that SSL + auth-digest is "good enough".

For a box that's primary function is to house a bunch of video that
can be found freely on the internet without any hacking at all, I
continue to maintain that yes, it is good enough for keeping the
riff-raff from screwing with my MythTV recordings. If they manage to
get past the authentication, the still have to take control of the web
server -- which is already running anyway, regardless of whether or
not they can get by the authentication step -- and escalate further to
do real damage, which is mitigated by things like selinux, stack
randomization and nx protection. So there *are* security measures in
place. And last I knew, there weren't any unpatched apache exploits in
the wild (I see plenty of vendor-sec traffic by way of $dayjob).

Is my system hackable? Sure. Have I taken what I consider to be
reasonable steps to secure the system? Yes. Do those reasonable steps
include not running apache in a way it can be reached by the general
public? No. Its a personal web and media server. The web part is sort
of defeated if apache can't be reached by the outside world. And I
rather like being able to look at mythweb on my mobile phone when I'm
away from home without having to jump through hoops. So mythweb is
accessible too, with ssl + auth-digest. Good enough for me.

-- 
Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org