I have opened another forum topic for this for assistance, so far I have been able to get one of many of the pages to work over HTTPS.
Aside from this ALL Traffic to your amahi server is plain text. Even Samba traffic, this is no good. I'd also like to point out that simply forcing a user to authenticate with a user name and password does not mean it's encrypted, and is plainly visable to the savvy users.
I realize most people dont think about this, but especially when you consider this is your DHCP server, DNS server, File server, Torrent box, VPN, etc, the insecurity really adds up quickly. Even if you use a seperate user and pass for your shares, apps, etc to access your system, it only takes me about 36 seconds to pull a password out of a wire shark capture and another few minutes to escilate privledges in many cases.
I was recently asked by a friend how I liked my Amahi/Fedora install (he and myself both fedora haters) and my only gripe was the complete lack of security for remote authentication. Beyond that, with the latest patches, F9 is relatively secure and I am extremely happy with the Amahi product as a whole aside from this.
HTTPS / Secure forms of Authentication
HTTPS / Secure forms of Authentication
Full time HDA: 2.5ghz Phenom Quad Core, 8gb DDR 800, Asus M3n-ht, PERC 6/i, Norco 4020
Re: HTTPS / Secure forms of Authentication
ok, you are mixing in a lot of things in here.
amahi is not intended to be in a hostile network. not even corporate IT systems have this level of encryption everywhere, even for samba, etc.
amahi is meant to be inside a home network, typically fairly trusted, and secured at the perimeter: router has a firewall, any remote connections are through VPN only and perhaps https, as well as encryption in the wifi.
you can enable https by hand like you have done - directions in the wiki.
you can do that for all the apps. in fact, if you could contribute a patch so that all webapps are using https, this would be popular. better yet, make it programmable with a single click whether one wants http or https. that would be accepted right away!
now - what passwords can you sniff?
certainly not ssh.
samba authentication is encrypted, though i am not sure if it's bulletproof. (the traffic is not encrypted, i believe - but who does that? the military?).
none of the apps authenticate with amahi users, so ... that is not sniffable.
finally, what eaxctly do you mean by "lack of security for remote authentication"?
the VPN is the only supported way to securely access your HDA remotely and that uses remote authentication believed to be completely secure.
oh, and the latest release of amahi is based on fedora 10. fedora 9 is supported only in manintenance mode. no new updates are provided for f9 at this time.
amahi is not intended to be in a hostile network. not even corporate IT systems have this level of encryption everywhere, even for samba, etc.
amahi is meant to be inside a home network, typically fairly trusted, and secured at the perimeter: router has a firewall, any remote connections are through VPN only and perhaps https, as well as encryption in the wifi.
you can enable https by hand like you have done - directions in the wiki.
you can do that for all the apps. in fact, if you could contribute a patch so that all webapps are using https, this would be popular. better yet, make it programmable with a single click whether one wants http or https. that would be accepted right away!
now - what passwords can you sniff?
certainly not ssh.
samba authentication is encrypted, though i am not sure if it's bulletproof. (the traffic is not encrypted, i believe - but who does that? the military?).
none of the apps authenticate with amahi users, so ... that is not sniffable.
finally, what eaxctly do you mean by "lack of security for remote authentication"?
the VPN is the only supported way to securely access your HDA remotely and that uses remote authentication believed to be completely secure.
oh, and the latest release of amahi is based on fedora 10. fedora 9 is supported only in manintenance mode. no new updates are provided for f9 at this time.
My HDA: Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz on MSI board, 8GB RAM, 1TBx2+3TBx1
Re: HTTPS / Secure forms of Authentication
Thanks for your reply.
I do understand my concerns regarding network security are a bit high, I work in the Security sector and spend most of my day looking over network traffic captures. I run a enterprise level VPN firewall to remotely access my internal networks so I can not comment on the Amahi VPN support. However, I can confirm that yoru Ike/vpn negotiations are sent via crackable hashes, however, they are not plain text.
A perfect example (in regard to the need for HTTPS) would be the default http://hda page. Since anyone on my network can access this page, anyone can make modifications to my configuration without authenticating over an encrypted channel. This is what I was refering to regarding remote authentication. Since I run my machine headless, all authentication is "remote" for me, I appologize for not better clarifying this in my previous post.
The passwords I was stating that could be sniffed are any of the pages that you enable "require login" (http://wiki.amahi.org/index.php/Require_Login). While the file created contains a hash, the authentication traffic in this case is handled in plain text ather than over SSL.
In regard to SMB. It appears I was incorrect in stating that this traffic was completely plain text. After some more testing, I have confirmed that the authentication was indeed hashed, but after authentication the traffic is plain text. However, these hashes are relatively easy to crack. Im testing this in my lab network as of current. I'll let you know what I find. I know that you can use SSH to tunnel SMB, but I need to do some more research to see what is required on the "client" side.
Im going to be upgrading to F10 some time in the near future once my Raid controller arrives.
*edit* Also, if your using VNC, unless you manually enable it, this is also plaintext authentication.
I do understand my concerns regarding network security are a bit high, I work in the Security sector and spend most of my day looking over network traffic captures. I run a enterprise level VPN firewall to remotely access my internal networks so I can not comment on the Amahi VPN support. However, I can confirm that yoru Ike/vpn negotiations are sent via crackable hashes, however, they are not plain text.
A perfect example (in regard to the need for HTTPS) would be the default http://hda page. Since anyone on my network can access this page, anyone can make modifications to my configuration without authenticating over an encrypted channel. This is what I was refering to regarding remote authentication. Since I run my machine headless, all authentication is "remote" for me, I appologize for not better clarifying this in my previous post.
The passwords I was stating that could be sniffed are any of the pages that you enable "require login" (http://wiki.amahi.org/index.php/Require_Login). While the file created contains a hash, the authentication traffic in this case is handled in plain text ather than over SSL.
In regard to SMB. It appears I was incorrect in stating that this traffic was completely plain text. After some more testing, I have confirmed that the authentication was indeed hashed, but after authentication the traffic is plain text. However, these hashes are relatively easy to crack. Im testing this in my lab network as of current. I'll let you know what I find. I know that you can use SSH to tunnel SMB, but I need to do some more research to see what is required on the "client" side.
Im going to be upgrading to F10 some time in the near future once my Raid controller arrives.
*edit* Also, if your using VNC, unless you manually enable it, this is also plaintext authentication.
Full time HDA: 2.5ghz Phenom Quad Core, 8gb DDR 800, Asus M3n-ht, PERC 6/i, Norco 4020
Who is online
Users browsing this forum: No registered users and 16 guests