6 ms·

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

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 only very recently supports IPv6 (which means the version from your repo may not). You can achieve similar results with something like -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 180 --hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix "ssh brute force: " -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 180 --hitcount 4 --rttl --name SSH --rsource -j DROP -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT but if you disable password logins, no one's going to brute force their way in. [1] https://help.ubuntu.com/community/AutomaticSecurityUpdates https://help.ubuntu.com/community/AutomaticSecurityUpdates [2] http://www.ubuntu.com/usn/ http://www.ubuntu.com/usn/

dsr_ 13y ago
Security is a tradeoff. In this case, unattended upgrades lead to increased downtime. (Why? Because you didn't read the caution note that upstream sent along to you, that's why. You just woke up to the alert saying that your system is down.) If you have a reasonable environment, you should have alpha or qa servers that look just like production, except that they aren't visible to the outside. Always test changes there before upgrading on your production machines.
- nl 13y ago
  Security is a tradeoff. In this case, unattended upgrades lead to increased downtime. Agreed. Indeed, the parent explicitly shows one possible trade-off: 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.
rmk2 13y ago
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 any of the other packages afterwards also do not garner any response, a counter counts up for every further package, effectively blocking everything after the first 7 packages arriving within a minute. (You could also do 3/hour, for example, if you think you need it.) The limit module is a beautiful thing, since you can also use it to limit log messages generated for events etc., using the same syntax, like so: -A INPUT -m limit --limit 1/hour --limit-burst 3 -j LOG --log-prefix "iptables denied: "
- Hello71 13y ago
  Awesome, now I can DoS your SSH with only 3 requests per minute.
  - modoc 13y ago
    You can DOS your own IP from being allowed in..... But not mine.
    - Hello71 13y ago
      The `limit` module operates system-wide; one must use the `hashlimit` module to differentiate based on IP.
- SpenserJ 13y ago
  Both limit and spindritf's suggestion will mitigate the attack, but they won't notify you about it. In most circumstances, I'd prefer to skip on the thousands of notifications per day, however I sometimes like to know about every detail on a server, and Fail2ban gives me that level of control, without the need to tail a log file.
fsniper 13y ago
As a seasoned system administrator, I strongly advise you against unattended or automatic upgrades. In a Linux or FLOSS eco system components are very strongly coupled but loosely developed. Say glibc is base of nearly every server application but it is and server apps are not regres tested for each other. Which will or may lead to incompatibilities, down times or performance issues even on edge cases data loss. So please don't.
- dotBen 13y ago
  While you are absolutely correct, no one is regression testing the updates potentially coming into their project box/gameserver/etc, even if they perform the apt-get upgrade manually. Might as well set it automatically and stay protected <shrugs>
  - SpenserJ 13y ago
    I prefer to be actively administrating my server, so that I know if something does go awry. If I'm asleep, it may be a few hours before I realize that an update broke something. On top of that, I clone my servers and test upgrades in a development environment as much as possible, before allowing an update to go live. As long as you're on top of the updates, a few days between automatic and manual shouldn't have much effect.
- agwa 13y ago
  Your concerns are not an issue with a distro like Debian where the only upgrades are for backported security fixes (or, when an announced point release comes around, critical bug fixes). I worked for several years at a shop with dozens of Debian servers, and nightly unattended upgrades very rarely caused issues, and never caused anything truly serious.
  - e12e 13y ago
    Debian is very stable. I recommend running "safe-upgrade" nightly -- and keeping an eye out for when you need a "dist-upgrade" (typically new kernel images -- and other stuff that should be tested (eg: test that the server actually boots -- not to mention do a reboot to use the new kernel). I'm not sure how good the Ubuntu LTS relases are, but Debian has always been great at both keeping a stable system up, and keeping the upgrade to new version as painless as possible.

dsr_ 13y ago

Security is a tradeoff. In this case, unattended upgrades lead to increased downtime. (Why? Because you didn't read the caution note that upstream sent along to you, that's why. You just woke up to the alert saying that your system is down.) If you have a reasonable environment, you should have alpha or qa servers that look just like production, except that they aren't visible to the outside. Always test changes there before upgrading on your production machines.

nl 13y ago
Security is a tradeoff. In this case, unattended upgrades lead to increased downtime. Agreed. Indeed, the parent explicitly shows one possible trade-off: 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.

rmk2 13y ago

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 any of the other packages afterwards also do not garner any response, a counter counts up for every further package, effectively blocking everything after the first 7 packages arriving within a minute. (You could also do 3/hour, for example, if you think you need it.) The limit module is a beautiful thing, since you can also use it to limit log messages generated for events etc., using the same syntax, like so: -A INPUT -m limit --limit 1/hour --limit-burst 3 -j LOG --log-prefix "iptables denied: "

Hello71 13y ago
Awesome, now I can DoS your SSH with only 3 requests per minute.
- modoc 13y ago
  You can DOS your own IP from being allowed in..... But not mine.
  - Hello71 13y ago
    The `limit` module operates system-wide; one must use the `hashlimit` module to differentiate based on IP.
SpenserJ 13y ago
Both limit and spindritf's suggestion will mitigate the attack, but they won't notify you about it. In most circumstances, I'd prefer to skip on the thousands of notifications per day, however I sometimes like to know about every detail on a server, and Fail2ban gives me that level of control, without the need to tail a log file.

fsniper 13y ago

As a seasoned system administrator, I strongly advise you against unattended or automatic upgrades. In a Linux or FLOSS eco system components are very strongly coupled but loosely developed. Say glibc is base of nearly every server application but it is and server apps are not regres tested for each other. Which will or may lead to incompatibilities, down times or performance issues even on edge cases data loss. So please don't.

dotBen 13y ago
While you are absolutely correct, no one is regression testing the updates potentially coming into their project box/gameserver/etc, even if they perform the apt-get upgrade manually. Might as well set it automatically and stay protected <shrugs>
- SpenserJ 13y ago
  I prefer to be actively administrating my server, so that I know if something does go awry. If I'm asleep, it may be a few hours before I realize that an update broke something. On top of that, I clone my servers and test upgrades in a development environment as much as possible, before allowing an update to go live. As long as you're on top of the updates, a few days between automatic and manual shouldn't have much effect.
agwa 13y ago
Your concerns are not an issue with a distro like Debian where the only upgrades are for backported security fixes (or, when an announced point release comes around, critical bug fixes). I worked for several years at a shop with dozens of Debian servers, and nightly unattended upgrades very rarely caused issues, and never caused anything truly serious.
- e12e 13y ago
  Debian is very stable. I recommend running "safe-upgrade" nightly -- and keeping an eye out for when you need a "dist-upgrade" (typically new kernel images -- and other stuff that should be tested (eg: test that the server actually boots -- not to mention do a reboot to use the new kernel). I'm not sure how good the Ubuntu LTS relases are, but Debian has always been great at both keeping a stable system up, and keeping the upgrade to new version as painless as possible.