On Thu, 2007-10-04 at 14:32 -0500, Les Mikesell wrote:
> Mike Wright wrote:
> > Jacques B. wrote:
> > <snip />
> >> I'm no expert on this topic. But I do know a case where the
> >> application that was running on the web server was exploited due to a
> >> vulnerability in that application, not in Apache or the Linux box. I
> >> suspect that is the case more often than not. Someone compromises a
> >> web site that is running a vulnerable application. That site happens
> >> to be hosted on a Linux box (because let's face it, a lot of web
> >> servers out there run on *nix).
> >>
> >
> > Hi Jacques.
> >
> > I think you're right on the money there. Google for phpbb and hack for
> > an example of your point.
>
> There's also a huge amount of ssh password-guessing going on, and with
> most distos, ssh is enabled by default on port 22. What I've seen
> appears to be very carefully time-constrained as though the programs
> doing it are trying large numbers of machines at once and limiting the
> attempts to any single machine to avoid notice.
>
In order to reduce the chance of someone successfully hacking in
through ssh unnoticed there a couple things I have been using for
a number of years.
Change the default sshd config or add this one in hosts.allow :
--- snip ---
sshd : .domain.tld \
<IP_ADDR/MASK> \
: severity auth.info \
: allow
sshd : ALL \
: severity auth.notice \
: deny
--- snip ---
It will allow you to monitor both rejected and successful ssh
authentications, which you can grep from the logs and email
irregularities. It also allows you to restrict the IP addresses,
and/or host names allowed to connect to ssh. Make sure to
disable the 'allow all' stuff. Also adding a "catch all" at
the end of the hosts.allow like ;
--- snip ---
ALL : ALL \
: severity auth.info \
: twist /bin/echo "You are not welcome to use %d from %h."
--- snip---
can help you monitor other undefined daemons.
Edit sshd_config and add something like :
--- snip ---
AllowGroups staff
--- snip ---
This allows you to restrict ssh access to users assigned to group
'staff'. Using this you can assign only the users that should be
allowed ssh access to successfully authenticate. Also stay far
away from allowing access to user names like "john", especially
since "john" is installed by default by the password cracker of
the same name making your machine especially tasty.
You can also experiment with using 'spawn' in hosts.allow to
send immediate alerts or log to 'hidden' files like this:
--- snip ---
sshd : KNOWN EXCEPT PARANOID \
: spawn ( /bin/date "+%%b %%d %%T" | \
/usr/bin/sed 's,$, %H %d[%p] allowed %u from %n [%a],' >> \
/var/log/.wrapper.`date +%%Y-%%m-%%d`.log ) & \
: allow
--- snip ---
Be careful to configure something to filter the things you don't
want to be alerted to when setting up automatic alerts. I use
'fgrep -vf <filterfile> <logfile>' in a cron job to mail
root {me} any unusual ssh attempts. The filter file looks like :
--- snip ---
logfile turned over
Received signal
Server listening on
refused connect from
host name/name mismatch
host name/address mismatch
can't verify hostname
Did not receive identification string from 123.45.67.89
Accepted keyboard-interactive/pam for mister.tee from 45.67.89.123
Accepted keyboard-interactive/pam for john.frakes from 67.89.123.45
Accepted keyboard-interactive/pam for mr.magoo from 89.123.45.67
--- snip ---
Remember these are the things you don't want to see.
Hope this gives some of you food for thought. It would be nice if some
of it made it into the default setup, but I have given up trying to get
helpful stuff added. Go ahead and try if you want.
Happy hacker hunting, and Thanksgiving / Columbus Day to those
celebrating this weekend.
