On Sat, Aug 15, 2015 at 6:59 PM, B. M. <b-m...@gmx.ch> wrote: > Hi list, > > - Not really a debian problem, but I value the knowledge of you all :-)
Well, these are common technical problems that many of us face, and some/many of the strategies and solutions are very much related to debian. > I'd like to get external input to my security considerations... Free advice and comments from the peanut gallery. (Mine are the latter.) > Hardware / Network situation: > - Family in an apartment, several other apartments in the same building Do you mean you're allowing access to people in other apartments? (Contract issues quickly become security issues.) Or that there are others in the apartment building who might try to access your wireless router? > - Internet by our cable network operator; router offered "for free", > providing WLAN to us Would they allow you to buy a modem of your own? In some countries, you can find cable modems at electronics stores. Although, if the router gives you a web-page where you can set the ip address and do some simple NAT and firewall kinds of things, update options are often there, somewhere. If the web page is only accessible from a wired ethernet connection, that's a good indication, usually. Sort-of. Not giving access to the ability to turn off updates is considered a security strategy by many providers, and that may be for good reason. They may actually consider your modem/router as part of the equipment they own responsibility for. But do they answer your questions about the updates if you ask them? In a way that shows someone at the company understands that updates are even necessary and desirable to them? > - Several clients use WLAN exclusively (no ethernet ports) > - Several computers and tablets, one of them running several services: I assume you are not running the services on a tablet, unless it's one you don't have to jailbreak to load your own OS on, or at least you aren't using a jailbreak app you picked up somewhere on the web? >>;-> (I am still more than a little piqued at Google for failing to do more to support the GPL freedoms of the Android community, not to mention their interface with the rest of the community. No shell except for shell apps that we have to trust some other programmer to squeeze in with gum tape and bailing wire? Libraries that hit segfaults when you try to redirect stdin inside your program? That's just begging for an exploit that can't be addressed. And lack of some means for wired ethernet access (not including the non-solution of ethernet-over-USB, and, no) is just one of the things I'm miffed about. At least the Nexus models should have some waterproofed ethernet port, even if the physical form (thickness of the tablet) requires a different physical connector. If they can get a USB connector on many of the tablets, they could have done something about ethernet. -- Since I seem to be in a very negative mood today, I'll mention that I don't mean MTP or debug-over-USB when I say ethernet-over-USB above. And MTP is a word that should be banned from the list, if banning it would not make it impossible to talk about transferring files. Files. Not media. Sheer social engineering. -- So my comments about the server not being on the tablet are only half-joking, even though they aren't quite relevant here -- other than being a big part of the reason we don't see more debian on tablets. Which is what the short-sighted manufacturers think they want.) > - dovecot for mail: automatic download of all mails (no long-term archiving > online - privacy!). The server, anyway, is connected to the modem/router by wire? > Other clients (laptops) use offline imap to access my dovecot instance > - owncloud for calendar, contacts, files: to synchronize files between > different machines, > synchronized per user I, personally, am not a fan of owncloud-like stuff. But I'm still doing that kind of thing ad-hoc, so maybe I shouldn't be critical. > - I created a CA and (sub-) certificates for S/MIME as well as a server > certificate > used for apache (owncloud, dovecot) Well, PKI is what it is, and, unfortunately, everyone sort of uses it because ... they think there is no other option. But they don't really use it because they don't really understand it. Which is not surprising because the people who invented it still don't really understand it. Which is not surprising because the "trust" mechanisms are not susceptible to systematic solution. System is anethema to trust. What is necessary is a framework under which non-systemized trust mechanisms can be created ad-hoc by the people who will trust them, in other words, by the people who will use them. PKI could almost be that, but such mechanisms don't make money for the big vendors. > Concerns: > - WLAN: SSID hidden, strong password, but I can't really trust the router, > can I ? Stealth mode is almost useless, as others have pointed out. The "password" there is not a password, it's a non-protectable token intended to prove ID (human) or access rights (again, human). That's why you see the factory-set "password" printed on a label on the device itself. It's a very low speed-bump. Stops some joy-riders. > - Someone who has access to our local network could get access to mails or > files (owncloud) Why? > - I have no control over the router (firmware updates? security fixes? I > assume it's > "really cheap" ...) No web page to set the IP, etc., at, mentioned somewhere in the one-page slick set-up guide that almost looks more like an ad than a technical document? > - How can I maximize security? > > Ideas: > - Configure apache to only accept SSL connections, because of WLAN sniffing > (done) > - Configure dovecot to only accept SSL connections, because of WLAN sniffing > (done) > - Configure apache to require SSL client authentication - not yet possible > because the > owncloud sync client doesn't support that yet > - apache: restrict allowed IP addresses using .htaccess file to > 192.168.1.1/24. Does > this provide security / make sense? > - dovecot: is restricting the allowed IP addresses for dovecot possible as > well? > Does this provide security / make sense? Restrictions based on IP are speed-bumps. They stop the people who are too lazy to go in and find a valid IP address to spoof. That's actually a reasonable speed-bump. About ankle-high. Depending on who spends time in your neighborhood, it'll keep out the riff-raff. Only the semi-serious attackers will bother to step over it. > - Any other measures? Demilitarized zone? Virtual demilitarized zone? If you can find the web page to set up the IP addresses for the router, you can do a lot to control how the devices access each other. But you'll need to set the network addresses, not just the device addresses. A firewall that can physically separate the WAN from the LAN and the wireless LAN from the wired LAN would do a lot to help, as someone has mentioned. A NIC for each local segment. (The Network Interface Connector for each segment is where the Raspbery PI and similar devices fall down. Ethernet-over-USB is really painful for anything more than localhost consumption.) But modems really should not have wireless routers in them, unless they allow you full admin access. Ideally, I'd be inclined to shut the freebie wireless off and do the wireless on my own. Ideally. Again, if you can even set the network and router addresses, and the network mask, you should be able to cobble together something to at least give you virtual separation of network segments. > Thanks for your input! > B.M. > Hopefully my rant was not too negative. You are already doing more than most of my neighbors. More than I, in fact, considering that I still don't have a backup device for the family. (I've somewhat given up. My family does not want me to "waste" money on the hardware, or even the time for the setup.) -- Joel Rees Be careful when you look at conspiracy. Arm yourself with knowledge of yourself, as well: http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html
