How to stop the flood?

How to stop the flood?

[Rikunj]

Hello All,

I am seeing lots of this kind of scanning flood attack from different IP
within my

network and even from outside.

How can I stop and protect from this kind of attack?

Any specific iptables rule-set or clue would be appreciated.

---------Log from clients Dlink Router---------------------

Thu Apr 28 10:39:07 2005 Unrecognized attempt blocked from
192.168.25.208:3113 to TCP port 1025
Thu Apr 28 10:39:09 2005 Unrecognized attempt blocked from
192.168.25.208:3113 to TCP port 1025
Thu Apr 28 10:39:52 2005 Unrecognized attempt blocked from
192.168.25.208:3345 to TCP port 6129
Thu Apr 28 10:39:56 2005 Unrecognized attempt blocked from
192.168.25.208:3345 to TCP port 6129
Thu Apr 28 10:40:01 2005 Unrecognized attempt blocked from
192.168.25.208:3345 to TCP port 6129
Thu Apr 28 10:40:12 2005 Unrecognized attempt blocked from
192.168.25.208:3450 to TCP port 80
Thu Apr 28 10:40:20 2005 Unrecognized attempt blocked from
192.168.25.208:3450 to TCP port 80
Thu Apr 28 10:40:32 2005 Unrecognized attempt blocked from
192.168.25.208:3568 to TCP port 443
Thu Apr 28 10:40:35 2005 Unrecognized attempt blocked from
192.168.25.208:3568 to TCP port 443
Thu Apr 28 10:40:44 2005 Unrecognized attempt blocked from
192.168.25.208:3568 to TCP port 443

---------Log from clients Dlink Router---------------------

Regards,
Rikunj

Re: How to stop the flood?

[Jason Opperisano]

On Thu, Apr 28, 2005 at 04:35:14PM +0300, Rikunj wrote:
> 
> Hello All,
> 
> I am seeing lots of this kind of scanning flood attack from different IP
> within my
> 
> network and even from outside.
> 
> How can I stop and protect from this kind of attack?

the word "blocked" means, well...blocked.  so you already are
"protecting"...

as for "stopping," go to the person sitting at 192.168.25.208 and kick
their teeth down their throat.

-j

--
"Peter: Wow, it's like I died and went to heaven, then God realized it
 wasn't my time yet, so He sent me back to a brewery."
        --Family Guy

Re: How to stop the flood?

[Rikunj]

Thankyou for the reply.

This was the log from one of my client who was attacked from a client on
other subnet.

My network consist of clients from different subnets of /24.

The attacks from one subnet travels through my linux router and hits the
client on other subnet.

I tried few rules as below but seems not to be working.

-----------Cut From fwscript.sh-------------------------

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 0 > /proc/sys/net/ipv4/conf/all/log_martians
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m length --length
92 -j DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A FORWARD -p tcp --syn -m limit --limit 10/s -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p ip -f  -j DROP
iptables -A FORWARD -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
iptables -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP
-----------------------------------------------

Regards,
Rikunj Patel


----- Original Message -----
From: "Jason Opperisano" <opie@817west.com>
To: <netfilter@lists.netfilter.org>
Sent: Thursday, April 28, 2005 5:16 PM
Subject: Re: How to stop the flood?


> On Thu, Apr 28, 2005 at 04:35:14PM +0300, Rikunj wrote:
> >
> > Hello All,
> >
> > I am seeing lots of this kind of scanning flood attack from different IP
> > within my
> >
> > network and even from outside.
> >
> > How can I stop and protect from this kind of attack?
>
> the word "blocked" means, well...blocked.  so you already are
> "protecting"...
>
> as for "stopping," go to the person sitting at 192.168.25.208 and kick
> their teeth down their throat.
>
> -j
>
> --
> "Peter: Wow, it's like I died and went to heaven, then God realized it
>  wasn't my time yet, so He sent me back to a brewery."
>         --Family Guy
>

RE: How to stop the flood?

[Rob Sterenborg]

netfilter-bounces@lists.netfilter.org <> scribbled on Thursday, 28 April
2005 16:48:

> Thankyou for the reply.
> 
> This was the log from one of my client who was attacked from a client
> on other subnet. 
> 
> My network consist of clients from different subnets of /24.
> 
> The attacks from one subnet travels through my linux router
> and hits the client on other subnet.
> 
> I tried few rules as below but seems not to be working.

The script doesn't block any packets from 192.168.25.208.
If 192.168.25.208 isn't allowed passing your router, you should block it
:

$IPT -A FORWARD -s 192.168.25.208 [-d <destination_ip>] \
  -j [DROP|REJECT --reject-with-tcp-reset]

Or something like that.

The real solution is like Jason said : track down the person at
192.168.25.208 and kick his/her ass !


Gr,
Rob

RE: How to stop the flood?

[Dwayne Hottinger]

Im confused.  Why would you allow someone on your network (subnet or net) do
such a thing.  Cant you just not give them access, either via dhcp or some
other way.  Sounds almost like an issue for management ie someone needs to
start looking for employment elsewhere.

ddh

Quoting Rob Sterenborg <rob@sterenborg.info>:

> netfilter-bounces@lists.netfilter.org <> scribbled on Thursday, 28 April
> 2005 16:48:
>
> > Thankyou for the reply.
> >
> > This was the log from one of my client who was attacked from a client
> > on other subnet.
> >
> > My network consist of clients from different subnets of /24.
> >
> > The attacks from one subnet travels through my linux router
> > and hits the client on other subnet.
> >
> > I tried few rules as below but seems not to be working.
>
> The script doesn't block any packets from 192.168.25.208.
> If 192.168.25.208 isn't allowed passing your router, you should block it
> :
>
> $IPT -A FORWARD -s 192.168.25.208 [-d <destination_ip>] \
>   -j [DROP|REJECT --reject-with-tcp-reset]
>
> Or something like that.
>
> The real solution is like Jason said : track down the person at
> 192.168.25.208 and kick his/her ass !
>
>
> Gr,
> Rob
>
>


--
Dwayne Hottinger
Network Administrator
Harrisonburg City Public Schools

Re: How to stop the flood?

[Rikunj]

I really don't want them to do this and they are blocked as soon as
discovered.

All the clients are from DHCP IP's of 4 subnets of /24. Blocking them one by
one will eat up IP's.

Moreover they change the attacking src and dst ports making it hard to
pinpoint them.

My real problem is to identify the curlprits.
How can I diferenciate a genuine traffic and a infected attack? What should
I look for?

Regards,
Rikunj Patel


----- Original Message -----
From: "Dwayne Hottinger" <dhottinger@harrisonburg.k12.va.us>
To: <netfilter@lists.netfilter.org>
Sent: Thursday, April 28, 2005 6:54 PM
Subject: RE: How to stop the flood?


> Im confused.  Why would you allow someone on your network (subnet or net)
do
> such a thing.  Cant you just not give them access, either via dhcp or some
> other way.  Sounds almost like an issue for management ie someone needs to
> start looking for employment elsewhere.
>
> ddh
>
> Quoting Rob Sterenborg <rob@sterenborg.info>:
>
> > netfilter-bounces@lists.netfilter.org <> scribbled on Thursday, 28 April
> > 2005 16:48:
> >
> > > Thankyou for the reply.
> > >
> > > This was the log from one of my client who was attacked from a client
> > > on other subnet.
> > >
> > > My network consist of clients from different subnets of /24.
> > >
> > > The attacks from one subnet travels through my linux router
> > > and hits the client on other subnet.
> > >
> > > I tried few rules as below but seems not to be working.
> >
> > The script doesn't block any packets from 192.168.25.208.
> > If 192.168.25.208 isn't allowed passing your router, you should block it
> > :
> >
> > $IPT -A FORWARD -s 192.168.25.208 [-d <destination_ip>] \
> >   -j [DROP|REJECT --reject-with-tcp-reset]
> >
> > Or something like that.
> >
> > The real solution is like Jason said : track down the person at
> > 192.168.25.208 and kick his/her ass !
> >
> >
> > Gr,
> > Rob
> >
> >
>
>
> --
> Dwayne Hottinger
> Network Administrator
> Harrisonburg City Public Schools
>

Re: How to stop the flood?

[Taylor, Grant]

Rikunj wrote:
> I really don't want them to do this and they are blocked as soon as
> discovered.

As they should be.

> All the clients are from DHCP IP's of 4 subnets of /24. Blocking them one by
> one will eat up IP's.

You could have a range of IPs in your DHCP scope that are for systems that are not known to the DHCP server, i.e. a smaller scope like what you have now.  Then set aside part of your existing scope to systems with known MAC addresses.  This way you can ensure that the computers have a known IP for a given MAC.  This will also solve the problem where the source IP changes, assuming that the same system is the problem.

> Moreover they change the attacking src and dst ports making it hard to
> pinpoint them.

Do they change the source and / destination ports or IP addresses?  Either way, you should be able to get the DHCP server to log what MAC has what IP address.  As this would be an on going log you could look back and see who had what IP at what time to find the MAC.  With the known MAC of the attacker at any give time you could then look in your log to see what IP is associated with that MAC at present.  Thus you know what IP an attacker has presently, if it has changed from the prior IP.  You could even temporarily block this IP from being able to do any thing on the internet and thus provoking a call from them thus making them stand out in the crowd.

> My real problem is to identify the curlprits.
> How can I diferenciate a genuine traffic and a infected attack? What should
> I look for?

Genuine traffic will follow patterns and access standard services.  This will depend on what your client's orginizations are and what they do.  Most orginizations will access FTP, SSH, Telnet, SMTP, DNS, HTTP, POP3, IMAP, NNTP, HTTPS and maybe a few others.  If all the traffic that your clients are generating is internet based there is not much else that is common on the net aside form the ports that various IM clients use.  You can fairly quickly pare out the traffic that is obviously standard (as far as ports to access any way) and be left with a small(er) list of ports that are being accessed to decide if it is genuine traffic or not.  Unfortunetly this is a learning process for every administrator on every network.  One tip that I can give you would be to have rule like the following:

iptables -t filter -A FORWARD -p tcp --dport 143

You would want this rule, with out a jump target (-j...), to act as a counter to see if you do have any traffic like this at all with out interfering with the rest of your firewall.  If you put such rules above any other rules that would effect the FORWARD chain you will get a decent counter.  I would be tempted to modify the rule slightly, as such:

iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 143

This will let you know how much traffic to port 143 (IMAP) Client #1 is sending.



Grant. . . .

Re: How to stop the flood?

[Rikunj]

Thankyou all for such a wonderful response.

All the suggestions are noted and I will post you the final results with my
implementation.

Regards,
Rikunj Patel


----- Original Message -----
From: "Taylor, Grant" <gtaylor@riverviewtech.net>
To: <netfilter@lists.netfilter.org>
Sent: Friday, April 29, 2005 6:12 AM
Subject: Re: How to stop the flood?


> Rikunj wrote:
> > I really don't want them to do this and they are blocked as soon as
> > discovered.
>
> As they should be.
>
> > All the clients are from DHCP IP's of 4 subnets of /24. Blocking them
one by
> > one will eat up IP's.
>
> You could have a range of IPs in your DHCP scope that are for systems that
are not known to the DHCP server, i.e. a smaller scope like what you have
now.  Then set aside part of your existing scope to systems with known MAC
addresses.  This way you can ensure that the computers have a known IP for a
given MAC.  This will also solve the problem where the source IP changes,
assuming that the same system is the problem.
>
> > Moreover they change the attacking src and dst ports making it hard to
> > pinpoint them.
>
> Do they change the source and / destination ports or IP addresses?  Either
way, you should be able to get the DHCP server to log what MAC has what IP
address.  As this would be an on going log you could look back and see who
had what IP at what time to find the MAC.  With the known MAC of the
attacker at any give time you could then look in your log to see what IP is
associated with that MAC at present.  Thus you know what IP an attacker has
presently, if it has changed from the prior IP.  You could even temporarily
block this IP from being able to do any thing on the internet and thus
provoking a call from them thus making them stand out in the crowd.
>
> > My real problem is to identify the curlprits.
> > How can I diferenciate a genuine traffic and a infected attack? What
should
> > I look for?
>
> Genuine traffic will follow patterns and access standard services.  This
will depend on what your client's orginizations are and what they do.  Most
orginizations will access FTP, SSH, Telnet, SMTP, DNS, HTTP, POP3, IMAP,
NNTP, HTTPS and maybe a few others.  If all the traffic that your clients
are generating is internet based there is not much else that is common on
the net aside form the ports that various IM clients use.  You can fairly
quickly pare out the traffic that is obviously standard (as far as ports to
access any way) and be left with a small(er) list of ports that are being
accessed to decide if it is genuine traffic or not.  Unfortunetly this is a
learning process for every administrator on every network.  One tip that I
can give you would be to have rule like the following:
>
> iptables -t filter -A FORWARD -p tcp --dport 143
>
> You would want this rule, with out a jump target (-j...), to act as a
counter to see if you do have any traffic like this at all with out
interfering with the rest of your firewall.  If you put such rules above any
other rules that would effect the FORWARD chain you will get a decent
counter.  I would be tempted to modify the rule slightly, as such:
>
> iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p
tcp --dport 143
>
> This will let you know how much traffic to port 143 (IMAP) Client #1 is
sending.
>
>
>
> Grant. . . .
>

Re: How to stop the flood?

[Mogens Valentin]

Taylor, Grant wrote:
> Rikunj wrote:
> 
>> Moreover they change the attacking src and dst ports making it hard to
>> pinpoint them.
> 
> Do they change the source and / destination ports or IP addresses?  
> Either way, you should be able to get the DHCP server to log what MAC 
> has what IP address.  As this would be an on going log you could look 
> back and see who had what IP at what time to find the MAC.  With the 
> known MAC of the attacker at any give time you could then look in your 
> log to see what IP is associated with that MAC at present.  Thus you 
> know what IP an attacker has presently, if it has changed from the prior 
> IP.  You could even temporarily block this IP from being able to do any 
> thing on the internet and thus provoking a call from them thus making 
> them stand out in the crowd.

If clients can change IP's on the fly, they can change MAC's all the 
same. Of cause, arranging DHCP on a per-client-based-on-MAC scheme will 
catch this behavior (which you more or less pointed out).

> ...One tip that I can give you would be to have rule like 
> the following:
> 
> iptables -t filter -A FORWARD -p tcp --dport 143
> 
> You would want this rule, with out a jump target (-j...), to act as a 
> counter to see if you do have any traffic like this at all with out 
> interfering with the rest of your firewall.  If you put such rules above 
> any other rules that would effect the FORWARD chain you will get a 
> decent counter.  I would be tempted to modify the rule slightly, as such:
> 
> iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp 
> --dport 143
> 
> This will let you know how much traffic to port 143 (IMAP) Client #1 is 
> sending.

So you chose IMAP merely as an example.. Meaning you'd do similarly for 
other services if interest, right?  Good idea, tnx.

-- 
Kind regards,
Mogens Valentin

Re: How to stop the flood?

[Taylor, Grant]

> If clients can change IP's on the fly, they can change MAC's all the 
> same. Of cause, arranging DHCP on a per-client-based-on-MAC scheme will 
> catch this behavior (which you more or less pointed out).

Rather than DROPing based on a known IP/MAC pair you could accept based on IP/MAC pair thus if the client did change things on you they would not be able to get to the internet.  This is normally how this works.  About the only caveat that I can see for this would be if a client switched NICs with another client.

> So you chose IMAP merely as an example.. Meaning you'd do similarly for 
> other services if interest, right?  Good idea, tnx.

Exactly

iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 20
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 20
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 21
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 21
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 22
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 22
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 23
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 23
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 25
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 25
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 53
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 53
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p udp --dport 53
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p udp --sport 53
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 80
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 80
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 110
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 110
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 119
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 119
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 143
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 143
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 443
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 443

iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 20
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 20
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 21
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 21
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 22
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 22
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 23
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 23
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 25
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 25
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 53
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 53
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p udp --dport 53
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p udp --sport 53
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 80
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 80
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 110
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 110
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 119
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 119
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 143
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 143
iptables -t filter -A FORWARD -i $Client_2 -s $Client_2_Subnet -p tcp --dport 443
iptables -t filter -A FORWARD -o $Client_2 -d $Client_2_Subnet -p tcp --sport 443

etc.  These rules will have their counter incremented for every packet that passes to or from one of your client's interfaces and subnets.  This way you will have an idea how much traffic of each type they generate.

If you were really curious you could do something like the following too:

iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --sport 0:1023 --dport 80
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 80 --dport 0:1023
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --sport 1024:65535 --dport 80
iptables -t filter -A FORWARD -o $Client_1 -d $Client_1_Subnet -p tcp --sport 80 --dport 1024:65535

This will tell you the amount of traffic for each type originating from the non ephemeral range and how much traffic is originating from the ephemeral range.  IMHO *MOST* if not all of the client web traffic to web servers should originate from ephemeral ports.



Grant. . . .

RE: How to stop the flood?

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


defiantly, as others have hinted, not everything is a technical/firewall 
issue.  Block the network access and let the user explain to their manager 
why they are not able to complete their work.  If this is consumer access, 
then you don't need their monies, send them on their merry way of finding 
another ISP to abuse.

Thanks,

Ron DuFresne

On Thu, 28 Apr 2005, Dwayne Hottinger wrote:

> Im confused.  Why would you allow someone on your network (subnet or net) do
> such a thing.  Cant you just not give them access, either via dhcp or some
> other way.  Sounds almost like an issue for management ie someone needs to
> start looking for employment elsewhere.
>
> ddh
>

 	[SNIP]

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCcVqOst+vzJSwZikRAuzCAKC2mG7g1BW3C7CSre8e0wJMmHLvgwCg1D5N
TB21afeUvHb15pLZREmfDY0=
=o40X
-----END PGP SIGNATURE-----

Re: How to stop the flood?

[wkc]

R. DuFresne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> defiantly, as others have hinted, not everything is a technical/firewall 
> issue.  Block the network access and let the user explain to their 
> manager why they are not able to complete their work.  If this is 
> consumer access, then you don't need their monies, send them on their 
> merry way of finding another ISP to abuse.
> 
> Thanks,
> 

Is there the possibility the users may not know they are causing a 
problem? Perhaps a virus or worm has arrived on their computer.
You could try blocking access, see who complains and then have a chat to 
them.
Just my 2 cents worth.

-- 
Keith Clethero



System Administrator
Taranaki Sawmills Ltd.
Ph 06 7559000 x 816

Re: How to stop the flood?

[Dwayne Hottinger]

If that was the case, you should be able to find the culprints via a sniffer.  I
would watch for large amounts of icmp traffic and trace it back to the user. 
Do you also supply DHCP and DNS to your subnets?  If so you can glean through
the logs of each and get a W/S to IP name.  Shouldnt take much of a sniff to
get the culprits.  Most of the time DOS attacks are done unknowlingly by users.
 Usually try to head that off by ensuring patches and virus software is up to
date.  Although that isnt always foolproof.  If windows machines exist (and we
all have to live with them) than these things will be issues.

ddh


Quoting wkc <wkc@tarapine.co.nz>:

> R. DuFresne wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > defiantly, as others have hinted, not everything is a technical/firewall
> > issue.  Block the network access and let the user explain to their
> > manager why they are not able to complete their work.  If this is
> > consumer access, then you don't need their monies, send them on their
> > merry way of finding another ISP to abuse.
> >
> > Thanks,
> >
>
> Is there the possibility the users may not know they are causing a
> problem? Perhaps a virus or worm has arrived on their computer.
> You could try blocking access, see who complains and then have a chat to
> them.
> Just my 2 cents worth.
>
> --
> Keith Clethero
>
>
>
> System Administrator
> Taranaki Sawmills Ltd.
> Ph 06 7559000 x 816
>


--
Dwayne Hottinger
Network Administrator
Harrisonburg City Public Schools

Re: How to stop the flood?

[Rikunj]

I really don't want them to do this and they are blocked as soon as
discovered.

All the clients are from DHCP IP's of 4 subnets of /24. Blocking them one by
one will eat up IP's.

Moreover they change the attacking src and dst ports making it hard to
pinpoint them.

My real problem is to identify the culprits.
How can I differentiate a genuine traffic and a infected attack? What should
I look for?

Regards,
Rikunj Patel


----- Original Message -----
From: "Dwayne Hottinger" <dhottinger@harrisonburg.k12.va.us>
To: <netfilter@lists.netfilter.org>
Sent: Thursday, April 28, 2005 6:54 PM
Subject: RE: How to stop the flood?


> Im confused.  Why would you allow someone on your network (subnet or net)
do
> such a thing.  Cant you just not give them access, either via dhcp or some
> other way.  Sounds almost like an issue for management ie someone needs to
> start looking for employment elsewhere.
>
> ddh
>
> Quoting Rob Sterenborg <rob@sterenborg.info>:
>
> > netfilter-bounces@lists.netfilter.org <> scribbled on Thursday, 28 April
> > 2005 16:48:
> >
> > > Thankyou for the reply.
> > >
> > > This was the log from one of my client who was attacked from a client
> > > on other subnet.
> > >
> > > My network consist of clients from different subnets of /24.
> > >
> > > The attacks from one subnet travels through my linux router
> > > and hits the client on other subnet.
> > >
> > > I tried few rules as below but seems not to be working.
> >
> > The script doesn't block any packets from 192.168.25.208.
> > If 192.168.25.208 isn't allowed passing your router, you should block it
> > :
> >
> > $IPT -A FORWARD -s 192.168.25.208 [-d <destination_ip>] \
> >   -j [DROP|REJECT --reject-with-tcp-reset]
> >
> > Or something like that.
> >
> > The real solution is like Jason said : track down the person at
> > 192.168.25.208 and kick his/her ass !
> >
> >
> > Gr,
> > Rob
> >
> >
>
>
> --
> Dwayne Hottinger
> Network Administrator
> Harrisonburg City Public Schools
>




----- Original Message -----
From: "Rob Sterenborg" <rob@sterenborg.info>
To: <netfilter@lists.netfilter.org>
Sent: Thursday, April 28, 2005 6:47 PM
Subject: RE: How to stop the flood?


> netfilter-bounces@lists.netfilter.org <> scribbled on Thursday, 28 April
> 2005 16:48:
>
> > Thankyou for the reply.
> >
> > This was the log from one of my client who was attacked from a client
> > on other subnet.
> >
> > My network consist of clients from different subnets of /24.
> >
> > The attacks from one subnet travels through my linux router
> > and hits the client on other subnet.
> >
> > I tried few rules as below but seems not to be working.
>
> The script doesn't block any packets from 192.168.25.208.
> If 192.168.25.208 isn't allowed passing your router, you should block it
> :
>
> $IPT -A FORWARD -s 192.168.25.208 [-d <destination_ip>] \
>   -j [DROP|REJECT --reject-with-tcp-reset]
>
> Or something like that.
>
> The real solution is like Jason said : track down the person at
> 192.168.25.208 and kick his/her ass !
>
>
> Gr,
> Rob
>
>

Re: How to stop the flood?

[Jason Opperisano]

On Thu, Apr 28, 2005 at 05:47:42PM +0300, Rikunj wrote:
> Thankyou for the reply.
> 
> This was the log from one of my client who was attacked from a client on
> other subnet.
> 
> My network consist of clients from different subnets of /24.
> 
> The attacks from one subnet travels through my linux router and hits the
> client on other subnet.
> 
> I tried few rules as below but seems not to be working.
> 
> -----------Cut From fwscript.sh-------------------------
> 
> echo 1 > /proc/sys/net/ipv4/tcp_syncookies
> echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
> echo 0 > /proc/sys/net/ipv4/conf/all/log_martians
> echo 0 > /proc/sys/net/ipv4/tcp_timestamps
> echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
> echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
> echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
> echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
> iptables -F
> iptables -t nat -F
> iptables -t mangle -F
> iptables -P FORWARD DROP
> iptables -P OUTPUT ACCEPT
> iptables -P INPUT DROP
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -p icmp --icmp-type echo-request -m length --length
> 92 -j DROP
> iptables -A INPUT -i lo -j ACCEPT
> iptables -A FORWARD -p tcp --syn -m limit --limit 10/s -j ACCEPT
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -p ip -f  -j DROP
> iptables -A FORWARD -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
> iptables -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
> iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
> iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
> iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
> iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
> iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
> iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP
> -----------------------------------------------

well, you're really not blocking much of anything with that.  if you
wish to block 192.168.25.208:

  iptables -A FORWARD -s 192.168.25.208 -j DROP

when they call to ask why "the Internet is down" invoke plan B--opening
up a can of the genuine whoop-ass.

-j

--
"Peter: You wanna talk about awkward moments? Once, during sex,
 I called Lois "Frank". Your move, Sherlock."
        --Family Guy

Re: How to stop the flood?

[Taylor, Grant]

> This was the log from one of my client who was attacked from a client on
> other subnet.

How many different subnets are you serving?  What interfaces are they on on your router?  Do you have each client on a different subnet, or are there multiple clients on one subnet?  What type of network setup do you have, both physical and logical?

> My network consist of clients from different subnets of /24.

Are these /24 subnets independently controlled by your clients such that you don't have any control on them sort of saying stop or you will stop their internet access?

> The attacks from one subnet travels through my linux router and hits the
> client on other subnet.

Assuming that each of your clients is on a different subnet and they are connected to an aliased interface on your router you could very easily set up your firewall script to filter based on inbound and outbound interface.  This also assumes that one client of yours will never need to communicate with another directly.  If one client needs to communicate with another directly you will need to explicitly allow the traffic to pass through your router.

(This is presuming that your FORWARD policy is set to DROP which IMHO it should *ALWAYS* be.)
# Client_1
iptables -t filter -A FORWARD -i $Client_1 -o $INet -s $Client_1_Subnet -j ACCEPT
iptables -t filter -A FORWARD -i $INet -o $Client_1 -d $Client_1_Subnet -j ACCEPT
# Client_2
iptables -t filter -A FORWARD -i $Client_2 -o $INet -s $Client_2_Subnet -j ACCEPT
iptables -t filter -A FORWARD -i $INet -o $Client_2 -d $Client_2_Subnet -j ACCEPT
# Client_3
iptables -t filter -A FORWARD -i $Client_3 -o $INet -s $Client_3_Subnet -j ACCEPT
iptables -t filter -A FORWARD -i $INet -o $Client_3 -d $Client_3_Subnet -j ACCEPT

(This is presuming that your FORWARD policy is set to ACCEPT which IMHO it should *NEVER* be.)
# Client_1
iptables -t filter -A FORWARD -i $Client_1 -o ! $INet -s $Client_1_Subnet -j DROP
iptables -t filter -A FORWARD -i ! $INet -o $Client_1 -d $Client_1_Subnet -j DROP
# Client_2
iptables -t filter -A FORWARD -i $Client_2 -o ! $INet -s $Client_2_Subnet -j DROP
iptables -t filter -A FORWARD -i ! $INet -o $Client_2 -d $Client_2_Subnet -j DROP
# Client_3
iptables -t filter -A FORWARD -i $Client_3 -o ! $INet -s $Client_3_Subnet -j DROP
iptables -t filter -A FORWARD -i ! $INet -o $Client_3 -d $Client_3_Subnet -j DROP

(Any one care to double check my logic?  Please?)

> I tried few rules as below but seems not to be working.

Your rules look like they are designed to do more quality assurance (making sure the traffic is not blatantly invalid) on any traffic passing through the FORWARD chain than filtering based on the source and destination address and interface.



Grant. . . .