Tag Info

New answers tagged

0

Are multiple ways to do this. Create your own group and add apache and ftp (if you want to use for external upload) user on it. Then change the permissions on /var/www folder to use your group (see this: http://serverfault.com/questions/184548/ftp-and-apache-permission-issues). Add your user(jsmith) to apache group (useradd -G www-data jsmith) and set ...


3

Using root as a general purpose user account is just generally unsafe. Bad things can happen too easily (I once did rm -rf ~ when I was in a root shell). So, you are correct, create a user. Using chown, if there is only one user messing with the server data files, seems fine. The answer to this question goes into some details on how to set it up. It does a ...


2

Some starting points which are by no means an exhaustive list (I will edit the post as people comment; and credit them too): Firewall - only allow access to ports that explicitly require it (in your case probably only SSH and HTTP/S). I've linked to UFW because it's easy. Disable root login - furthermore consider limiting to a particular set of users - you ...


3

It should be safe to click (although I still wouldn't). It looks like the attacker tried to exploit the shellshock vulnerability. If your server is vulnerable, the script will already be executed, you calling it again doesn't add that much harm (in this case, you don't have any more rights than the attacker has, assuming you are not viewing the log from ...


1

Backups don't really have anything to do with preventing or mitigating DDOS attacks. A DDOS attack will prevent people from accessing your site, it doesn't have anything to do with the destruction of data. So to answer your question, no - I don't think setting up backups will help you in the event of a DDOS attack. That said, regularly backing up data ...


1

Here 6 key steps : 1 - Secure your application code 2 - disable all modules not used. Try to disable all, and then, one by one, add modules. 3 - remove all scripts and backup files in the web folder. 4 - disable directory listing 5 - use modsecurity to protect your application from application-level attacks. 6 - Use Fail2ban to trigger HTTP errors ...


3

It's very hard to be have assurance there is no malware present on your server. There are indicators of compromise, but considering you probably didn't log anything remotely and did not have controls in place to prevent unauthorized alteration, it's very hard to rely on your system. Some recommendations (from the perspective that you are on a very limited ...


1

You dont have much to worry about regarding having your VM hijacked to attack the host of all the possible attacks thats really near the bottom of the list. Your outline above is pretty solid and would deter the majority of attackers (barring bots who will just hammer your system). If you want to throw an ips on there, check out snort (its fantastic). In ...


6

You are being hit with Shellshock attempts. As long as you have patched your bash, you should be safe against these attempts. However, you might want to invest in a system for banning repeat system abusers. Try fail2ban. What is a specific example of how the Shellshock Bash bug could be exploited? If you haven't patched bash, you are in big, big trouble. ...


2

Im unsure if this is the "correct" approach, but I would change the permissions of the file to owned by root but also owned by another group which only has read access. Making sure your upstart user is in this shared group. # groupadd upstart # usermod -G upstart the_user # chown root:upstart the_file.conf # chmod 740 the_file.conf The above adds a new ...


0

According to the latest report the Vulnerability is in ZynOS and is trouble for the users of the router from the D-Link, TP-Link, ZTE and other manufacturers which allow remote hackers in changing the DNS settings and hijacks the user traffic. This vulnerability has a "backdoor-type" function "built" into the router suggests a deliberate implementation. ...



Top 50 recent answers are included