On Tue, 03 Dec 2013, Martin Kraus wrote:
On Tue, Dec 03, 2013 at 01:04:03PM +0100, Alessandro Brega wrote:
Setup firewall (iptables) rules so that only traffic with a destination of my own IP space is accepted from other IXP participant. Drop any other traffic from IXP participants.
Hi. Implementing BCP38 on your outgoing interfaces, where you allow only ip packets with source ip address from your address allocation should prevent that and also protect others from spoofing attacks from your own network.
on the down side you'd have to process their traffic on the router or even route it through your internal network if your upstream is somewhere else but I don't think they would be pointing their static route at you for long if you drop the packets in the end.
The best practice for connecting to an IXP in Brazil is to: 1. Have BCP38 and BCP46 ingress and egress filtering deployed (strict!) 2. Have paranoid filtering on the control plane (BGP) 3. Don't be shy at depeering with anyone that causes repeated issues 4. Monitor closely the routing table received from the IXP, and traffic levels 5. Deploy flow collection and monitoring on the IXP interface 6. Keep historical (and hysterical ;-) ) data to know the baselines and trends for (4) and (5). We've seen "default gateway" and static route "transit stealing" attacks in IXPs around here. The IXPs have rules that allow participants to be removed with prejudice from the IXP should they statically route packets to others without permission, but the IXP is not going to police its L2 matrix hunting for violators: if the victim doesn't notice and complains, such abuse would go on unpunished and undetected. Besides, you need all that filtering to be able to sleep in peace anyway because the IXPs are always a few operator errors away from massive packet-loss events (be them restricted to some routes/participants, or IXP-wide). There are alternatives to ingress and egress "firewall/ACL" filtering, the most commonly used around here is strict uRPF. However, this requires a router (or VR instance) dedicated to interface with the IXP, *and* it causes some incoming (good) traffic to be droped due to the lack of return routes for that traffic inside the IXP. As for operating the IXP itself, there are some best-practices and operational reports published by several IXPs. I don't have the links to those readly available, but Google can find them reasonably easily, and they're well worth a read. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh