Hi guys, right now I have a quagga router, but I'm open to switch to bird if it makes sense and helps me with my problem below. My router has two transit neighbors and announcing my own IP space. I recently joined a public peering exchange (IXP) and so I'm part of their local network (/24), together with all other participants. So far everything works fine. Now for security I wonder if other participants could not simply route all their outgoing traffic through me? For example what happens if any other participant would point a default route to my IXP ip. If I understand correctly all outgoing traffic from that participant would then go to my router which would route it to the internet using my transit uplink, right? So I wonder if I have to take any measures against it. My ideas are: 1. 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. 2. Somehow make quagga use a different kernel routing table for each neighbor (or peer-group). The routing table for the IXP neighbors would not contain any entries except for my own IP space and so no routing using my ip transit uplinks would occur. Looking at the output of ip rule showshows quagga is not doing this automatically? Would bird do this automatically? Am I on the right track? How do other routers like bord or hardware routers (cisco, juniper, ..) deal with this problem? Thank you for any help! Alessandro
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. cheers mk
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
Вторник, 3 декабря 2013, 13:04 +01:00 от Alessandro Brega <alessandro.brega1@gmail.com>:
Hi guys, right now I have a quagga router, but I'm open to switch to bird if it makes sense and helps me with my problem below. My router has two transit neighbors and announcing my own IP space. I recently joined a public peering exchange (IXP) and so I'm part of their local network (/24), together with all other participants. So far everything works fine. Now for security I wonder if other participants could not simply route all their outgoing traffic through me? For example what happens if any other participant would point a default route to my IXP ip. If I understand correctly all outgoing traffic from that participant would then go to my router which would route it to the internet using my transit uplink, right? So I wonder if I have to take any measures against it. My ideas are: * 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. * Somehow make quagga use a different kernel routing table for each neighbor (or peer-group). The routing table for the IXP neighbors would not contain any entries except for my own IP space and so no routing using my ip transit uplinks would occur. Looking at the output of ip rule showshows quagga is not doing this automatically? Would bird do this automatically? Not sure about quagga and multiple kernel routing tables (at least without external patch), but BIRD supports multiple routing tables internally and each internal table could be attached and synchronized with kernel. By using Linux PBR (Policy-Based Routing) mechanisms (see ip-rule(8) for more information) you could accomplish task in your second setup (different kernel routing tables).
An minimal PBR config might look like this: ----------------------------------------------------- ip -4 rule add pref 10000 iif <iface2ixp> table ixp ip -4 rule add pref 10000 iif lo from <ip_on_iface2ixp> table ixp (do not forget to add mapping between symbolic name of the routing table "ixp" and routing table number to /etc/iproute2/rt_tables) In BIRD configuration you should create routing table instance, attach kernel syncer protocol to it (kernel protocol). Populate routing table at least with following routes: directly connected network on <iface2ixp> (needed to establish sessions with IXP RSes for example), routes to your ip space, blackhole default route (to match all other routes not in table and drop traffic). Am I on the right track? How do other routers like bord or hardware routers (cisco, juniper, ..) deal with this problem?
Thank you for any help! Alessandro
-- SP5474-RIPE Sergey Popovich
Hey Alessandro, As for you question: There are two levels that you should notice while this can or cannot happen. If your network has couple peers and for example the end of the Fiber Optic cables is attached at the IXP to a machine that you *own* you will see one thing. While if your machine is in the other end of the cable and a switch that is owned by the IXP is managing the traffic your strategy would be different. Since IXP have rules every participant would be obligated to not abuse other peers without at-least contact the IXP or ISP management. If one of the peers would be found abusing you, he will need eventually to pay for the *usage* of bandwidth since it's the same thing like using your friend car without permission. Most public IXP ISPs or companies would not try to abuse others peers intentionally but sometimes it can happen that an automated system was missing a "column" or whatever and someone made a mistake. It would be preferable to define a rule in the switch that would not allow any "rouge" traffic to be dropped\blocked but this is not a security measure but a smart thing to implement if possible. The basic general rule is to use a policy route rule that applies to a specific interface and specific traffic. For example: "for interface0 allow only traffic from my internal src IPs" This will protect you from rouge clients inside your network imposing to other IP addresses. But this logic is more of a FIREWALL and\or IPTABLES logic. In a router you don't want any unneeded processing that is above the routing level! When you use a tool like PING for example and the kernel determines that there is no "route" in the routing table which matches the host it will drop in the terminal something like "no route to this host". Inside a router it's another story in a completely lower level in the kernel. The kernel "catch" a packet from the interface and put it in the corresponding routing "table" which then if found and only if found a route "best" matches it will use it to just "put" the packet into the cable again towards the next router in the network changing couple tiny binary data. There should not be a "default" route in use in the router that applies also on the *forwarded* traffic. (I will not say anything regarding using a default route globally) Once you have a route policy which "throw" the traffic that is either flowing from your network IP masks or flowing towards your IP masks in the right interfaces you can throw it towards the right routing table which contains only the needed routes. Remember that the packet has only one IP address as a src and one IP address as a dst which can be matched for two different interfaces but there are packets that will never contain src IP address on a specific interface. If you must use IPTABLES for securing your router host there is a NO_TRACK module in IPTABLES which should assist you to avoid any connection tracking for the FORWARD table by removing any unneeded load on the kernel and kernel modules operations. I have read about something regarding using packet MARKING(not connection marking) and IPTABLES which can help while applying dynamic rules on LB routers. One system that can demonstrate a Linux routing system setup would be VYATTA which already uses quagga. The algorithm that cisco or juniper apply that you have asked about is not public(to me) and in the case of a Linux kernel it would not even make sense to look at their settings or code. It's sounds to me like "I have a drill and I want to put a nail in the wall". I would just first ask at the IXP what administrative rules they have and what are the basic support I have from them about a case I need their help to block some traffic or even contact the abuser by phone or knock his office\home door. Traffic flowing towards your router do add overhead to the CPU and power-consumption if continues a long period of time. Regards, Eliezer On 03/12/13 14:04, Alessandro Brega wrote:
Now for security I wonder if other participants could not simply route all their outgoing traffic through me? For example what happens if any other participant would point a default route to my IXP ip. If I understand correctly all outgoing traffic from that participant would then go to my router which would route it to the internet using my transit uplink, right?
participants (5)
-
Alessandro Brega -
Eliezer Croitoru -
Henrique de Moraes Holschuh -
Martin Kraus -
Сергей Попович