Re: use ipchains to block all ports > 60,000

From: Tim Haynes (usenet-20030828_at_stirfried.vegetable.org.uk)
Date: 08/28/03 

Date: Thu, 28 Aug 2003 00:33:28 +0100

Neil Sandow <rx@rxlist.com> writes:

>> or 2 is experimental error; in a false-positive report, I'd expect
>> chkrootkit not to be able to discover between 0-2 pids, once every
>> quite-a-few runs, if the box is heavily fork()ing processes left right &
>> centre. A near-as-dammit-constant large-number like 27 going AWOL isn't
>> cool.
>
> Yes, but running ./chkrootkit -x lkm shows all the process id's and they
> are no different than what ps shows. It's not like there are hidden
> processes going on that shouldn't be running (as far as I can tell)

OK. I suppose it could well be a bug in chkrootkit, then. Might be
worthwhile investigating exactly what commands *it* does in order to
ascertain what's going off.

>>>Hmmm very different.
>>>
>>>`ls /proc/[0-9]* | wc -l' returns 377 (every time)
>>>
>>>
>>>`ps auxww | wc -l' returns 28 (every time)
>> OK, I cocked-up on the first of those. Woops :( I should've requested:
>> ls -1d /proc/[0-9]* | wc -l
>> instead - a simple count of how many second-level directories comprised
>> solely of pid#s there are, contrasted with how many processes are running.
>> Only 28 processes on the box? What is its role?
>
> It's an LVS (director) for a web site (load balancer) As the LVS is
> compiled into the kernel it doesn't even show as a process. Nothing else
> going on here except sshd which allows me to log in and monitor the load.
> That's all it does.

OK. In that case, 28 pids isn't too unreasonable for normal operation.

>>>>Do both a netstat -plant | grep LISTEN
>>>
>>>I get:
>>>tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 480/sshd
>> Just sshd? That's possibly a good thing. Now what version of ssh is that?
>> (Telnet into port 22 and give us the banner string.)
>>
>
> Telnet not running but here's the ouput of ssh -V and sshd -V
>
> OpenSSH_3.0.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f
> sshd version OpenSSH_3.0.1p1
>

Ugh. OK, those are old, aren't they? And you're still allowing protocol one
connections as well?

It's 3.6.1p2, here.

>> On a remote box with nmap,
>> nmap -sS -P0 -p1-65535 myboxip -O -o somelogfile.nmap
>> (syn/fin scan, ignoring failure to respond to pings, all ports, your box's
>> externally-visible IP#, with OS-detection, outputs to file as well as
>> stdout).
>
> OK, ran that from an external box and it showed open ports 22, 80, plus
> the masqueraded ports which have been set up to allow ssh into the
> realservers behind the LVS. Should I be concerned that netstat -plant |
> grep listen only returned port 22?

That's not a problem if they're DNATted back into the real server pool -
they'll show as open but there's no process responsible listening on the
box itself so that's to be expected.

>> By temporarily breaking the network connection and inserting a hub there,
>> you can plug another box into that hub that'll see all the traffic coming &
>> going with tcpdump, ethereal or snort, as long as its network device is in
>> promiscuous mode.
>
> Would I have to get off my couch? :>

Very probably ;)

>> One idea you might want to consider: get pen and paper, and list all the
>> functions and services this box provides, all the critical data stored
>> on it, all the tiresome configuration-tweaks present on it. List the
>> cron-jobs it runs. List the users on it and how it gets them.
>> Now, in the background, you can start work on building a replacement box
>> with clean, uptodate, trusted CDs offline, apply distribution's errata,
>> and be vaguely confident of being able to switch the two in the
>> eventuality that you discover (a) a crack has been perpetrated or (b)
>> you never get certain knowlege[0] but want a clean slate.
>
> That certainly sounds reasonable!

It seems like the only niggle at the moment is the antiquated version of
sshd; you'll need to check what versions are vulnerable, but it may well be
everything <=3.5, in which case you could have had a breach and the
processes gone away later - maybe?

> My ISP looked for evidence of massive scans emanating from my ip address
> and found none. No unknown users, no unknown pid's. I'm reluctant to take
> heroic measures without, as you say, concrete evidence of a real problem.

In that case, it's probably time to chill a bit more :)

~Tim 

-- 
   00:28:54 up 82 days, 15:05,  2 users,  load average: 0.15, 0.08, 0.13
piglet@stirfried.vegetable.org.uk |I never knew that the 
http://piglet.is.dreaming.org     |light of ages breaks the way before us
Quantcast