81–90 of 143 posts
Earlier quoted context omitted.
Better way to reduce the need for copying keys around would be setting up a private CA, and signing the individual keys with it. Of course you need to keep the CA key secure, I'd strongly suggest removable media or preferably a real HSM.
Can you explain how this would work? How do I use a private CA to generate(?) keys for ssh authentication?
I find https://wiki.ubuntu.com/UncomplicatedFirewall to be much friendlier to use when setting up firewalls. The big problem I have is securing my private keys. I use multiple devices, and haven't found a secure and convenient way to share the keys across devices securely. I'd love ideas..
You can keep the database file on an USB stick or even something like dropbox or owncloud [3].
[1] http://keepass.info/index.html
Less than 2% of traffic to Google is IPv6: http://www.google.com/ipv6/statistics.html Even the attacks CloudFlare sees are mostly DDOS: http://blog.cloudflare.com/ipv6-day-usage-attacks-rise Traffic through Akamai is minimal: http://www.akamai.com/ipv6
Maybe someday it makes sense to spend a lot of time around IPv6 defenses, but today is not that day.
This falls a bit short. You shouldn't just update, you should update regularly or better yet set up unattended upgrades[1]. Especially for your hobby projects or personal server because odds are that you won't always have the time to act on every security advisory. (Subscribe here[2] to at least hear about them.) Also, if something breaks once in a blue moon, it's not that big a deal. Fail2ban is fairly heavy and onl…
Another really nifty way to achieve pretty much the same is to use iptables' built-in limit module like so: -A INPUT -p tcp -m tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 4 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j DROP Limit-bursts allows that many packages through before any limit counter starts, if an…
Earlier quoted context omitted.
And then realize you left all ipv6 traffic open (?)
Having separate iptables for IPv6 is painful. Are there any means to address this?
Earlier quoted context omitted.
You shouldn't try to share them, imo, and generate a key for each device. Yes, that may be painful to have to copy 5 public keys on each new server, but the day where, say, your laptop get stolen, you don't have to change the private key on each device : simply remove the laptop one. If you want some kind of centralization, you could only add your keys on a single server, then add this server key on others. You log o…
I agree that key-for-each-device is probably best practice. It just doesn't work for me though. I frequently need to log onto servers from new client computers, and the workflow of connect from trusted device, generate new key for new device then use new device just isn't practical. I've spent a lot of time thinking about this. I think the biggest threat to security on my servers is brute forcing of ssh passwords. Th…
Agree. But wouldn't it make sense then to generate unique keys for all of your devices (still) and then have a key which is your "travel" key and change that periodically?
Amazed that "Install grsecurity" isn't one of the key things listed here. Sure, you have to compile your own kernel, but the enhanced memory protections and many other hardening features make it an excellent addition to your security arsenal. http://grsecurity.net
Another suggestion I miss is just setting the SSH port to something different than 22, while many will correctly notice that this comes close to security through obscurity, it does throw off some more mainstream attempts.
A third one is more web-server specific, if you have the option, make it hide its version number in its responses.
A fourth one would be to mask all errors to a 404 on a production server, the less an attacker knows, the better.
A fifth actually links to the person operating the server: 'know what permissions are, and what they allow/deny'. Too many people "solve" issues by doing a "chmod 777" on a folder, which might have solved one problem (in a very bad way) but probably set him up for a few nasty surprises down the road.
Earlier quoted context omitted.
Having separate iptables for IPv6 is painful. Are there any means to address this?
Simple. Disable IPv6 - it's probably not worth the tradeoff, and your network provider probably doesn't support it anyway.
Many ISPs (and hosters) do support IPv6, and it’s worthwhile to learn a bit about it. If you are running an internet-facing server, I’d say it’s part of being a good citizen to support the latest standards.
To address the parent question, the firewall rules actually need to be a bit different than for IPv4. As an example, IPv6 makes supporting ICMP (for ping and the like) mandatory.
I wrote a post with a simple ip6tables setup about 4 years ago (in German, though, and there might be better posts): http://blogs.noname-ev.de/commandline-tools/archives/74-ip6t...