6 ms·

This is very interesting, and I want to try it out. The part about them immediately receiving 'attack packets' made me realise that I am quite ignorant about t

This is very interesting, and I want to try it out. The part about them immediately receiving 'attack packets' made me realise that I am quite ignorant about the realities of web security. It is eye opening to me that a lot of web traffic is malicious. Are there any 'security hardening your server 101 for n00bs' resources? It should be useful for any of these 'phone servers' as well (preferably tool agnostic)

killjoywashere 4y ago
Step 1) If it's not installed, it can't be exploited.
RajT88 4y ago
Use ubiquitous open source software, which has been battle-hardened over the years. I ran a web forum for years, either on PhPbb, or YAF.net. Never got compromised. Constant, round-the-clock attacks though. I think the ultimate saving grace is that the site didn't contain anything of interest - it wasn't selling anything, so no stored credit cards. No digital goods to steal, no public forum topics which relate to videogames, politics, etc. It was a small forum for friends of mine, so there was no obvious community anyone wanted to ruin. The worst we got, was some spam bots once in a while would breach the captcha, and start posting ads. Easily fixed. Not a hack, per se, but neither benign. I don't think we ever attracted the attention of a human hacker, and that's likely why we never got breached.
- RajT88 4y ago
  Also - I am more knowledgeable now. Also install ModSecurity. That will block a lot of malicious stuff once you tune it to your application.
- Gigachad 4y ago
  PHP forum software getting hacked used to be very common occurrence. Not so sure about those but I remember a vbulitin one being exploited.
  - RajT88 4y ago
    Yeah, sure. PHPbb had plenty of exploits too. You could read about them as they were published/fixed.
- prmoustache 4y ago
  > Never got compromised. What makes you 100% sure you would have figured out?
  - EUROCARE 4y ago
    One way of checking is that emails and passwords/hashes might appear in leaks and then DBs like https://haveibeenpwned.com/ https://haveibeenpwned.com/
- urbandw311er 4y ago
  Genuine question : do you feel that FOSS is at a disadvantage when it comes to security/threat prevention? The hypothesis would be that potential attackers are able to gain the advantage by being able to fully review the source in advance and leverage potential weaknesses. (Or worse, contribute to the project and inject weaknesses)
  - EUROCARE 4y ago
    It's the other way around. Only FOSS code has the ability to gather reviews, improvements and fixes from the general public. Security through obscurity is not security.
    - madacol 4y ago
      > Security through obscurity is not security I've never felt comfortable with that argument Yes, if you are a big corporation, and you have many employees with eyes on the code, there's no obscurity when an employee goes rogue, you are wide open. But if you are the only person with access to the code, obscurity works
      - imtringued 4y ago
        This is how companies justify not patching security vulnerabilities.
        madacol 4y ago
        I don't follow, I said obscurity does not work for companies I only think it can work for very small teams with high trust
      - EUROCARE 4y ago
        Obscurity doesn't work because someone will find the hole, they don't need the source code.
  - imtringued 4y ago
    That is a nice hypothesis. The real world isn't that nice. You are assuming that proprietary software vendors care about fixing security vulnerabilities. Most of them don't and they will sue you if you make the foolish mistake of not contacting them anonymously. The truth is that hiding source code is the security barrier for most proprietary software and nothing else.
evan_ 4y ago
> It is eye opening to me that a lot of web traffic is malicious. you should work from the assumption that ALL network traffic is malicious.
- imwillofficial 4y ago
  This is absurd. If all network traffic is malicious, just unplug your device. Boom, more secure. At least some traffic is expected to be valid, but the majority will not if internet facing. Google “Linux hardening for beginners hacker news” there are articles with easy steps and thoughtful comments from time to time.
  - kova12 4y ago
    OK, then work from the assumption that all network traffic is suspect.
    - imwillofficial 4y ago
      There ya go
  - evan_ 4y ago
    > If all network traffic is malicious, just unplug your device. Boom, more secure. I'm not sure why you're saying that like it's ridiculous, it's just plainly true.
    - imwillofficial 4y ago
      Obviously it’s not true. Or you’d have no legit traffic
- Agamus 4y ago
  This is spot-on, especially given the topic of hosting and protecting a server. If you assume that it is all malicious, (and much/most of it is), you stand a better chance of fending an attack.
bragr 4y ago
The main advice I'd give is don't follow the steps about port forwarding and public DNS if you are noob. If you are just playing around with things, you don't need to put it on the public internet, you can just access it over your local network none of those concerns really apply. Other than that, update software regularly because that malicious traffic can only hurt you if you are vulnerable. Otherwise it is just noise in your logs.
jeroenhd 4y ago
An important thing to know is that most automated exploitation techniques are only effective against old and outdated software. It's very rare someone will burn a 0day on the public internet. My personal recommendations, ordered by importance, sort of, maybe: - Minimize attack service: don't install it if you don't need it - Assume you'll be compromised at some point. NSA servers get hacked. FSB servers get hacked. You're not better than them. Think of what you'll do when you get hacked: do you need to rotate keys, change passwords, delete tokens? It's better to have a plan, even if it's a vague idea, just in case. - Think about who might hack you, and how. Are you an activist? You may have opponents that want to attack you directly. Are you just some guy with a blog? Focus on defending against your most probable attackers, like botnets and automated scripts. You can make grand plans for when the NSA tries to break into your secure server network, but in practice you should probably be fine if you just defend against botnets. You can find entire threat analysis guides on the internet but a quick think about "who will attack me why and how will they do it" will probably do. - You probably won't get hacked. Don't become too paranoid; just taking the bare basic steps to prevent getting hacked will make you more secure than millions or even billions of hosts on the web. - Install software in a way that automatic security updates will take care of common vulnerabilities (i.e. prefer apt-install over ./configure && make && sudo make install or curl | bash). - Check how quickly your upstream sources (Termux, in this case) are issuing patches. I haven't checked Termux' security stats myself, but I'd personally try a Debian chroot over a Termux environment just because Debian has more funds available to provide timely updates. - Principle of least privilege: barely anything needs root anymore. Ignore outdated guides and use separate users (or even random user IDs with systemd), it'll probably work. If your server provider gives you a root account, create a normal account, give it sudo permissions, and disable remote root login; root should only be for system maintenance and repair! - Read the manual for suspicious config you copy/paste. Sometimes config is just data (hostnames etc.) but sometimes config disables or overrides default config; for those cases, think "why is this not on by default" - When in doubt, update. Auto-update if you have to. I've run sudo apt update && sudo apt upgrade -y" in a cron job for years but there are better options for most server OS's. On Ubuntu (and probably Debian) run sudo dpkg-reconfigure unattended-upgrades to configure automatic security updates - If you do install stuff manually (downloading a binary, curl2bash, etc.) then find out how to update such software and think of ways to automate the process - Listen to warning messages. For example, many old Ubuntu guides will have you add PPAs in a manner that will give the security keys of a PPA the ability to sign packages from the main system repos. You'll get warnings if you use this method on a modern system and you should probably heed those. - Reboot your server after important kernel updates. If you can afford the downtime, reboot after every update just to be sure; if you can't, check if any important patches were released during the past few days. You can often monitor the reboot status file (/var/run/reboot-required, for example) to see if a reboot is necessary. - Make sure your services come back up after a reboot. One of my servers has a nasty firewall configuration bug somewhere that I haven't been able to track down that causes the firewall to refuse to start on boot. Better to find out that your server isn't reboot safe during a planned maintenance window than when you need the service and it suddenly stops working! - An important file doesn't exist unless it's at three places, at least two which are in a different geographical location. Make backups! - Test if you can recover from backups. An untested backup is a non-functional backup. - Back up recovery/security keys to a safe location. Your fancy, unbreakable hard drive encryption is useless if you forget your password! - When using Docker, make sure to update regularly. It's very easy to deploy a docker application and forget to update it for years! - Even if nothing is going on, log in every now and then and check how your server is doing. - Keep an eye on exploit/security lists for software that you expose publicly, especially if you're not updating them automatically. There are websites that will list all important new vulnerabilities for only certain projects (I use the RSS feed provided by the Dutch government, but others likely exist). - When you see your server might be vulnerable, don't panic. Vulnerability descriptions often start with "an unauthenticated user may execute code and take over the system and turn the sky red and..." and end with "if the administrator has enabled the enable_apple_II_compatibility setting". For example, the Samba/SMB bug that allowed code execution on NAS devices only applied when the optional AppleTalk extension was enabled, which was commonly disabled by default.
colechristensen 4y ago
Most of those "attacks" are extremely low effort full-Internet searches for easily exploited software, effectively checking if you've left your front door open. Basic security practices make a very large proportion of them entirely harmless. (things like not having default usernames and passwords, not including configuration files to be hosted directly, having authentication turned on at all, etc.) You'll want to be basic security knowledge for whatever services you are using, but being safe from these kinds of attacks really only requires the absolute minimum.
- Gigachad 4y ago
  Problem is if you don't keep on top of updates, your server very quickly goes from well secured to a low effort target. There was one instance I remember where an exploit for router software was found and published at the same time the patch came out so routers were being exploited within hours, before their users even had time to update them.
herbst 4y ago
My servers get constantly hammered. 99% are either WordPress exploit requests (which I ignore as I don't run wordpress) or SSH attacks. For which I recommend using fail2ban. Connecting fail2ban notifications to your telegram gives you a new perspective on how bad it really is :)

killjoywashere 4y ago

Step 1) If it's not installed, it can't be exploited.

RajT88 4y ago

Use ubiquitous open source software, which has been battle-hardened over the years. I ran a web forum for years, either on PhPbb, or YAF.net. Never got compromised. Constant, round-the-clock attacks though. I think the ultimate saving grace is that the site didn't contain anything of interest - it wasn't selling anything, so no stored credit cards. No digital goods to steal, no public forum topics which relate to videogames, politics, etc. It was a small forum for friends of mine, so there was no obvious community anyone wanted to ruin. The worst we got, was some spam bots once in a while would breach the captcha, and start posting ads. Easily fixed. Not a hack, per se, but neither benign. I don't think we ever attracted the attention of a human hacker, and that's likely why we never got breached.

RajT88 4y ago
Also - I am more knowledgeable now. Also install ModSecurity. That will block a lot of malicious stuff once you tune it to your application.
Gigachad 4y ago
PHP forum software getting hacked used to be very common occurrence. Not so sure about those but I remember a vbulitin one being exploited.
- RajT88 4y ago
  Yeah, sure. PHPbb had plenty of exploits too. You could read about them as they were published/fixed.
prmoustache 4y ago
> Never got compromised. What makes you 100% sure you would have figured out?
- EUROCARE 4y ago
  One way of checking is that emails and passwords/hashes might appear in leaks and then DBs like https://haveibeenpwned.com/ https://haveibeenpwned.com/
urbandw311er 4y ago
Genuine question : do you feel that FOSS is at a disadvantage when it comes to security/threat prevention? The hypothesis would be that potential attackers are able to gain the advantage by being able to fully review the source in advance and leverage potential weaknesses. (Or worse, contribute to the project and inject weaknesses)
- EUROCARE 4y ago
  It's the other way around. Only FOSS code has the ability to gather reviews, improvements and fixes from the general public. Security through obscurity is not security.
  - madacol 4y ago
    > Security through obscurity is not security I've never felt comfortable with that argument Yes, if you are a big corporation, and you have many employees with eyes on the code, there's no obscurity when an employee goes rogue, you are wide open. But if you are the only person with access to the code, obscurity works
    - imtringued 4y ago
      This is how companies justify not patching security vulnerabilities.
      - madacol 4y ago
        I don't follow, I said obscurity does not work for companies I only think it can work for very small teams with high trust
    - EUROCARE 4y ago
      Obscurity doesn't work because someone will find the hole, they don't need the source code.
- imtringued 4y ago
  That is a nice hypothesis. The real world isn't that nice. You are assuming that proprietary software vendors care about fixing security vulnerabilities. Most of them don't and they will sue you if you make the foolish mistake of not contacting them anonymously. The truth is that hiding source code is the security barrier for most proprietary software and nothing else.

evan_ 4y ago

> It is eye opening to me that a lot of web traffic is malicious. you should work from the assumption that ALL network traffic is malicious.

imwillofficial 4y ago
This is absurd. If all network traffic is malicious, just unplug your device. Boom, more secure. At least some traffic is expected to be valid, but the majority will not if internet facing. Google “Linux hardening for beginners hacker news” there are articles with easy steps and thoughtful comments from time to time.
- kova12 4y ago
  OK, then work from the assumption that all network traffic is suspect.
  - imwillofficial 4y ago
    There ya go
- evan_ 4y ago
  > If all network traffic is malicious, just unplug your device. Boom, more secure. I'm not sure why you're saying that like it's ridiculous, it's just plainly true.
  - imwillofficial 4y ago
    Obviously it’s not true. Or you’d have no legit traffic
Agamus 4y ago
This is spot-on, especially given the topic of hosting and protecting a server. If you assume that it is all malicious, (and much/most of it is), you stand a better chance of fending an attack.

bragr 4y ago

The main advice I'd give is don't follow the steps about port forwarding and public DNS if you are noob. If you are just playing around with things, you don't need to put it on the public internet, you can just access it over your local network none of those concerns really apply. Other than that, update software regularly because that malicious traffic can only hurt you if you are vulnerable. Otherwise it is just noise in your logs.

jeroenhd 4y ago

An important thing to know is that most automated exploitation techniques are only effective against old and outdated software. It's very rare someone will burn a 0day on the public internet. My personal recommendations, ordered by importance, sort of, maybe: - Minimize attack service: don't install it if you don't need it - Assume you'll be compromised at some point. NSA servers get hacked. FSB servers get hacked. You're not better than them. Think of what you'll do when you get hacked: do you need to rotate keys, change passwords, delete tokens? It's better to have a plan, even if it's a vague idea, just in case. - Think about who might hack you, and how. Are you an activist? You may have opponents that want to attack you directly. Are you just some guy with a blog? Focus on defending against your most probable attackers, like botnets and automated scripts. You can make grand plans for when the NSA tries to break into your secure server network, but in practice you should probably be fine if you just defend against botnets. You can find entire threat analysis guides on the internet but a quick think about "who will attack me why and how will they do it" will probably do. - You probably won't get hacked. Don't become too paranoid; just taking the bare basic steps to prevent getting hacked will make you more secure than millions or even billions of hosts on the web. - Install software in a way that automatic security updates will take care of common vulnerabilities (i.e. prefer apt-install over ./configure && make && sudo make install or curl | bash). - Check how quickly your upstream sources (Termux, in this case) are issuing patches. I haven't checked Termux' security stats myself, but I'd personally try a Debian chroot over a Termux environment just because Debian has more funds available to provide timely updates. - Principle of least privilege: barely anything needs root anymore. Ignore outdated guides and use separate users (or even random user IDs with systemd), it'll probably work. If your server provider gives you a root account, create a normal account, give it sudo permissions, and disable remote root login; root should only be for system maintenance and repair! - Read the manual for suspicious config you copy/paste. Sometimes config is just data (hostnames etc.) but sometimes config disables or overrides default config; for those cases, think "why is this not on by default" - When in doubt, update. Auto-update if you have to. I've run sudo apt update && sudo apt upgrade -y" in a cron job for years but there are better options for most server OS's. On Ubuntu (and probably Debian) run sudo dpkg-reconfigure unattended-upgrades to configure automatic security updates - If you do install stuff manually (downloading a binary, curl2bash, etc.) then find out how to update such software and think of ways to automate the process - Listen to warning messages. For example, many old Ubuntu guides will have you add PPAs in a manner that will give the security keys of a PPA the ability to sign packages from the main system repos. You'll get warnings if you use this method on a modern system and you should probably heed those. - Reboot your server after important kernel updates. If you can afford the downtime, reboot after every update just to be sure; if you can't, check if any important patches were released during the past few days. You can often monitor the reboot status file (/var/run/reboot-required, for example) to see if a reboot is necessary. - Make sure your services come back up after a reboot. One of my servers has a nasty firewall configuration bug somewhere that I haven't been able to track down that causes the firewall to refuse to start on boot. Better to find out that your server isn't reboot safe during a planned maintenance window than when you need the service and it suddenly stops working! - An important file doesn't exist unless it's at three places, at least two which are in a different geographical location. Make backups! - Test if you can recover from backups. An untested backup is a non-functional backup. - Back up recovery/security keys to a safe location. Your fancy, unbreakable hard drive encryption is useless if you forget your password! - When using Docker, make sure to update regularly. It's very easy to deploy a docker application and forget to update it for years! - Even if nothing is going on, log in every now and then and check how your server is doing. - Keep an eye on exploit/security lists for software that you expose publicly, especially if you're not updating them automatically. There are websites that will list all important new vulnerabilities for only certain projects (I use the RSS feed provided by the Dutch government, but others likely exist). - When you see your server might be vulnerable, don't panic. Vulnerability descriptions often start with "an unauthenticated user may execute code and take over the system and turn the sky red and..." and end with "if the administrator has enabled the enable_apple_II_compatibility setting". For example, the Samba/SMB bug that allowed code execution on NAS devices only applied when the optional AppleTalk extension was enabled, which was commonly disabled by default.

colechristensen 4y ago

Most of those "attacks" are extremely low effort full-Internet searches for easily exploited software, effectively checking if you've left your front door open. Basic security practices make a very large proportion of them entirely harmless. (things like not having default usernames and passwords, not including configuration files to be hosted directly, having authentication turned on at all, etc.) You'll want to be basic security knowledge for whatever services you are using, but being safe from these kinds of attacks really only requires the absolute minimum.

Gigachad 4y ago
Problem is if you don't keep on top of updates, your server very quickly goes from well secured to a low effort target. There was one instance I remember where an exploit for router software was found and published at the same time the patch came out so routers were being exploited within hours, before their users even had time to update them.

herbst 4y ago

My servers get constantly hammered. 99% are either WordPress exploit requests (which I ignore as I don't run wordpress) or SSH attacks. For which I recommend using fail2ban. Connecting fail2ban notifications to your telegram gives you a new perspective on how bad it really is :)