I think my box has been hacked ? --help

redhatattack · 10-31-2006, 12:58 AM

Greetings again,

I just installed a server ( colo ). Redhat ES ...

Big thing I noticed was how I was able to login remotely as root. ( su root ). I just "plugged it in" to the isp a few hours ago and I was able to login as root as...

my root password = MRP@345xyz

also was able to login as root as ...

MRP

How is this possible? How can you log in as root with 2 different passwords? Other then my system has been compromised? How can you login successfully with 2 root passwords? I think I'm going to have to go back to the ISP and reinstall my system and disable root( only sudo, and use encryption ).

I thought If I just installed it with the redhat basic firewall I would be okay until I could do more... I guess not.

What are the thoughts of the experts here?

Your help is very appreciated!!!!

thank you

redhatattack · 10-31-2006, 01:05 AM

did I screw up and use the @ symbol in my password ?

Gato Azul · 10-31-2006, 01:22 AM

Having never used an '@' symbol in a password, my educated guess would be that it has a special meaning of some sort and that it (and everything after) is getting ignored in your password. I could be wrong however, and if I am I welcome anyone to correct me!

Anyway, It doesn't sound to me like your box has been hacked, though you should really check the logfiles to see if there's any suspicious behavior and should always have some sort of system integrity tool such as AIDE installed so that if an attacker modifies the logfiles, you can still check your system for integrity and possibly find out what files or binaries have been modified. You might want to do a search on what legal characters are allowed in passwords and if the '@' symbol has special significance in a Linux login password.

Hope that helps!

jschiwal · 10-31-2006, 01:23 AM

Since you posted your root password, you need to change it anyway. The password looks more like a login name instead. I'm guessing that your username is MRP and the server is named 345xyz. Choose a better password. Or maybe you are using too simple of a "system" for coming up with a password. I don't think that the problem is that you were hacked.

Your post says that you logged in as root as ... instead of I logged in as root with the password of ...
It sounds like you may have that confused.

In any event how are you logging in remotely. If you are logging in remotely via ssh then you should disable root logins. (Set "PermitRootLogin no" in /etc/ssh/sshd_config.) Instead log in using your username and su to root. Also, if you are the only person who logs in via ssh, then add the line "AllowUsers <your-user-name>" to the /etc/ssh/sshd_config file. This will disallow all other ssh logins, including system users. Script Kiddies will attack the ssh port using root, and the system users.

From the sshd_config manpage:

Code:

     AllowUsers
             This keyword can be followed by a list of user name patterns,
             separated by spaces.  If specified, login is allowed only for
             user names that match one of the patterns.  ‘*’ and ‘?’ can be
             used as wildcards in the patterns.  Only user names are valid; a
             numerical user ID is not recognized.  By default, login is
             allowed for all users.  If the pattern takes the form USER@HOST
             then USER and HOST are separately checked, restricting logins to
             particular users from particular hosts.

     .
     .
     .

     PermitRootLogin
             Specifies whether root can log in using ssh(1).  The argument
             must be “yes”, “without-password”, “forced-commands-only” or
             “no”.  The default is “yes”.

             If this option is set to “without-password” password authentica‐
             tion is disabled for root.

             If this option is set to “forced-commands-only” root login with
             public key authentication will be allowed, but only if the
             command option has been specified (which may be useful for taking
             remote backups even if root login is normally not allowed).  All
             other authentication methods are disabled for root.

             If this option is set to “no” root is not allowed to log in.

Some people will also change the port that sshd listens to. This is configured in /etc/ssh/ssh_config:

Code:

     Port    Specifies the port number to connect on the remote host.  Default
             is 22.

For the protocol, only use ssh v2. Again from ssh_config:

Code:

     Protocol
             Specifies the protocol versions ssh should support in order of
             preference.  The possible values are “1” and “2”.  Multiple ver‐
             sions must be comma-separated.  The default is “2,1”.  This means
             that ssh tries version 2 and falls back to version 1 if version 2
             is not available.

slantoflight · 10-31-2006, 06:37 AM

Quote:

Originally Posted by redhatattack

my root password = MRP@345xyz
lso was able to login as root as ...
MRP

Just tested it. yes you definately can use an at symbol in passwords.

Its not all bad though.I once ran a distro where getting root access was as simple as sudo su <type anything>. And from the first try.

I wont point any fingers though.

poweredbydodge · 10-31-2006, 11:08 AM

below is my example conf file... ( /etc/ssh/sshd_config in FC5 )

this has allowed me to run only SPECIFIED usernames over SSH login. anyone not specified gets kicked / denied after being allowed to enter a password. this keeps it so that a hacker attempting random usernames won't think that he's gotten lucky if he gets to the password prompt -- everyone gets there... doesn't mean you're getting in though.

this also disallows root logins... however, a user can "su" into root capability if they have the root password (but they must have already logged in with a non-root account that is listed under the allow portion of this config file.

hope this helps...

# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

#Listen on
Port 22
#Protocol 2,1
Protocol 2
#The IP address of your machine (NOT YOUR ROUTER or MODEM!)
ListenAddress 192.168.0.XXX

#Encryption key (ssl)
HostKey /directory/directory/name_of_key.pem

# Logging
SyslogFacility AUTHPRIV

#Authentication:

#Login controls
# .. how long allowed to enter uname/pw
LoginGraceTime 1m
# .. allow the root user ??
PermitRootLogin no
# .. max number of times a guy can try to login and fail before the server kicks him and he has to start over
MaxAuthTries 2
# permit blank password entries (this would be used as 'yes' for a guest account where account name = guest / password = 'blank'
PermitEmptyPasswords no
# Check password against that on file?
PasswordAuthentication yes

# Not sure what this option envokes, however, I had an issue logging in and a 'fix' I found online was to change this option to 'no'
ChallengeResponseAuthentication no

# USERS TO ALLOW (This is a 'deny first, allow second' type of list... everyone is denied unless you list them here).
AllowUsers username1 username2 yourotherusername yourbuddysusername yourmomsusername

# GSSAPI options (were in default setup file)
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

# PAM Authentication (we set to 'no' because we're using our ALLOW list above)
UsePAM no

# Accept locale-related environment variables (all setup by default)
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
X11Forwarding yes

# override default of no subsystems
# this will allow sftp logins through sftp clients like gFTP
# remove it and I --believe-- sftp will not work.
Subsystem sftp /usr/libexec/openssh/sftp-server

---------------------
end

redhatattack · 10-31-2006, 09:53 PM

Thank you everyone for the replies.

Here is a summary of the confusion ...

< I "su root" and entered half my password and got logged in. That basically sums up what happened without going into anything else. >

Wouldn't you find it odd if you were able to do that on your box? Needless to say I haven't been able to duplicate this. I was also using putty, maybe it was something in that? At any rate it's weird. I think I was hacked, I'd rather think I was not but...

Thanks again !!!

jschiwal · 10-31-2006, 10:00 PM

Since you just installed the server, you could reinstall it without having to backup much data. I'm thinking that the interface you used to set the root password may have dropped everything after the @ symbol.

Make sure that you harden the server before connecting to the internet. If you are running MySQL for instance, there is a pdf or ps file (manual.ps) in the /usr/share/doc/packages/mysql/ directory. One of the first sections of the manual deals with securing mysql. Otherwise, there are two passwordless root accounts open.

hank43 · 11-01-2006, 02:18 AM

"Make sure that you harden the server before connecting to the internet."
Any tips on how to go about this when you're getting a dedicated server from a provider?

i've read the password length in login.defs could cause this. if set to 5, it matches only the first 5 characters of the pass, so if your pass is 8 in length, only the 1st 5 count. maybe that is a legacy problem that has since been solved.

unSpawn · 11-01-2006, 06:25 AM

"Make sure that you harden the server before connecting to the internet."
Any tips on how to go about this when you're getting a dedicated server from a provider?
Check out the LQ FAQ: Security references, post #1 "Checklists" and "Securing" and since you're probably running LAMP check out post #6 "Securing networked services" as well.

hank43 · 11-01-2006, 12:52 PM

unSpawn, i was pointing out that the dedicated companies give you the server already connected to the internet. i don't know if they build it without the machine on the public net, but before i log in and get to do any hardening, the machine has been out there. It's not like a colo where i can harden my box and then plug it in.

unSpawn · 11-01-2006, 07:05 PM

before I log in and get to do any hardening, the machine has been out there.
If they're not willing to work with you on that then uncontrolled public exposure can lower the initial level of trust, depending on how post-install configuration is done. That does not change the fact you have to do a full scale audit of the system. It means the outcome of the audit can not be seen as definitive which means you can not trust the system onehundred percent. With all due respect, but what you pay for is what you get.