public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Simon Waters <Simon@wretched.demon.co.uk>
To: linux-kernel@vger.kernel.org
Subject: Progress Re: IP DoS on 2.2.17
Date: Tue, 10 Jul 2001 13:34:20 +0100	[thread overview]
Message-ID: <3B4AF64C.B801E8DB@wretched.demon.co.uk> (raw)
In-Reply-To: <3B48829E.1975F8E4@wretched.demon.co.uk>

Simon Waters wrote:
> 
> Please excuse a post from a non-member, but this seems the
> most suitable place I could find. Please e-mail me any
> thoughts, and I'll summarise if I make any progress.

The problem also occurs with 2.2.19. 

Symptoms are identical, following some sort of port scan,
outgoing packets are dropped until you remove kernel modules
down to and including slhc.

Demon users report a steady drip of problems related to
compression of ISDN and Linux, including today a panic - I'm
digging there for kernel versions etc.

I'm going to mindlessly stare at the source code for slhc.c
and see if I'm inspired.
 
> Should I upgrade to 2.2.19 and hope it goes away?

It doesn't.
 
> Any one any idea on the scanner in use? If I could reproduce
> the problem at will I'd be in a better position to analyse
> what is happening.

No news here. 

I haven't found any neat tools either - pondering netcat and
portsentry, netcat at least lets me run an arbitary program
on receipt of an arbitary UDP IP packet, I guess I was
hoping for something like IPtrap that sets TCPHOPSTIP before
running an arbitary program....

I'll try hacking netcat's GAPING_SECURITY_HOLE section....

However if it is slhc.c getting muddled it could be a
combination of packets, rather than just one bad egg. This
is all a bit lower than the kind of IP problems I usually
deal with.

Meanwhile maybe I'll tcpdump the port 111 traffic, and see
if the PEN-TEST list guys know what is hitting me.
 
> I don't understand why I am the only one seeing this (I
> found some promising references, only to find they were many
> kernel revisions out of date) - it is a very infrequent
> problem (Despite seeing scans against port 111 every few
> hours, I've only seen this problem a handful of times).
> 
> Maybe others just assume it is yet another ISP problem and
> reboot?!, but the ability to only get incoming packets is
> rather distinctive (Although I only spotted this as I
> happened to have pload running).

I'm siding more with the nobody else has figured out what is
wrong school of thought, and perhaps it only occurs with
specific configurations.

Replies as before by e-mail - thanks for the two replies so
far. Good ideas both.

	Simon

      reply	other threads:[~2001-07-10 12:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-08 15:56 IP DoS on 2.2.17 Simon Waters
2001-07-10 12:34 ` Simon Waters [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B4AF64C.B801E8DB@wretched.demon.co.uk \
    --to=simon@wretched.demon.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox