-
warning: /etc/hosts.deny, line 9: missing ":" separator
thats in my secure log. does that mean the 'all' in hosts.deny isn't taking place? if so thats a major security breach.
Jan 2 22:07:03 localhost sshd[578]: Received signal 15; terminating.
terminating? is that where the attacked stopped the service?
I didn't nmap myself yesterday to see if I had any more open ports. I have a list of things to do when I get home, this evening or at lunch.
-Jason
I configured k-mail w/ my name in it, the settings are stored in /home/Admin/mail, a text file in there with my name config'd might had led the cracker to knowing my name.
-
For the /etc/hosts.deny question, it seems to be badly formatted. Can you put the text from that file in a post? /etc/hosts.deny denies access to the machine remotely based on rule-settings such as the following:
ALL: ALL EXCEPT 127.0.0.1, <your_outside_ip_here, preferably static>
This will still allow a 'connection' but then it'll be closed but localhost (loopback) and the other allowed IP will be able to get in.
Another thing to make sure of, which I'm pretty sure is already the case, is to make sure TCP Wrappers are installed. TCP Wrappers was made by Wietse Venema and is kickass for ensuring the service that's being connected to. Go
here for more information.
As for sshd receiving a SIGTERM (signal 15) and bailing, I'm not sure given the info if that's because of an internal error or because of an outside attack. SSH by default install is pretty stable provided the binary was configured correctly for your machine/OS.
Another measure to take is to find out if you have a banner set for telnet. On RH, you have /etc/issue and /etc/issue.net. Do the following:
# cd /etc/rc.d
# vi rc.local (go down to the /etc/issue part)
In rc.local make sure that something other than the usual uname information is going into /etc/issue.net and /etc/issue. This way, you'll have a notice instead of critical information about your machine. I usually put something like "Welcome to MS-DOS 1.0" or something else...
Now only if I remembered where wu-ftp's information is so they can't find out what kind you use, although if they get in as anonymous, they can run SYST to find out...blah.
-
Vorlin, I never know where I will need to ssh in. So I have hosts.deny set to ALL and hosts.allow set to sshd: all
That way no connections can be made on any services (my understanding of it) but unlimited connections can be made on sshd port. Once I get home for lunch or after dinner I will post a few more things on my website and post a link again.
-Jason
-
Jason, it seems to me that your computer was broken into possibly because of a simple password guess. Out of curiosity, what version of OpenSSH are you running? There was a major vulnerability discovered recently in OpenSSH 1.x IIRC, one that could lead to remote compromises like this.
-
neither of my passwords, (root or Admin) are easy to guess, my root is alphanumeric and is 7chars long and my Admin is also 7 chars long. Unless someone keylog'd me.
-Jason
-
I have updated some logs on my website. UberC0der, Vorlin, whoever would like to help. Please check it out.
-Jason
BTW: wtmp won't copy right, I did a "data wtmp" and it said it was a data file, cat or opening it in text editor just give me garbage.
-
Using 'last' will show you the contents of wtmp, whereas lastb will show you bad connect attempts out of btmp. That should help some.
-
Excellent Vorlin! I hope you don't mind if I kind of re-hash/repeat what you have already said in my two posts here. I kinda posted them before I realized that you had pretty much answered the question and then I came back to edit them. :D
Hi jason-mis, just a little feedback on your /etc/hosts.deny and the error messages we saw in secure log.
[root@nothing /root]# cat /etc/hosts.deny
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!
all <---- This is what secure log is complaining about on line 9 "missing : "
hosts.deny should be in this format if you want to block all:
ALL: ALL EXCEPT 127.0.0.1 Vorlin's caveat applies here.
TCP Wrappers (as mentioned by Vorlin) can drop individual ip's into /etc/hosts.deny, check out portsentry, it can make use of TCP Wrappers for all offending hosts if you choose. Below is an example of blocking individual ip addresses.
ALL: 24.116.131.36
ALL: 65.242.102.24
etc...
-
[root@nothing /root]# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:
operator:x:11:0:operator:/root:
games:x:12:100:games:/usr/games:
gopher:x:13:30:gopher:/usr/lib/gopher-data:
ftp:x:14:50:FTP User:/home/ftp:
nobody:x:99:99:Nobody:/:
nscd:x:28:28:NSCD Daemon:/:/bin/false
mailnull:x:47:47::/var/spool/mqueue:/dev/null
ident:x:98:98:pident user:/:/bin/false
rpc:x:32:32:Portmapper RPC user:/:/bin/false
xfs:x:43:43:X Font Server:/etc/X11/fs:/bin/false
Admin:x:500:500:Administrator:/home/Admin:/bin/bash
squid:x:23:23::/var/spool/squid:/dev/null
The fact that the only non-root, non-system user on the system is named Admin, and not
jason reinforces my suspicion that your attacker knows you. Unless perhaps your hostname is jason or
some form of jason, this guy/gal knows who you are!
/etc/passwd looks to be clean at first glance, I don't see anything out of the ordinary in here. But
please, someone else check this over for something I may have missed.
I would bet that your attacker used some variant of the `SSH CRC32' attack which is a buffer overflow
exploit for vulnerable versions of ssh (which RedHat and others are known to have packaged with their
systems unknowingly). An excellent paper on this attack can be found at http://www.ciac.org/ciac/techbull/CIACTech02-001.shtml .
You had a question about how your attacker changed the ssh login banner. Generally speaking, the file
is /etc/issue.net, but you can check which one your system is using, or even change it by looking in
/etc/ssh/shd_config. The option that controls that login message is.....
Banner /path/to/the/banner
Hope this helped.
-
My banner in /etc/ssh/sshd_config is /etc/issue.net
/etc/issue.net only contains the regualr uname -r contents.
I dont know much about 'grep' but couldn't I grep for 'h4v1ng fun j45on??'
Thanks alot for your input Uberc0der, my hostname is 'nothing', the only thing on my system that has my name in it (that I can think of) is my k-mail config. If they knew me in irc, I chat under the name of jason-mis. if someone got in when I was chatting on my linux box while in irc.antionline.com
I can think of nothing else
About my hosts.deny I want it set to deny all BUT whats in my hosts.allow, I never know where I will need to ssh in from so I have hosts.allow set to sshd: all, is 'all: all' a valid argument in hosts.deny??
Thanks,
Jason
