Tag Info

Hot answers tagged

12

The short answer is this: No, CentOS 5.6 is inherently no more or less secure than any other modern supported operating system. The long answer is a bit more complicated. CentOS is the "Community" release of RedHat Enterprise Linux (RHEL). The differences between the two are fairly small so you can think of them as functionally equivalent, see the Wikipedia ...


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 ...


9

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 ...


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

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 ...


5

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 ...


5

Another free option for long lasting support are the Ubuntu Server LTS "Long Term Support" releases. They offer updates for free for 5 years for server functionality from the initial release. And in this case you get the updates right away, directly from the provider. The CentOS page you link to generally shows support for each release over a 7-year life ...


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

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

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 ...


3

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 ...


3

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 ...


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 ...


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

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


2

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 ...


2

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 ...


2

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.


2

If your system is compromised, you can't trust the OSSEC logs or any other logs generated from that machine. OSSEC is good for detecting new intrusions through log analysis. The command you give is used to detect which OSSEC rule will match the given log. So you are piping all the log files to the ossec-logtest utility and finding out if something matches ...


2

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


1

Basically agreeeing but adding several points: Cipher suites are in the OpenSSL code (technically the library not the executable). Proper OpenSSL already implements nearly all the standard suites so there's nothing useful to add. However RedHat and AIUI also CentOS packages until about the end of 2013 excluded from the build all Elliptic Curve (ECC) ...


1

A fully updated system will still have insecure or weak cipher-suites enabled. You can run a tool such as TestSSLServer, written by Tomas Pornin which will give you a list of cipher suites that are vulnerable to BEAST and CRIME. After you have identified the specific set of insecure cipher suites that affect your system, you can disable them in Apache's ...


1

There are a large number of known vulnerabilities in MT 5.12, but this one that allows command injection (i.e., anything you can run at the shell, it can do) stands out: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0319


1

The answer is no, this doesn't mean you are immune to this attack. If an attacker is unable to compile the exploit on your system, he can as well compile it somewhere else and then upload and run it on your server, providing he has an access to your server of course. Generally speaking, you should not rely on denying access to gcc or any other utility to ...


1

Linux is Linux is Linux. Quite a few commonly used tools (nmap, wireshark etc) are already in the package repository. Those that aren't, you can compile yourself. Will it be more effort than simply spinning up Kali or Debian? Sure. Is it perfectly viable? Definitely.


1

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 ...


1

The short answer is "Yes, anything is possible." The long answer is "Maybe, but without more information it's virtually impossible to tell." You should consider that CentOS VM compromised, remove it from your network and also check the logs on any other systems that were online / connected at the time the unauthorized access occurred. First, here's ...


1

All security tools produce false positives, and this should not be treated any differently. If you are having trouble with this report, I suggest seeking a different approach to testing, perhaps one that isn't dependent on a broken tool. That being said httpd-2.2.15-26.el6.centos.x86_64 was released on March 2nd 2013, and there have been a couple of ...


1

Some daemons traditionally use nobody, so that if they are comprimised, the access they have is limited. If you start assigning files to the nobody user, then if you do have a daemon running as that user, and it was comprimised in some way, then the attacker could potentially gain access to the files. Given that the files are a website, and Joomla ...


1

Definitely, as long as it is a one-time password. It is quite simple to add two-factor auth to any linux service using pam_radius:http://www.wikidsystems.com/support/wikid-support-center/how-to/pam-radius-how-to.



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