Securing 224.0.0.0/24 from the users, Secure EIGRP/PIM/OSFP

[bnidacoc]

I have been experimenting with ACLs on users VLANs in order to protect the network. ACLs to prevent IP spoofing, and preventing destination addresses like 0.0.0.0/24 and 127.0.0.0/24.

I also would to take means to prevent users from even conversing over multicast destined for 224.0.0.0/24. EIGRP/OSPF/PIM seem to use a number of addresses in this range. Yea, I know all about passive interface and deploy it already, but who knows what the next EIGRP unauthenticated vulnerability will reveal.

As far as I can tell, users only need to send to 224.0.0.2 (IGMP Leave Requests).

Anyone know of other legitimate 224.0.0.0/24 addresses which users would be sending to? Or, can anyone supply reasons for not even pursuing this task?

[smalkeric]

PIX Firewall software version 6.2 enables you to statically configure multicast routes or use an Internet Group Management Protocol (IGMP) helper address for forwarding IGMP reports and leave announcements.

This list summarizes multicast support in this release.

Access list filters can be applied to multicast traffic to permit or deny specific protocols and ports.

Network Address Translation (NAT) and Port Address Translation (PAT) can be performed on the multicast packet source addresses only.

Multicast data packets with destination addresses in the 224.0.0.0/24 address range are not forwarded. However, everything else in the 224.0.0.0/8 address range is forwarded.

IGMP packets for address groups within the 224.0.0.0 through 224.0.0.255 range are not forwarded because these addresses are reserved for protocol use.

NAT is not performed on IGMP packets. When IGMP forwarding is configured, the PIX forwards the IGMP packets (report and leave) with the IP address of the helper interface as the source IP address.

[bnidacoc]

Well, I'm talking about securing multicast from internal user's nasty tendencies, not a border point. My organization doesn't seem take MAC/IP source address spoofing seriously, but I do.

I am also interested in finding out what others are doing to prevent malicious activity in regards to multicast.

I simply can not buy, deploy and manage a PIX for every user VLAN (logical network) across 100 unique physically separated sites, thanks.

Since users have done a number of things I would consider malicious, like spoofing server's production IPs at their workstations (even though they are on a different logical network), their nasty tendencies may flow to multicast, particularly the 224.0.0.0/8 network. This one seems to be the reserved for administrative uses.

Anyone at all doing anything at all here?

[MIKE DOUGLAS]

Enable "ip verify unicast reverse-path" at the closest L3 interface to your users. That should take care of most of your spoofed source problems (not sure if this works for the multicast range of addresses or not).

[mheusinger]

Hello,

in case you are troubled by the possibility of users "attacking" your EIGRP/OSPF/PIM, why not just secure those protocols by passwords?

You can secure each OSPF interface by

interface Ethernet0

ip address 192.168.1.1 255.255.255.0

ip ospf message-digest-key 1 md5 MyKey

!

router ospf 10

network 192.168.1.1 0.0.0.0 area 0

area 0 authentication message-digest

You can secure EIGRP by

interface Ethernet0

ip authentication mode eigrp 1 md5

ip authentication key-chain eigrp 1 MyChain

key chain MyChain

key 1

key-string MyKey

On switches you could also setup MAC access-lists denying the multicast MAC addresses on access ports.

Hope this helps

Martin

P.S.: please rate all posts