use ipchains to block all ports > 60,000

My ISP has asked me to block all incoming and outgoing traffic on my
Linux Director for tcp ports > 60,000 I tried and managed to block
all ports and had to reboot. This is what I tried (I think)

ipchains -A input --sport 60000:65535 -p -j DENY

at which point everything went blank.

Does anybody know the correct syntax to just block that range of ports
(in and out) without affecting anything else?

Thanks! -Neil

Neil Sandow wrote:

> My ISP has asked me to block all incoming and outgoing traffic on my
> Linux Director for tcp ports > 60,000 I tried and managed to block
> all ports and had to reboot. This is what I tried (I think)
>
> ipchains -A input --sport 60000:65535 -p -j DENY
>
> at which point everything went blank.
>
> Does anybody know the correct syntax to just block that range of ports
> (in and out) without affecting anything else?
>
> Thanks! -Neil

So your isp does not want you to do masquerading. I would recommend
_not_ to do this.

EJ
--
Remove the obvious part (including the dot) for my email address

David <thunderbolt01@netscape.net> writes:

> Neil Sandow wrote:
>> My ISP has asked me to block all incoming and outgoing traffic on my
>> Linux Director for tcp ports > 60,000 I tried and managed to block
>> all ports and had to reboot. This is what I tried (I think)
>> ipchains -A input --sport 60000:65535 -p -j DENY
>> at which point everything went blank.
>> Does anybody know the correct syntax to just block that range of ports
>> (in and out) without affecting anything else?
>
> What is your ISP wanting you to block those ports?
>
> ??? ipchains ???
> Most be an older distro.

I was rather wondering why, as well - are they trying to clamp-down on some
preposterous anti-masquerading rule of theirs, perhaps?

If so, it should be noted that the range of ports used for outgoing masq
source-ports is user-configurable... :)

~Tim
--
Rushing onwards, tracing the chains, |piglet@stirfried.vegetable.org.uk
Chasing the days, chasing the days. |http://spodzone.org.uk/

Yes, it is an older dist. and since it's working I've been reluctant to
upgrade (aint broke...)

We got a an e-mail from abuse@somewhere that my ipaddress was
probing/scanning their ports and they sent along a log file which showed
my ip and the originating port which was alwasy > 60,000. I have no
idea whether any of this is real and I seriously doubt that this is
really coming from my machine but the engineer tells me that it's
possible I could have some 'microcode' running that would be next to
impossible to detect and his recommendation was to simply block those
high port numbers.

-Neil

Tim Haynes wrote:
>
> David <thunderbolt01@netscape.net> writes:
>
> > Neil Sandow wrote:
> >> My ISP has asked me to block all incoming and outgoing traffic on my
> >> Linux Director for tcp ports > 60,000 I tried and managed to block
> >> all ports and had to reboot. This is what I tried (I think)
> >> ipchains -A input --sport 60000:65535 -p -j DENY
> >> at which point everything went blank.
> >> Does anybody know the correct syntax to just block that range of ports
> >> (in and out) without affecting anything else?
> >
> > What is your ISP wanting you to block those ports?
> >
> > ??? ipchains ???
> > Most be an older distro.
>
> I was rather wondering why, as well - are they trying to clamp-down on some
> preposterous anti-masquerading rule of theirs, perhaps?
>
> If so, it should be noted that the range of ports used for outgoing masq
> source-ports is user-configurable... :)
>
> ~Tim
> --
> Rushing onwards, tracing the chains, |piglet@stirfried.vegetable.org.uk
> Chasing the days, chasing the days. |http://spodzone.org.uk/

Tim Haynes wrote:
>
> David <thunderbolt01@netscape.net> writes:
>
> > Neil Sandow wrote:
> >> My ISP has asked me to block all incoming and outgoing traffic on my
> >> Linux Director for tcp ports > 60,000
> > What is your ISP wanting you to block those ports?

> I was rather wondering why, as well - are they trying to clamp-down on some
> preposterous anti-masquerading rule of theirs, perhaps?
>
> If so, it should be noted that the range of ports used for outgoing masq
> source-ports is user-configurable... :)

And that the source port number used by non-masqueraded traffic is
undefined except that it is within
/proc/sys/net/ipv4/ip_local_port_range or the equivalent in other OSs;
and that this is also configurable in most OSs these days (including
Linux of course). And in many it includes 60000 - 65535 by default, even
if it doesn't in most Linux systems. I have a copy of SuSE Enterprise
Server 8 here for instance, and its default ephemeral range is
32768-61000. Solaris's default is 32768-65535 as is AIX's nowadays.

If this is an attempt by an ISP to prevent customers using many-to-one
NAT (whatever you like to call it) then I agree, this is seriously brain
dead and is bound to backfire. The OP is advised not to comply.

Regards, Ian

Neil Sandow wrote:
>
> Thanks, David! I'll wait a little while to see if anybody pops up and
> says, wait, do that and this will happen, otherwise I'll put this in
> place tonight. -Neil

If the system has been cracked then you need to fix it instead of
blocking ports. Though you probably already know that.
You might want to run chkrootkit on it to see if it finds
anything if you haven't already.

--
Confucius: He who play in root, eventually kill tree.
Registered with The Linux Counter. http://counter.li.org/
Slackware 9.0 Kernel 2.4.22 i686 (GCC) 3.3
Uptime: 1 day, 0 min, 1 user, load average: 1.11, 1.21, 1.23

David <thunderbolt01@netscape.net> wrote in message news:<s2S2b.105978$2x.30473@rwcrnsc52.ops.asp.att. net>...
> Neil Sandow wrote:
> >
> > Thanks, David! I'll wait a little while to see if anybody pops up and
> > says, wait, do that and this will happen, otherwise I'll put this in
> > place tonight. -Neil
>
> If the system has been cracked then you need to fix it instead of
> blocking ports. Though you probably already know that.
> You might want to run chkrootkit on it to see if it finds
> anything if you haven't already.

It's sounding like blocking the ports is an unwise idea and checking
for signs of compromise is the way to go. Thanks for the suggestion
to run chkrootkit as I've never used it before. After running it, I
find one interesting message:

Checking `lkm'... You have 27 process hidden for ps command
Warning: Possible LKM Trojan installed

When I run ./chkrootkit -x lkm it shows me the processes and when I
check the output of ps (ps -edf or ps aux) I see all the same
processes id's. I've read that you can get false positives for short
lived processes that may have finished while chkrootkit is running but
these are all stable running processes such as init, sshd, mingetty,
etc. I'm not sure why I'm getting this error since ps and chkproc
both show identical process id's. -Neil

rx@rxlist.com (Neil Sandow) writes:

> It's sounding like blocking the ports is an unwise idea and checking for
> signs of compromise is the way to go. Thanks for the suggestion to run
> chkrootkit as I've never used it before. After running it, I find one
> interesting message:
>
> Checking `lkm'... You have 27 process hidden for ps command Warning:
> Possible LKM Trojan installed

Ach, pants. I'd be worried, if I were you.

Next question: does that persist on subsequent runs? Does the number vary,
if so, by how much?

> When I run ./chkrootkit -x lkm it shows me the processes and when I check
> the output of ps (ps -edf or ps aux) I see all the same processes id's.
> I've read that you can get false positives for short lived processes that
> may have finished while chkrootkit is running but these are all stable
> running processes such as init, sshd, mingetty, etc. I'm not sure why I'm
> getting this error since ps and chkproc both show identical process id's.

How about `ls /proc/[0-9]* | wc -l' and compare that with `ps auxww | wc -l'
several times over?

Do both a
netstat -plant | grep LISTEN
and nmap your box remotely - all ports - and compare what it thinks are
listening.

Also you need to monitor traffic going out - preferably by inserting a hub
just adjacent to the machine with another box listening in promiscuous mode
to what's going past. Also, snort would be an idea. If you can't place a
sniffing box in the way, run snort on the box itself and configure it to
look for port-scans and dodgy outgoing traffic.

~Tim
--
21:00:08 up 82 days, 11:36, 10 users, load average: 0.66, 0.47, 0.23
piglet@stirfried.vegetable.org.uk |Newton and Adam, lost and found,
http://piglet.is.dreaming.org |The apple must fall to the ground

Neil Sandow wrote:

> David <thunderbolt01@netscape.net> wrote in message
> news:<s2S2b.105978$2x.30473@rwcrnsc52.ops.asp.att. net>...
>> Neil Sandow wrote:
>> >
>> > Thanks, David! I'll wait a little while to see if anybody pops up
>> > and says, wait, do that and this will happen, otherwise I'll put
>> > this in
>> > place tonight. -Neil
>>
>> If the system has been cracked then you need to fix it instead of
>> blocking ports. Though you probably already know that.
>> You might want to run chkrootkit on it to see if it finds
>> anything if you haven't already.
>
> It's sounding like blocking the ports is an unwise idea and checking
> for signs of compromise is the way to go. Thanks for the suggestion
> to run chkrootkit as I've never used it before. After running it, I
> find one interesting message:
>
> Checking `lkm'... You have 27 process hidden for ps command
> Warning: Possible LKM Trojan installed
>
> When I run ./chkrootkit -x lkm it shows me the processes and when I
> check the output of ps (ps -edf or ps aux) I see all the same
> processes id's. I've read that you can get false positives for short
> lived processes that may have finished while chkrootkit is running but
> these are all stable running processes such as init, sshd, mingetty,
> etc. I'm not sure why I'm getting this error since ps and chkproc
> both show identical process id's. -Neil

Given the fact that you run an old distribution chances are that you did
not update all running services on your machine. I would guess that
your machine does have problems. Disconnect now. Investigate further.
Assume that hosts behind your machine are also compromised. That would
account for the masqueraded hosts.

EJ
--
Remove the obvious part (including the dot) for my email address

erik wrote:
> Neil Sandow wrote:
>
>
>>David <thunderbolt01@netscape.net> wrote in message
>>news:<s2S2b.105978$2x.30473@rwcrnsc52.ops.asp.at t.net>...
>>
>>>Neil Sandow wrote:
>>>
>>>>Thanks, David! I'll wait a little while to see if anybody pops up
>>>>and says, wait, do that and this will happen, otherwise I'll put
>>>>this in
>>>>place tonight. -Neil
>>>
>>>If the system has been cracked then you need to fix it instead of
>>>blocking ports. Though you probably already know that.
>>>You might want to run chkrootkit on it to see if it finds
>>>anything if you haven't already.
>>
>>It's sounding like blocking the ports is an unwise idea and checking
>>for signs of compromise is the way to go. Thanks for the suggestion
>>to run chkrootkit as I've never used it before. After running it, I
>>find one interesting message:
>>
>>Checking `lkm'... You have 27 process hidden for ps command
>>Warning: Possible LKM Trojan installed
>>
>>When I run ./chkrootkit -x lkm it shows me the processes and when I
>>check the output of ps (ps -edf or ps aux) I see all the same
>>processes id's. I've read that you can get false positives for short
>>lived processes that may have finished while chkrootkit is running but
>>these are all stable running processes such as init, sshd, mingetty,
>>etc. I'm not sure why I'm getting this error since ps and chkproc
>>both show identical process id's. -Neil
>
>
> Given the fact that you run an old distribution chances are that you did
> not update all running services on your machine. I would guess that
> your machine does have problems. Disconnect now. Investigate further.
> Assume that hosts behind your machine are also compromised. That would
> account for the masqueraded hosts.
>
> EJ


If I disconnect now my entire site goes down and I'd only do that under
extreme circumstances knowing that I had something terrible going on.
It's a high traffic public website. This linux box was built from
scratch a couple of years ago using Mandrake 2.2.17 and the kernel was
rebuilt to include LVS which is its sole purpose. (Maybe it's time
to build a new, clean LVS with the latest code.)

I've checked the freebsd servers behind the linux box with chkrootkit
and everything seems fine with them.

I'm still not getting why chkproc is complaining about processes that
are clearly visible under ps. -Neil