network flood imunity

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.

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.)

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 :)

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

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.)

I'll try these. Thank you!

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."