RE: simple rules and unexpected traffic

RE: simple rules and unexpected traffic

[George Vieira]

So why are you allowing any other device being allowed, please tell me your
not running PPPoE for adsl or something.. this means your network is open
then.....

thanks,
George Vieira
Systems Manager
Citadel Computer Systems P/L
http://www.citadelcomputer.com.au



-----Original Message-----
From: christophe barbé [mailto:christophe.barbe.ml@online.fr]
Sent: Friday, 05 July 2002 9:47 AM
To: netfilter@lists.samba.org
Subject: Re: simple rules and unexpected traffic


On Fri, Jul 05, 2002 at 09:44:36AM +1000, George Vieira wrote:
> Have you got any packet counts for the DROPped rules??

no.

> I'm still a bit stumped on the
> 
> -A block -i ! eth0 -m state --state NEW -j ACCEPT 
> 
> as what other devices do you have???

I have only eth0 and lo.

Christophe


> 
> thanks,
> George Vieira
> Systems Manager
> Citadel Computer Systems P/L
> http://www.citadelcomputer.com.au
> 
> 
> 
> -----Original Message-----
> From: christophe barbé [mailto:christophe.barbe.ml@online.fr]
> Sent: Friday, 05 July 2002 8:57 AM
> To: netfilter@lists.samba.org
> Subject: Re: simple rules and unexpected traffic
> 
> 
> On Fri, Jul 05, 2002 at 12:54:36AM +0200, Jan Humme wrote:
> > On Friday 05 July 2002 00:45, christophe barbé wrote:
> > > On Fri, Jul 05, 2002 at 08:35:53AM +1000, George Vieira wrote:
> > > > Yes I've found that some user space programs can see stuff before
> > > > iptables.. tcpdump too I think...
> > >
> > > Yes it sounds logical for tcpdump or tools like that (which pass the
> > > interface in promiscuisious mode) to see everything. I was not
expecting
> > > the same from a unprivileged app like gkrellm.
> > > It is stil unclear for me what is the data processing path.
> > >
> > > Has someone a clear picture of the packets path ?
> > 
> > It is no problem to open a socket and receive a copy of all raw packets 
> > before they get to the kernel iptables modules. See "man 7 packet" for 
> > details.
> > 
> > I believe this is how tcpdump does it too.
> 
> Ok it sounds logical.
> Now the question is what is dropping these packets ? Apparently not
> rp_filter, and not netfilter because I see no log for it.
> 
> Christophe
> 
> > 
> > Jan Humme.
> 
> -- 
> Christophe Barbé <christophe.barbe@ufies.org>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> 
> Imagination is more important than knowledge.
>    Albert Einstein, On Science

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

L'experience, c'est une connerie par jour mais jamais la même.

Re: simple rules and unexpected traffic

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 3366 bytes --]

On Fri, Jul 05, 2002 at 09:54:04AM +1000, George Vieira wrote:
> So why are you allowing any other device being allowed, please tell me your
> not running PPPoE for adsl or something.. this means your network is open
> then.....

No I am not using PPPoE. I have a plain normal ethernet connection with
an static IP.

What would you use instead of '! eth0' ?

NOTE: I know that my network is not open. It's very easy to verify,
starting with pinging myself from outside.

Christophe


> 
> thanks,
> George Vieira
> Systems Manager
> Citadel Computer Systems P/L
> http://www.citadelcomputer.com.au
> 
> 
> 
> -----Original Message-----
> From: christophe barbé [mailto:christophe.barbe.ml@online.fr]
> Sent: Friday, 05 July 2002 9:47 AM
> To: netfilter@lists.samba.org
> Subject: Re: simple rules and unexpected traffic
> 
> 
> On Fri, Jul 05, 2002 at 09:44:36AM +1000, George Vieira wrote:
> > Have you got any packet counts for the DROPped rules??
> 
> no.
> 
> > I'm still a bit stumped on the
> > 
> > -A block -i ! eth0 -m state --state NEW -j ACCEPT 
> > 
> > as what other devices do you have???
> 
> I have only eth0 and lo.
> 
> Christophe
> 
> 
> > 
> > thanks,
> > George Vieira
> > Systems Manager
> > Citadel Computer Systems P/L
> > http://www.citadelcomputer.com.au
> > 
> > 
> > 
> > -----Original Message-----
> > From: christophe barbé [mailto:christophe.barbe.ml@online.fr]
> > Sent: Friday, 05 July 2002 8:57 AM
> > To: netfilter@lists.samba.org
> > Subject: Re: simple rules and unexpected traffic
> > 
> > 
> > On Fri, Jul 05, 2002 at 12:54:36AM +0200, Jan Humme wrote:
> > > On Friday 05 July 2002 00:45, christophe barbé wrote:
> > > > On Fri, Jul 05, 2002 at 08:35:53AM +1000, George Vieira wrote:
> > > > > Yes I've found that some user space programs can see stuff before
> > > > > iptables.. tcpdump too I think...
> > > >
> > > > Yes it sounds logical for tcpdump or tools like that (which pass the
> > > > interface in promiscuisious mode) to see everything. I was not
> expecting
> > > > the same from a unprivileged app like gkrellm.
> > > > It is stil unclear for me what is the data processing path.
> > > >
> > > > Has someone a clear picture of the packets path ?
> > > 
> > > It is no problem to open a socket and receive a copy of all raw packets 
> > > before they get to the kernel iptables modules. See "man 7 packet" for 
> > > details.
> > > 
> > > I believe this is how tcpdump does it too.
> > 
> > Ok it sounds logical.
> > Now the question is what is dropping these packets ? Apparently not
> > rp_filter, and not netfilter because I see no log for it.
> > 
> > Christophe
> > 
> > > 
> > > Jan Humme.
> > 
> > -- 
> > Christophe Barbé <christophe.barbe@ufies.org>
> > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> > 
> > Imagination is more important than knowledge.
> >    Albert Einstein, On Science
> 
> -- 
> Christophe Barbé <christophe.barbe@ufies.org>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> 
> L'experience, c'est une connerie par jour mais jamais la même.
> 

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Dogs believe they are human. Cats believe they are God.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: simple rules and unexpected traffic

[George Vieira]

Have you got any packet counts for the DROPped rules??

I'm still a bit stumped on the

-A block -i ! eth0 -m state --state NEW -j ACCEPT 

as what other devices do you have???

thanks,
George Vieira
Systems Manager
Citadel Computer Systems P/L
http://www.citadelcomputer.com.au



-----Original Message-----
From: christophe barbé [mailto:christophe.barbe.ml@online.fr]
Sent: Friday, 05 July 2002 8:57 AM
To: netfilter@lists.samba.org
Subject: Re: simple rules and unexpected traffic


On Fri, Jul 05, 2002 at 12:54:36AM +0200, Jan Humme wrote:
> On Friday 05 July 2002 00:45, christophe barbé wrote:
> > On Fri, Jul 05, 2002 at 08:35:53AM +1000, George Vieira wrote:
> > > Yes I've found that some user space programs can see stuff before
> > > iptables.. tcpdump too I think...
> >
> > Yes it sounds logical for tcpdump or tools like that (which pass the
> > interface in promiscuisious mode) to see everything. I was not expecting
> > the same from a unprivileged app like gkrellm.
> > It is stil unclear for me what is the data processing path.
> >
> > Has someone a clear picture of the packets path ?
> 
> It is no problem to open a socket and receive a copy of all raw packets 
> before they get to the kernel iptables modules. See "man 7 packet" for 
> details.
> 
> I believe this is how tcpdump does it too.

Ok it sounds logical.
Now the question is what is dropping these packets ? Apparently not
rp_filter, and not netfilter because I see no log for it.

Christophe

> 
> Jan Humme.

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Imagination is more important than knowledge.
   Albert Einstein, On Science

Re: simple rules and unexpected traffic

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]

On Fri, Jul 05, 2002 at 09:44:36AM +1000, George Vieira wrote:
> Have you got any packet counts for the DROPped rules??

no.

> I'm still a bit stumped on the
> 
> -A block -i ! eth0 -m state --state NEW -j ACCEPT 
> 
> as what other devices do you have???

I have only eth0 and lo.

Christophe


> 
> thanks,
> George Vieira
> Systems Manager
> Citadel Computer Systems P/L
> http://www.citadelcomputer.com.au
> 
> 
> 
> -----Original Message-----
> From: christophe barbé [mailto:christophe.barbe.ml@online.fr]
> Sent: Friday, 05 July 2002 8:57 AM
> To: netfilter@lists.samba.org
> Subject: Re: simple rules and unexpected traffic
> 
> 
> On Fri, Jul 05, 2002 at 12:54:36AM +0200, Jan Humme wrote:
> > On Friday 05 July 2002 00:45, christophe barbé wrote:
> > > On Fri, Jul 05, 2002 at 08:35:53AM +1000, George Vieira wrote:
> > > > Yes I've found that some user space programs can see stuff before
> > > > iptables.. tcpdump too I think...
> > >
> > > Yes it sounds logical for tcpdump or tools like that (which pass the
> > > interface in promiscuisious mode) to see everything. I was not expecting
> > > the same from a unprivileged app like gkrellm.
> > > It is stil unclear for me what is the data processing path.
> > >
> > > Has someone a clear picture of the packets path ?
> > 
> > It is no problem to open a socket and receive a copy of all raw packets 
> > before they get to the kernel iptables modules. See "man 7 packet" for 
> > details.
> > 
> > I believe this is how tcpdump does it too.
> 
> Ok it sounds logical.
> Now the question is what is dropping these packets ? Apparently not
> rp_filter, and not netfilter because I see no log for it.
> 
> Christophe
> 
> > 
> > Jan Humme.
> 
> -- 
> Christophe Barbé <christophe.barbe@ufies.org>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> 
> Imagination is more important than knowledge.
>    Albert Einstein, On Science

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

L'experience, c'est une connerie par jour mais jamais la même.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: simple rules and unexpected traffic

[George Vieira]

Yes I've found that some user space programs can see stuff before iptables..
tcpdump too I think...

1 question: if it's not eth0 what other device is there (-i ! eth0 -m state
--state NEW -j ACCEPT) ???
Are you running PPPoE or something because this will bring up a ppp0 device
which will accept ALL packets with that rule above...

Have I missed something here, or am I correct?

thanks,
George Vieira
Systems Manager
Citadel Computer Systems P/L
http://www.citadelcomputer.com.au



-----Original Message-----
From: christophe barbé [mailto:christophe.barbe.ml@online.fr]
Sent: Friday, 05 July 2002 7:02 AM
To: netfilter@lists.samba.org
Subject: Re: simple rules and unexpected traffic


I have found at http://www.cavebear.com/CaveBear/Ethernet/multicast.html
that ff:ff:ff:ff:0:30 could be a multicast ethernet address
(03-00-FF-FF-FF-FF) for 'All Stations Address'.

Is it something commonly used by script kiddies ?

If I undersatnd correctly, nothing has changed at the router, but
somebody connected at the same router is doing bad stuff. Is it right ?

What I still don't understand is why I can see this traffic with my
iptables rules. Is the traffic exposed (to user-space tools) before
entering the iptables processing ?

Christophe

On Thu, Jul 04, 2002 at 10:10:48AM -0400, christophe barbé wrote:
> Hi,
> 
> I use a simple set of iptables rules for my laptop to reject everything
> from outside using ip_conntrack (from the howto) :
> 
> # Generated by iptables-save v1.2.6a on Thu Jul  4 09:54:11 2002
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [43965:4118502]
> :block - [0:0]
> -A INPUT -j block 
> -A FORWARD -j block 
> -A block -m state --state RELATED,ESTABLISHED -j ACCEPT 
> -A block -i ! eth0 -m state --state NEW -j ACCEPT 
> -A block -i eth0 -m limit --limit 3/hour -j LOG --log-prefix "Bad packet
from eth0:" 
> -A block -i ! eth0 -m limit --limit 3/hour -j LOG --log-prefix "Bad packet
not from eth0:" 
> -A block -j DROP 
> COMMIT
> # Completed on Thu Jul  4 09:54:11 2002
> 
> I have a ADSL connection and only a hub between my laptop and the
> ADSL-modem. Recently something changed, I guess on the router from my
> provider and now I see unexpected traffic.
> 
> I see it with the eth0 monitor in gkrellm and with iftop but not with
> lsof -i.
> I was not expecting this traffic and the pattern seems strange : a
> constant 20kB incoming traffic during a few seconds. So I started
> looking closer. With ethereal I saw that it was a kind of flooding
> most of the time a lot of SYN packet but also netbios ....
> Each time both IPs are not one of my computer. For example I see during
> one of this flooding with 'tcpdump -c 2 -e'
> 
> tcpdump: listening on eth0
> 10:00:39.946940 0:0:c:c3:a:88 ff:ff:ff:ff:0:30 ip 62:
216-203-233-196.customer.algx.net.3574 >
adsl-216-158-52-76.cust.oldcity.dca.net.www: S 2011680397:2011680397(0) win
16384 <mss 1460,nop,nop,sackOK> (DF)
> 10:00:39.949401 0:0:c:c3:a:88 ff:ff:ff:ff:0:30 ip 62:
216-203-233-196.customer.algx.net.3574 >
adsl-216-158-52-76.cust.oldcity.dca.net.www: S 2011680397:2011680397(0) win
16384 <mss 1460,nop,nop,sackOK> (DF)
>  
> I am not sure how to interpret 'ff:ff:ff:ff:0:30' is it a kind of
> broadcasting at the ethernet level ?
> 
> Why can I see these packets that are not for me ?
> 
> Why this traffic is not dropped by netfilter ? 
> 
> It seems to be a miss-configuration of my ISP router, no ? I believe it's
> harmless (except for my bandwidth) but I don't understand why I see
> (with gkrellm) this traffic which seems to be rejected before netfilter.
> Is gkrellm using packets information before the iptable processing ?
> 
> I have tried to set /proc/.../eth0/rp_filter to 0 without any
> difference.
> 
> Thanks,
> Christophe
> 
> -- 
> Christophe Barbé <christophe.barbe@ufies.org>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> 
> Dogs come when they're called;
> cats take a message and get back to you later. --Mary Bly



-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Dogs believe they are human. Cats believe they are God.

Re: simple rules and unexpected traffic

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 5785 bytes --]

On Fri, Jul 05, 2002 at 08:35:53AM +1000, George Vieira wrote:
> Yes I've found that some user space programs can see stuff before iptables..
> tcpdump too I think...

Yes it sounds logical for tcpdump or tools like that (which pass the
interface in promiscuisious mode) to see everything. I was not expecting
the same from a unprivileged app like gkrellm.
It is stil unclear for me what is the data processing path.

Has someone a clear picture of the packets path ? 

> 1 question: if it's not eth0 what other device is there (-i ! eth0 -m state
> --state NEW -j ACCEPT) ???
> Are you running PPPoE or something because this will bring up a ppp0 device
> which will accept ALL packets with that rule above...

No no, I have only eth0 with a pure tcp/ip connection wwith a static ip.
As I understand it packets are rejected because they are not for me and
this reject is done before netfilter. At a time i believed it was the
job of rp_filter (which checks if the packet is really for you) but
reseting rp_filter change nothing.

> Have I missed something here, or am I correct?

I only have eth0 and I am convinced that all stranges packets are
dropped before entering the netfilter stage.

My current understanding is that someone in my neighborough plugged on
the same router is doing some nasty flooding (perhaps a compromised
computer) and my provider doesn't answer to my mails (I guess because
today is May 4th). 

Christophe

> thanks,
> George Vieira
> Systems Manager
> Citadel Computer Systems P/L
> http://www.citadelcomputer.com.au
> 
> 
> 
> -----Original Message-----
> From: christophe barbé [mailto:christophe.barbe.ml@online.fr]
> Sent: Friday, 05 July 2002 7:02 AM
> To: netfilter@lists.samba.org
> Subject: Re: simple rules and unexpected traffic
> 
> 
> I have found at http://www.cavebear.com/CaveBear/Ethernet/multicast.html
> that ff:ff:ff:ff:0:30 could be a multicast ethernet address
> (03-00-FF-FF-FF-FF) for 'All Stations Address'.
> 
> Is it something commonly used by script kiddies ?
> 
> If I undersatnd correctly, nothing has changed at the router, but
> somebody connected at the same router is doing bad stuff. Is it right ?
> 
> What I still don't understand is why I can see this traffic with my
> iptables rules. Is the traffic exposed (to user-space tools) before
> entering the iptables processing ?
> 
> Christophe
> 
> On Thu, Jul 04, 2002 at 10:10:48AM -0400, christophe barbé wrote:
> > Hi,
> > 
> > I use a simple set of iptables rules for my laptop to reject everything
> > from outside using ip_conntrack (from the howto) :
> > 
> > # Generated by iptables-save v1.2.6a on Thu Jul  4 09:54:11 2002
> > *filter
> > :INPUT ACCEPT [0:0]
> > :FORWARD ACCEPT [0:0]
> > :OUTPUT ACCEPT [43965:4118502]
> > :block - [0:0]
> > -A INPUT -j block 
> > -A FORWARD -j block 
> > -A block -m state --state RELATED,ESTABLISHED -j ACCEPT 
> > -A block -i ! eth0 -m state --state NEW -j ACCEPT 
> > -A block -i eth0 -m limit --limit 3/hour -j LOG --log-prefix "Bad packet
> from eth0:" 
> > -A block -i ! eth0 -m limit --limit 3/hour -j LOG --log-prefix "Bad packet
> not from eth0:" 
> > -A block -j DROP 
> > COMMIT
> > # Completed on Thu Jul  4 09:54:11 2002
> > 
> > I have a ADSL connection and only a hub between my laptop and the
> > ADSL-modem. Recently something changed, I guess on the router from my
> > provider and now I see unexpected traffic.
> > 
> > I see it with the eth0 monitor in gkrellm and with iftop but not with
> > lsof -i.
> > I was not expecting this traffic and the pattern seems strange : a
> > constant 20kB incoming traffic during a few seconds. So I started
> > looking closer. With ethereal I saw that it was a kind of flooding
> > most of the time a lot of SYN packet but also netbios ....
> > Each time both IPs are not one of my computer. For example I see during
> > one of this flooding with 'tcpdump -c 2 -e'
> > 
> > tcpdump: listening on eth0
> > 10:00:39.946940 0:0:c:c3:a:88 ff:ff:ff:ff:0:30 ip 62:
> 216-203-233-196.customer.algx.net.3574 >
> adsl-216-158-52-76.cust.oldcity.dca.net.www: S 2011680397:2011680397(0) win
> 16384 <mss 1460,nop,nop,sackOK> (DF)
> > 10:00:39.949401 0:0:c:c3:a:88 ff:ff:ff:ff:0:30 ip 62:
> 216-203-233-196.customer.algx.net.3574 >
> adsl-216-158-52-76.cust.oldcity.dca.net.www: S 2011680397:2011680397(0) win
> 16384 <mss 1460,nop,nop,sackOK> (DF)
> >  
> > I am not sure how to interpret 'ff:ff:ff:ff:0:30' is it a kind of
> > broadcasting at the ethernet level ?
> > 
> > Why can I see these packets that are not for me ?
> > 
> > Why this traffic is not dropped by netfilter ? 
> > 
> > It seems to be a miss-configuration of my ISP router, no ? I believe it's
> > harmless (except for my bandwidth) but I don't understand why I see
> > (with gkrellm) this traffic which seems to be rejected before netfilter.
> > Is gkrellm using packets information before the iptable processing ?
> > 
> > I have tried to set /proc/.../eth0/rp_filter to 0 without any
> > difference.
> > 
> > Thanks,
> > Christophe
> > 
> > -- 
> > Christophe Barbé <christophe.barbe@ufies.org>
> > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> > 
> > Dogs come when they're called;
> > cats take a message and get back to you later. --Mary Bly
> 
> 
> 
> -- 
> Christophe Barbé <christophe.barbe@ufies.org>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> 
> Dogs believe they are human. Cats believe they are God.

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

A qui sait comprendre, peu de mots suffisent.
(Intelligenti pauca.) 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: simple rules and unexpected traffic

[Jan Humme]

On Friday 05 July 2002 00:45, christophe barbé wrote:
> On Fri, Jul 05, 2002 at 08:35:53AM +1000, George Vieira wrote:
> > Yes I've found that some user space programs can see stuff before
> > iptables.. tcpdump too I think...
>
> Yes it sounds logical for tcpdump or tools like that (which pass the
> interface in promiscuisious mode) to see everything. I was not expecting
> the same from a unprivileged app like gkrellm.
> It is stil unclear for me what is the data processing path.
>
> Has someone a clear picture of the packets path ?

It is no problem to open a socket and receive a copy of all raw packets 
before they get to the kernel iptables modules. See "man 7 packet" for 
details.

I believe this is how tcpdump does it too.

Jan Humme.

Re: simple rules and unexpected traffic

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

On Fri, Jul 05, 2002 at 12:54:36AM +0200, Jan Humme wrote:
> On Friday 05 July 2002 00:45, christophe barbé wrote:
> > On Fri, Jul 05, 2002 at 08:35:53AM +1000, George Vieira wrote:
> > > Yes I've found that some user space programs can see stuff before
> > > iptables.. tcpdump too I think...
> >
> > Yes it sounds logical for tcpdump or tools like that (which pass the
> > interface in promiscuisious mode) to see everything. I was not expecting
> > the same from a unprivileged app like gkrellm.
> > It is stil unclear for me what is the data processing path.
> >
> > Has someone a clear picture of the packets path ?
> 
> It is no problem to open a socket and receive a copy of all raw packets 
> before they get to the kernel iptables modules. See "man 7 packet" for 
> details.
> 
> I believe this is how tcpdump does it too.

Ok it sounds logical.
Now the question is what is dropping these packets ? Apparently not
rp_filter, and not netfilter because I see no log for it.

Christophe

> 
> Jan Humme.

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Imagination is more important than knowledge.
   Albert Einstein, On Science

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

simple rules and unexpected traffic

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]

Hi,

I use a simple set of iptables rules for my laptop to reject everything
from outside using ip_conntrack (from the howto) :

# Generated by iptables-save v1.2.6a on Thu Jul  4 09:54:11 2002
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [43965:4118502]
:block - [0:0]
-A INPUT -j block 
-A FORWARD -j block 
-A block -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A block -i ! eth0 -m state --state NEW -j ACCEPT 
-A block -i eth0 -m limit --limit 3/hour -j LOG --log-prefix "Bad packet from eth0:" 
-A block -i ! eth0 -m limit --limit 3/hour -j LOG --log-prefix "Bad packet not from eth0:" 
-A block -j DROP 
COMMIT
# Completed on Thu Jul  4 09:54:11 2002

I have a ADSL connection and only a hub between my laptop and the
ADSL-modem. Recently something changed, I guess on the router from my
provider and now I see unexpected traffic.

I see it with the eth0 monitor in gkrellm and with iftop but not with
lsof -i.
I was not expecting this traffic and the pattern seems strange : a
constant 20kB incoming traffic during a few seconds. So I started
looking closer. With ethereal I saw that it was a kind of flooding
most of the time a lot of SYN packet but also netbios ....
Each time both IPs are not one of my computer. For example I see during
one of this flooding with 'tcpdump -c 2 -e'

tcpdump: listening on eth0
10:00:39.946940 0:0:c:c3:a:88 ff:ff:ff:ff:0:30 ip 62: 216-203-233-196.customer.algx.net.3574 > adsl-216-158-52-76.cust.oldcity.dca.net.www: S 2011680397:2011680397(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
10:00:39.949401 0:0:c:c3:a:88 ff:ff:ff:ff:0:30 ip 62: 216-203-233-196.customer.algx.net.3574 > adsl-216-158-52-76.cust.oldcity.dca.net.www: S 2011680397:2011680397(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
 
I am not sure how to interpret 'ff:ff:ff:ff:0:30' is it a kind of
broadcasting at the ethernet level ?

Why can I see these packets that are not for me ?

Why this traffic is not dropped by netfilter ? 

It seems to be a miss-configuration of my ISP router, no ? I believe it's
harmless (except for my bandwidth) but I don't understand why I see
(with gkrellm) this traffic which seems to be rejected before netfilter.
Is gkrellm using packets information before the iptable processing ?

I have tried to set /proc/.../eth0/rp_filter to 0 without any
difference.

Thanks,
Christophe

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Dogs come when they're called;
cats take a message and get back to you later. --Mary Bly

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: simple rules and unexpected traffic

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 3568 bytes --]

I have found at http://www.cavebear.com/CaveBear/Ethernet/multicast.html
that ff:ff:ff:ff:0:30 could be a multicast ethernet address
(03-00-FF-FF-FF-FF) for 'All Stations Address'.

Is it something commonly used by script kiddies ?

If I undersatnd correctly, nothing has changed at the router, but
somebody connected at the same router is doing bad stuff. Is it right ?

What I still don't understand is why I can see this traffic with my
iptables rules. Is the traffic exposed (to user-space tools) before
entering the iptables processing ?

Christophe

On Thu, Jul 04, 2002 at 10:10:48AM -0400, christophe barbé wrote:
> Hi,
> 
> I use a simple set of iptables rules for my laptop to reject everything
> from outside using ip_conntrack (from the howto) :
> 
> # Generated by iptables-save v1.2.6a on Thu Jul  4 09:54:11 2002
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [43965:4118502]
> :block - [0:0]
> -A INPUT -j block 
> -A FORWARD -j block 
> -A block -m state --state RELATED,ESTABLISHED -j ACCEPT 
> -A block -i ! eth0 -m state --state NEW -j ACCEPT 
> -A block -i eth0 -m limit --limit 3/hour -j LOG --log-prefix "Bad packet from eth0:" 
> -A block -i ! eth0 -m limit --limit 3/hour -j LOG --log-prefix "Bad packet not from eth0:" 
> -A block -j DROP 
> COMMIT
> # Completed on Thu Jul  4 09:54:11 2002
> 
> I have a ADSL connection and only a hub between my laptop and the
> ADSL-modem. Recently something changed, I guess on the router from my
> provider and now I see unexpected traffic.
> 
> I see it with the eth0 monitor in gkrellm and with iftop but not with
> lsof -i.
> I was not expecting this traffic and the pattern seems strange : a
> constant 20kB incoming traffic during a few seconds. So I started
> looking closer. With ethereal I saw that it was a kind of flooding
> most of the time a lot of SYN packet but also netbios ....
> Each time both IPs are not one of my computer. For example I see during
> one of this flooding with 'tcpdump -c 2 -e'
> 
> tcpdump: listening on eth0
> 10:00:39.946940 0:0:c:c3:a:88 ff:ff:ff:ff:0:30 ip 62: 216-203-233-196.customer.algx.net.3574 > adsl-216-158-52-76.cust.oldcity.dca.net.www: S 2011680397:2011680397(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
> 10:00:39.949401 0:0:c:c3:a:88 ff:ff:ff:ff:0:30 ip 62: 216-203-233-196.customer.algx.net.3574 > adsl-216-158-52-76.cust.oldcity.dca.net.www: S 2011680397:2011680397(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
>  
> I am not sure how to interpret 'ff:ff:ff:ff:0:30' is it a kind of
> broadcasting at the ethernet level ?
> 
> Why can I see these packets that are not for me ?
> 
> Why this traffic is not dropped by netfilter ? 
> 
> It seems to be a miss-configuration of my ISP router, no ? I believe it's
> harmless (except for my bandwidth) but I don't understand why I see
> (with gkrellm) this traffic which seems to be rejected before netfilter.
> Is gkrellm using packets information before the iptable processing ?
> 
> I have tried to set /proc/.../eth0/rp_filter to 0 without any
> difference.
> 
> Thanks,
> Christophe
> 
> -- 
> Christophe Barbé <christophe.barbe@ufies.org>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> 
> Dogs come when they're called;
> cats take a message and get back to you later. --Mary Bly



-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Dogs believe they are human. Cats believe they are God.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]