Hot answers tagged

67

Well, from your question I assume you know what a line in /etc/passwd is, so your question strikes me as a bit of odd. Unless, of course, you're going through some kind of test and don't really know your ways around a unix system and try to pass easily by cheating with us. However: That's a line in /etc/passwd that defines a user called backdoor, which ...


19

Passwords are normally stored in /etc/shadow, which is not readable by users. However, historically, they were stored in the world-readable file /etc/passwd along with all account information. For backward compatibility, if a password hash is present in the second column in /etc/passwd, it takes precedence over the one in /etc/shadow. Historically, an empty ...


17

You could drop packets from tor nodes all together if you like with ip tables. List of tor nodes can be found at: Ref 1: https://check.torproject.org/cgi-bin/TorBulkExitList.py Ref 2: https://www.dan.me.uk/tornodes Here is a bash one liner to block all traffic from tor to your web server. There are currently about 2000 tor nodes online now that support ...


11

Removal? Forget about it. There is unauthorised root access to your server; anything could have been installed by now and you would have no reliable way to detect it. Even for a forensic expert with local access, it would take a long time to completely audit a system to ensure no trace of extant malware. The only reasonable and responsible course is to ...


11

I am not completely sure, but you may want to look at the protocol setting in sshd_config. From http://wiki.centos.org/HowTos/Network/SecuringSSH # Protocol 2,1 Protocol 2 Change Protocol 1 to Protocol 2 and restart. This should already be set to Protocol 2 in Centos 6.5, but you may want to double check. I found this run down of the different protocol ...


10

You have already acknowledged that having no password is a bad idea due to the fact that your server can be accessible via the Internet. Without a sudo password, it means that you are relying on your public key authentication. If a vulnerability would be found in the authentication which allows an attacker to login: No sudo password It means that your ...


9

Just type: echo root::0:0:root:/root:/bin/bash > /etc/passwd su and you are root. (Removing x means root requires no password anymore, you can use sed command instead of echo yet this is enough to get root shell)


8

Yes it's possible, even over ssh and quite trivial to do. Enable X11 forwarding over ssh (e.g., -X option), start firefox, go to Preferences -> Security -> Saved Passwords -> Show Saved Passwords. You could also find them in the relevant files in ~/.mozilla/firefox/{ user_profile } specifically key3.db for the encryption key and signons.sqlite for the ...


7

Add the following 2 lines to your /etc/ssh/ssh_config and the /etc/ssh/sshd_config file: Ciphers aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-cbc MACs hmac-sha1 Restart services. Boom. FIPS compliant.


6

Going by what you originally posted about SSH, there is no evidence there that your server is compromised. It would be quite a round-the-houses way of breaking SSH for an attacker to resort to a default configuration. This is simply a warning message that your sshd or ssh might be misconfigured. RKHunter could not find a configuration value for the Protocol ...


6

First things first. Your machine was compromised, and several things were installed to keep it compromised. This cannot be salvaged; the machine should be cleansed with fire. You will not be able to avoid a complete format & reinstall. Your system is dead; shed a tear on it, then move on. Now, we are only talking about post-mortem analysis. The crontab ...


6

Found the way. vim /etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_10_whitelist.conf And add this line: SecRule REMOTE_ADDR "^192\.168\.50\.1$" phase:1,log,allow,ctl:ruleEngine=Off,id:999945


6

So it appears that the Red Hat errata and CentOS errata are the same numbers. This is Red Hat's format: RHSA-YYYY-#### And this is CentOS' format: CESA-YYYY:#### Where #### is the same number for both. So, to solve your example question, here's what I did: I went on the RedHat site and searched for the CVE number. This led me to the CVE page that ...


6

You can drop packets that contain specific string and apperantely all requests contain: 'HEAD //images/' string. I suggest the following rule for now and later you can remove it: iptables -I INPUT -p tcp --dport 80 -m string --algo bm --string 'HEAD //images/' -j DROP


6

It's an attempt at command injection. IFS is basically a space in this situation, and && executes multiple commands. So you have: /language/Swedish && echo 610cker > qt && tar /string.js Which tries to execute three commands: /language/Swedish <-- where the injection takes place echo 610cker > qt <-- write 610cker ...


5

It's 2017 and it's time to update the recommendations. Now both all *-CBC and RC4 ciphers are considered weak. So we are left with: MACs hmac-sha2-512,hmac-sha2-256 Ciphers aes256-ctr,aes192-ctr,aes128-ctr Or for anything newer that supports OpenSSH 6.7 and above: Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-...


5

All this is indicating is that the process listening on that address and port has 'requested' the ability to receive connections from any IP address on any port. Until a connection is made the process appears as being connected to nothing in this way (asterisk). From the netstat manpage: Foreign Address - The IP address and port number of the remote ...


5

It can be exploited by log files injection. it might be possible to inject Apache log files, but these files needs root access to open, so it will not be possible to open them via LFI. to solve this problem, we inject temporary Apache log files, which are existed under this path: proc/self/fd/12 or proc/self/fd/14 or proc/<apachi pid>/fd/12 or ...


4

You will never be able to gain complete confidence in your server again, you'll have to rebuild or restore from backups. If there are critical files you don't have backed up then boot to single-user mode, get your data, then wiperola. There are no tools, scanners, or methodologies that will enable you to be sure you're hack-free. Also, you could spend much ...


4

Well there is only one thing you can do: Now best thing is to refer to the stub about this on serverfault. If you are using your webserver for hosting different websites, the best thing you can do is make sure every site has its own user which is jailed. This will reduce the risk of getting your system compromised. (There might still be vulnerable ...


4

Most of the security tools you use in Kali can be installed on CentOS. Maybe they will allow Fedora if not Arch or Ubuntu... https://fedoraproject.org/wiki/Security_Lab Personally I would push for debian and use the Kali repos to install whatever tools you need for the sake of simplicity if that is what you are familiar with, but you could the same tools ...


4

Assuming your system is using regular simple unix authentication, there's at least one way of changing a password assuming you have root access. You can do this by simply editing the /etc/shadow file and pasting in a new password hash in place of the old one. This does not influence "chage -l" output as the change is done outside tools, so no other data (...


4

I think you're the proud owner of a "libworker.so" backdoor! Malware Must Die has a good analysis of it, read that before running it yourself. The Malware Must Die author isn't a native english speaker, but does disclose a ton of detail. Malware Must Die has the PHP "dropper" code getting downloaded via a copy of "Web Shell by oRb", so you're going to need ...


4

You are correct in your assumptions. The keys in /etc/ssh are the keys used to identify the server to the clients, so they cant be used to connect. They can however, as you also correctly states, be used to by someone to identify as your server. You can generate new keys for the server and notify any users that there is a new key and they should trust it. ...


3

In addition to @DogEatCatWorld's answer, there is a more general piece of software called 'fail2ban' that can be configured to monitor log files for specific regular expressions and track IP addresses that act 'suspiciously' (for instance, multiple failed ssh login attempts within a certain timespan) and temporarily block the IP address at the firewall level....


3

I would install sshguard on this server to automatically block hosts trying to bruteforce your ssh accounts. It does this by adding the offending hosts to the firewall rules. An alternative to this is denyhosts which do more or less the same as sshguard, but uses /etc/hosts.deny instead of firewall rules to block the offenders.


3

The first port of call might be to take a packet dump (ie, tcpdump) and see what it is you're throwing out.


3

What you're experiencing is a common problem. Vulnerability scanners that rely upon service banners do not deal with vendors like Red Hat which backport security updates. They are also prone to making assumptions about configuration that lead to false positives. You may be able to improve the accuracy of the scan by running an credentialed scan. If your ...


3

Passwords of 8 or more characters are easy to type and good enough, if you don't use a common word and use combinations of capitals, small letters, numbers and special symbols. Only 8 character passwords is the mandate in many corporate companies. Such companies also force users to change their passwords in 2-3 months. Bruteforcing 8 characters password(...


Only top voted, non community-wiki answers of a minimum length are eligible