![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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