Re: Bad loopback traffic not stopped by ipfw.

2004-03-02 Thread Ian Smith
On Tue, 2 Mar 2004, Tony Frank wrote: > Bit of a delayed response I'm afraid - PC troubles. No worries, and thanks for that. Curiousity sated, nothing to fix, no way to track their real source on $oif anyway, so moving along .. > > > > I> >deny tcp from any to any tcpflags rst,ack > > > >

Re: Bad loopback traffic not stopped by ipfw.

2004-03-01 Thread Tony Frank
Hi, Bit of a delayed response I'm afraid - PC troubles. On Sun, Feb 29, 2004 at 01:28:23AM +1100, Ian Smith wrote: > On Sat, 28 Feb 2004, Tony Frank wrote (in [EMAIL PROTECTED]): > > > On Wed, Feb 25, 2004 at 05:21:34PM +0300, Gleb Smirnoff wrote: > > > On Wed, Feb 25, 2004 at 04:19:51PM +0200

Re: Bad loopback traffic not stopped by ipfw.

2004-02-27 Thread Tony Frank
Hi all, On Wed, Feb 25, 2004 at 05:21:34PM +0300, Gleb Smirnoff wrote: > On Wed, Feb 25, 2004 at 04:19:51PM +0200, Iasen Kostov wrote: > I> >>16:26:23.287642 0:1:2:9>c:cf:e2 0:02:55:b0:90:e4 0800 60: 127.0.0.1.80 > > I> >>192.168.118.205.1046: R 0:0(0) ack 1959723009 win 0 > I> > > I> >This is so

Re: Bad loopback traffic not stopped by ipfw.

2004-02-25 Thread Iasen Kostov
Andrea Venturoli wrote: ** Reply to note from Gleb Smirnoff <[EMAIL PROTECTED]> Wed, 25 Feb 2004 17:21:34 +0300 P.S. This is really off-topic already. We should move to -isp@ may be. I don't really think so, why would it be? It's concerning ipfw, netstat, traffic and the IP stack in gener

Re: Bad loopback traffic not stopped by ipfw.

2004-02-25 Thread Andrea Venturoli
** Reply to note from Gleb Smirnoff <[EMAIL PROTECTED]> Wed, 25 Feb 2004 17:21:34 +0300 > P.S. This is really off-topic already. We should move to -isp@ may be. I don't really think so, why would it be? It's concerning ipfw, netstat, traffic and the IP stack in general, I believe. N.B. I'm obvi

Re: Bad loopback traffic not stopped by ipfw.

2004-02-25 Thread Gleb Smirnoff
On Wed, Feb 25, 2004 at 04:19:51PM +0200, Iasen Kostov wrote: I> >>16:26:23.287642 0:1:2:9>c:cf:e2 0:02:55:b0:90:e4 0800 60: 127.0.0.1.80 > I> >>192.168.118.205.1046: R 0:0(0) ack 1959723009 win 0 I> > I> >This is some kind of Win32 virus. This floods can be easily I> >stopped by ipfw rule: I> > I

Re: Bad loopback traffic not stopped by ipfw.

2004-02-25 Thread Iasen Kostov
Gleb Smirnoff wrote: On Wed, Feb 25, 2004 at 04:47:03PM +0300, Andrew Riabtsev wrote: A> To me it would be also interesting to know where this traffic comes A> from. I have same on my local net: A> A> # tcpdump -neifxp0 src or dst 127.0.0.1 A> tcpdump: listening on fxp0 A> 16:26:23.280737 0:50:fc

Re: Bad loopback traffic not stopped by ipfw.

2004-02-25 Thread Gleb Smirnoff
On Wed, Feb 25, 2004 at 04:47:03PM +0300, Andrew Riabtsev wrote: A> To me it would be also interesting to know where this traffic comes A> from. I have same on my local net: A> A> # tcpdump -neifxp0 src or dst 127.0.0.1 A> tcpdump: listening on fxp0 A> 16:26:23.280737 0:50:fc:ed:d4:4 0:02:55:b0:90

Re: Bad loopback traffic not stopped by ipfw.

2004-02-25 Thread Iasen Kostov
Andrew Riabtsev wrote: Привет Iasen, Wednesday, February 25, 2004, 3:37:25 PM, you wrote: IK> netstat -s -p ip IK> . IK> . IK> . IK> 3575124 datagrams with bad address in header IK> Could it be this that drops "bad" packets before they enter the IPFW ? To me it would be also interes

Re[2]: Bad loopback traffic not stopped by ipfw.

2004-02-25 Thread Andrew Riabtsev
Привет Iasen, Wednesday, February 25, 2004, 3:37:25 PM, you wrote: IK> netstat -s -p ip IK> . IK> . IK> . IK> 3575124 datagrams with bad address in header IK> Could it be this that drops "bad" packets before they enter the IPFW ? To me it would be also interesting to know where this

Re: Bad loopback traffic not stopped by ipfw.

2004-02-25 Thread Andrea Venturoli
** Reply to note from Iasen Kostov <[EMAIL PROTECTED]> Wed, 25 Feb 2004 14:37:25 +0200 >netstat -s -p ip >.. >.. >.. >3575124 datagrams with bad address in header > >Could it be this that drops "bad" packets before they enter the IPFW ? Nice, it could be, but I'm not so expert as to

Re: Bad loopback traffic not stopped by ipfw.

2004-02-25 Thread Iasen Kostov
netstat -s -p ip . . . 3575124 datagrams with bad address in header Could it be this that drops "bad" packets before they enter the IPFW ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe,

Re: Bad loopback traffic not stopped by ipfw.

2004-02-24 Thread Andrea Venturoli
** Reply to note from Ian Smith <[EMAIL PROTECTED]> Wed, 25 Feb 2004 06:41:08 +1100 (EST) > ... still dribbling in I see. Yawn. But they're being denied ok here. But it is not so here! And also someone else reported the same problem... > Try just 'deny log ip from 127.0.0.0/8 to any' (and

Re: Bad loopback traffic not stopped by ipfw.

2004-02-24 Thread Ian Smith
On Tue, 24 Feb 2004, Andrea Venturoli wrote: > 4.8-RELEASE-p15: ipfw1? > In /var/log/all.log I get a lot of: > > snort: [1:528:4] BAD-TRAFFIC loopback traffic [Classification: > Potentially Bad Traffic] [Priority: 2]: {TCP} > 127.0.0.1:80 -> xx.xx.xx.xx:1055 > > (src port is always 80,

Re: Bad loopback traffic not stopped by ipfw.

2004-02-24 Thread Andrea Venturoli
** Reply to note from Barney Wolff <[EMAIL PROTECTED]> Tue, 24 Feb 2004 12:30:23 -0500 >> IMHO opinion wrong packets are arriving >> from the upstream router (for which it >> would be useless to ask for a fix), > Your first three rules, before anything else, should be: > allow ip from any to an

Re: Bad loopback traffic not stopped by ipfw.

2004-02-24 Thread Barney Wolff
On Tue, Feb 24, 2004 at 05:11:22PM -0500, Andrea Venturoli wrote: > IMHO opinion wrong packets are arriving from the upstream router (for which it would > be useless to ask for a fix), Your first three rules, before anything else, should be: allow ip from any to any via lo0 deny log logamount 100

Bad loopback traffic not stopped by ipfw.

2004-02-24 Thread Andrea Venturoli
Hello. 4.8-RELEASE-p15: In /var/log/all.log I get a lot of: snort: [1:528:4] BAD-TRAFFIC loopback traffic [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 127.0.0.1:80 -> xx.xx.xx.xx:1055 (src port is always 80, dst port changes, xx.xx.xx.xx is my tun0 IP.) ifconfig -a gives: