Hi David,
On Fri, 9 Sep 2011 21:45:52 +0930, David Walker <davidianwal...@gmail.com> wrote: > Nick Holland <nick () holland-consulting ! net> >> define "security" :) > > I'm guessing that TLS is out and that IPsec might be in on that criteria. > Is SSH out there too? > I'd say SSH tunnels are still in. >> Your risks with wireless: >> * Unauthorized use to access Internet >> -> use AuthPF so that you have to ssh authenticate to use the >> gateway. > > Yep. Too good to be true but it won't stop a persistent script kiddie > from spoofing though right? > No. IP spoofing won't help them script kiddy at all. To successfully authenticate via authpf, you need a valid ip adress for responses. With a fake source ip, the script kiddy won't even get a full tcp handshake ready... Additionally, you should configure your ssh server to only accept key based authentication. A script kiddy without a private key just wouldn't get in. If you are concerned of unsuccessful login attempts by script kiddies, you should throw in pf's overload function as well. To me that's best practice for any open ssh port. I like my logfiles clean. >> * Unauthorized use of local resources >> -> Use strong authentication for anything internal > > Yep. No SSH server until I sit down and read the docs. > Read about key based authentication. If you only allow keys, you're good to go. Don't lose your private key, though ;) >> * Packet sniffing >> -> use encrypted communications for all you can, and everything >> important. SSH tunnels are your friend > > I'd like to encrypt everything. > Thanks for the search term. :] > Use SSH and/or IPSEC. >> * Uncontrolled access to network' >> -> authenticate everything. > > Here's where the flags go up for authpf right? right. > If I'm right the authentication is on the initial connection and > everything subsequent is based on the associated IP address (or with > noip the userid) which won't prevent a MITM from hijacking that IP and > certainly won't prevent them from reading my packets. Is that right? > Usually authpf is used to open a port to "remote_ip" after successful authentication. That port is usually used for ipsec. Your initial authentication connection is ssh, thus it's encrypted and packet sniffing is useless. Your second connection could be the ipsec tunnel. Again, it's encrypted and packet sniffing is useless. With regards to MITM and hijacking. No, isn't possible with an ssh2 connection. Well, at least I haven't heard of that. >> Basic trick for safer wireless is to assume your wireless devices and >> all devices that are accessible via wireless are raw on the Internet. >> As all your listed devices are OpenBSD, this is entirely possible. > > I guess that works both ways. > I'm quite concerned about the youngsters down my street with too much > time on their hands and not so much with some guy from the intarwebs > using my wireless to attack them ... > I'd like to see that. :] > If your outside facing boxes are OpenBSD, locked down to only have tcp/22 open and the underlying sshd enforces key based authentication, I'd really to see a script kiddy getting beyond that. Can't think of a way, other then they are stealing your private key in the first place. Uh, yeah, when you generate keys, make sure to have a strong passphrase. This will give you some time ahead before a lost private key can get used. I'm under the impression that you have a huge journey of reading, reading and more reading ahead of you ;) Cheers, Marian
