Broadcast pings

I just noticed my Linux box responds to broadcast pings. I don't like the idea of being part of a smurf attack, or being discovered by pinging my network's broadcast address. How do I configure the adapter eth0 not to respond to traffic sent to the broadcast address? My IP is dynamic, and my subnet changes frequently, so I can't really firewall off that address. Here is the info from ifconfig and ping -b. Addresses have been changed, for obvious reasons:-

eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.123.154 Bcast:192.168.123.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2553 errors:0 dropped:0 overruns:0 frame:0
TX packets:2742 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1604139 (1.5 Mb) TX bytes:377355 (368.5 Kb)
Interrupt:11 Base address:0x7000

WARNING: pinging broadcast address
PING 192.168.123.255 (192.168.123.255) 56(84) bytes of data.
64 bytes from 192.168.123.154: icmp_seq=1 ttl=64 time=0.049 ms
64 bytes from 192.168.123.254: icmp_seq=1 ttl=64 time=1.04 ms (DUP!)
64 bytes from 192.168.123.154: icmp_seq=2 ttl=64 time=0.061 ms
64 bytes from 192.168.123.254: icmp_seq=2 ttl=64 time=1.04 ms (DUP!)
64 bytes from 192.168.123.154: icmp_seq=3 ttl=64 time=0.069 ms
64 bytes from 192.168.123.254: icmp_seq=3 ttl=64 time=1.24 ms (DUP!)
64 bytes from 192.168.123.154: icmp_seq=4 ttl=64 time=0.047 ms
64 bytes from 192.168.123.254: icmp_seq=4 ttl=64 time=1.02 ms (DUP!)

--- 192.168.123.255 ping statistics ---
4 packets transmitted, 4 received, +4 duplicates, 0% packet loss, time 3032ms
rtt min/avg/max/mdev = 0.047/0.572/1.241/0.520 ms

Any information will be greatly appreciated.

Don't know for sure if this would do what you want, but maybe you could use snort (an IDS) and write a rule to drop that type of traffic. Snort now has the ability to set variables, one of which being your home network. You can set it to use whatever ip you have at the time, so people like us with dhcp can still use it.
hth

EDIT: I had come across this over the weekend; it wouldn't be easy, but sometimes the challenge is the best part :D

Q: Is it possible with snort to add a ipfilter/ipfw rule to a firewall?

A: Yes, with additional software in the contrib directory. But this
can be dangerous and is not recommended unless you know what you're
doing.

Guardian is available and is part of the contrib directory in
the tarball distribution.

Guardian is a perl script which uses snort to detect attacks,
and then uses IPchains to deny any further attacks.

The Guardian webpage can be found at:
http://www.chaotic.org/~astevens/Guardian/index.html
or you can use the mirror,
http://www.cyberwizards.com/~midnite...ian/index.html

Quote:

---

Originally posted here by KeyserSoze
Don't know for sure if this would do what you want, but maybe you could use snort (an IDS) and write a rule to drop that type of traffic. Snort now has the ability to set variables, one of which being your home network. You can set it to use whatever ip you have at the time, so people like us with dhcp can still use it.
hth

---

AFAIK Snort cannot drop traffic by itself. It needs some sort of firewall to be able to do this.
There should be some sysctl you can set during run time. On Freebsd it's net.inet.icmp.bmcastecho. On Linux it's probably the same one.

Which firewall are you using? iptables? ipchains?

iptables: put this in your script

Quote:

---

# disable ping reply and log incoming pings, so you'll get in /var/log/messages
# IP addresses of little Hackers trying to check if your host is up.
$IPT -A INPUT -i $iface -p icmp -s 0.0.0.0/0 --icmp-type echo-request -j LOG
$IPT -A INPUT -i $iface -p icmp -s 0.0.0.0/0 --icmp-type echo-request -j DROP

---

ipchains: pu this in your script

Quote:

---

# disable ping reply and log incoming pings, so you'll get in /var/log/messages
# IP addresses of little Hackers trying to check if your host is up.
$IPC -A input -l -i $iface -p icmp -s 0/0 echo-request -j DENY

---

Source

Forgot about this thread. Cheers for all your help. Fixed it by modifying /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts