network flood imunity

network flood imunity

[Sorin Panca]

Hi!
I have a network with no natting and i would linke to develop a rule set
for flood protection of some windows stations. Recently one station was
flooded while it was powered off (for me this is a uncomprehensible
situation / act).. My ISP added a filter against my station and I can't
acces the internet on it now. The server is running kernel 2.4.22-10mdk
with mandrake-<some.version> and iptables-1.2.8. I tried to replace it
(the server) but due to unknown reasons, I failed three times. And I
gave up.
If someone has an ideea of how can I protect the server in this
configuration against floods, I would be very happy to learn.
iptraf also shows some arp traffic that I don't know what is and I don't
know how to fiter it.
Here is a sample:
ARP request for 85.186.68.52 (63 bytes) from 000ed6bdc070 to
ffffffffffff on eth1
ARP request for 83.103.129.16 (40 bytes) from 000ed6bdc070 to
ffffffffffff on eth1
ARP request for 83.103.132.190 (63 bytes) from 000ed6bdc070 to
ffffffffffff on eth1
ARP request for 83.103.128.51 (40 bytes) from 000ed6bdc070 to
ffffffffffff on eth1                         ARP request for
83.103.133.236 (1500 bytes) from 000ed6bdc070 to ffffffffffff on eth1
These are marked with red.
Thank you!

Sorin.

Re: network flood imunity

[ludi]

Do you know where is the box that MAC address is 000ed6bdc070?

Re: network flood imunity

[Sorin Panca]

ludi wrote:

>Do you know where is the box that MAC address is 000ed6bdc070?
>  
>
It's in my ISP's local network. It's a network neighbour. (I don't know
exactly it's physical location.)

Re: network flood imunity

[Mogens Valentin]

Sorin Panca wrote:
> Hi!
> I have a network with no natting and i would linke to develop a rule set
> for flood protection of some windows stations. Recently one station was
> flooded while it was powered off (for me this is a uncomprehensible
> situation / act)..

Ehh? Flooded while powered off? Says who? Your ISP? If they can see YOUR 
  IP getting spoofed (while powered off), they -may- have a problem with 
overlapping custumer IP's; I've seend that before :)

> My ISP added a filter against my station and I can't
> acces the internet on it now. The server is running kernel 2.4.22-10mdk
> with mandrake-<some.version> and iptables-1.2.8. I tried to replace it
> (the server) but due to unknown reasons, I failed three times. And I
> gave up.
> If someone has an ideea of how can I protect the server in this
> configuration against floods, I would be very happy to learn.

I havne't got time for rule examples, but you may find the following 
/proc settings quite helpful:

       # Disable ICMP echo-request to broadcast addresses (Smurf amplifier):
           echo "1" >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

       # Enable syn-cookies (prevent syn-flood attacks):
           echo "1" >/proc/sys/net/ipv4/tcp_syncookies

       # Reduce number of possible SYN Floods:
           echo "1024" >/proc/sys/net/ipv4/tcp_max_syn_backlog

       # Enable defrag error protection:
           echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

       # Enable time-wait assassination hazards in tcp (RFC 1337):
           echo "1" >/proc/sys/net/ipv4/tcp_rfc1337

       # Prevent remote digging of OS-type and uptime (RFC1323):
           #echo "1" >/proc/sys/net/ipv4/tcp_timestamps    # enable 
timestamps
           echo "0" >/proc/sys/net/ipv4/tcp_timestamps    # disable 
timestamps

       # Disable RFC2018 TCP Selective Acknowledgements:
           echo 0 > /proc/sys/net/ipv4/tcp_sack



       # Sourcerouting and spoofing:
           for i in /proc/sys/net/ipv4/conf/*; do
               # Drop all source-routed packets:
               echo "0" >$i/accept_source_route

               # Deactivate normal ICMP redirect accept/send:
               echo "0" >$i/accept_redirects
               echo "0" >$i/send_redirects

               # Activate secure ICMP redirects (send only?) (on by 
default):
               echo "1" >$i/secure_redirects

               # Enable ingress + egress source-address verification 
(prevent spoofing):
               #echo "0" >$i/rp_filter   # disable
               echo "1" >$i/rp_filter   # enable
           done

       # Log spoofed, source routed and redirect packets:
           #echo 1 >/proc/sys/net/ipv4/conf/all/log_martians
           echo 0 >/proc/sys/net/ipv4/conf/all/log_martians


-- 
Kind regards,
Mogens Valentin

Re: network flood imunity

[Sorin Panca]

Mogens Valentin wrote:

> Sorin Panca wrote:
>
>> Hi!
>> I have a network with no natting and i would linke to develop a rule set
>> for flood protection of some windows stations. Recently one station was
>> flooded while it was powered off (for me this is a uncomprehensible
>> situation / act)..
>
>
> Ehh? Flooded while powered off? Says who? Your ISP? If they can see
> YOUR  IP getting spoofed (while powered off), they -may- have a
> problem with overlapping custumer IP's; I've seend that before :)

Tell taht to my boss! :) As far as he is concerned that flood is my
fault and the ISP is always right... And I should do something for that
matter. (That is why I asked you guys.)

>
>> My ISP added a filter against my station and I can't
>> acces the internet on it now. The server is running kernel 2.4.22-10mdk
>> with mandrake-<some.version> and iptables-1.2.8. I tried to replace it
>> (the server) but due to unknown reasons, I failed three times. And I
>> gave up.
>> If someone has an ideea of how can I protect the server in this
>> configuration against floods, I would be very happy to learn.
>
>
> I havne't got time for rule examples, but you may find the following
> /proc settings quite helpful:
>
>       # Disable ICMP echo-request to broadcast addresses (Smurf
> amplifier):
>           echo "1" >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
>
>       # Enable syn-cookies (prevent syn-flood attacks):
>           echo "1" >/proc/sys/net/ipv4/tcp_syncookies
>
>       # Reduce number of possible SYN Floods:
>           echo "1024" >/proc/sys/net/ipv4/tcp_max_syn_backlog
>
>       # Enable defrag error protection:
>           echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
>
>       # Enable time-wait assassination hazards in tcp (RFC 1337):
>           echo "1" >/proc/sys/net/ipv4/tcp_rfc1337
>
>       # Prevent remote digging of OS-type and uptime (RFC1323):
>           #echo "1" >/proc/sys/net/ipv4/tcp_timestamps    # enable
> timestamps
>           echo "0" >/proc/sys/net/ipv4/tcp_timestamps    # disable
> timestamps
>
>       # Disable RFC2018 TCP Selective Acknowledgements:
>           echo 0 > /proc/sys/net/ipv4/tcp_sack
>
>
>
>       # Sourcerouting and spoofing:
>           for i in /proc/sys/net/ipv4/conf/*; do
>               # Drop all source-routed packets:
>               echo "0" >$i/accept_source_route
>
>               # Deactivate normal ICMP redirect accept/send:
>               echo "0" >$i/accept_redirects
>               echo "0" >$i/send_redirects
>
>               # Activate secure ICMP redirects (send only?) (on by
> default):
>               echo "1" >$i/secure_redirects
>
>               # Enable ingress + egress source-address verification
> (prevent spoofing):
>               #echo "0" >$i/rp_filter   # disable
>               echo "1" >$i/rp_filter   # enable
>           done
>
>       # Log spoofed, source routed and redirect packets:
>           #echo 1 >/proc/sys/net/ipv4/conf/all/log_martians
>           echo 0 >/proc/sys/net/ipv4/conf/all/log_martians
>
>
I'll try these. Thank you!

Re: network flood imunity

[TheGesus]

On 12/21/05, Mogens Valentin <mogensv@vip.cybercity.dk> wrote:
>
> Ehh? Flooded while powered off? Says who?
>

Stranger things have been known to happen...

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=PSD_HPSBMA01220

"During ongoing internal quality testing of the HP ProLiant DL585
server, a potential vulnerability has been identified, where a
remote unauthorized user may gain access to the server controls,
but only when the server is powered down."