Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Frackin script kiddies!!



On Tue, Aug 3, 2010 at 5:11 PM, Richard Pieri <richard.pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> On Aug 3, 2010, at 4:31 PM, Jarod Wilson wrote:
>>
>> Yeah, that would be what the http auth-digest part is for. So am I to
>> understand correctly that your main opposition to this approach is
>> that the auth happens *after* the encryption channel is established,
>> rather than being a requirement to bring up the encryption channel?
>
> Correct. ?The encryption channel does nothing to prevent an attack against auth-digest. ?All it does is prevent eavesdroppers from listening in and seeing your login/password pair.

Okay, but I'm pretty sure this is still better than having no auth and
no encryption, despite your earlier insistence that it provides "no
protection to your server. None. Zilch. Nada."


>> So am I to presume you never use online banking and never shop online then?
>
> Orthogonal issue, or straw-man, take your pick.

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?

> Two-tier presences put a firewall between the front-end web server and the back-end application. ?Three-tier presences put firewalls between the front-end web server, the application server, and the back-end database. ?In both cases the firewalls only permit outbound connections; they block all inbound connections. ?This ensures that when -- not if, when -- the public-facing servers are compromised they are still isolated from the internal network and cannot be used to launch further attacks inbound.

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.

> On the other hand, it seems that you have no walls between your MythTV web server and everything on your internal network. ?Someone gets past auth-digest somehow and he has full access to everything on the inside.
>
> Food for thought.

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"
(yet). Then I'm in the exact same situation as David. All that
happened to him, so far as he's said, is he lost some recordings. They
still have to do more work to get access to the system itself beyond
just a web ui that lets them delete video files and schedule new
recordings, delete channel info, etc. Sure, its possible there's an
exploit in the mythweb code they could use to get further access, but
the same can be said for a LOT of stuff running on a LOT of web
servers all over the place.

Connecting anything to a public network is a risk. Period. I know
this. Hell, faulty network interface drivers or IP routing stacks can
even be exploited to gain system access, even if you have no services
publicly exposed. The only way to win the game is not to play. ;)


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







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org