NetFlow is a very useful tool/protocol to monitor network traffic’s patterns. Many tools have been developed to collect and analyze NetFlow data, here I chose flow-tools and FlowViewer packages, and I would like to show how to get them work on a fresh Debian 5.0 (Lenny) setup.
Automatically filtering bogons with BGP and Team Cymru Bogon Route Server Project
What do you do if someone knocks at your door, you see him through the peephole, and you notice he has a black cowl, a crowbar and a big bag? I’m quite sure: you do not open that door! Why? Because, sometimes, the gown does make the friar! And, actually, he’s really not a friar!
Same thing should happen in a network! If you know a packet is a bad packet, why should you let it go through?
In this (stupid) example bad packets are those coming from or going toward bogon IP addresses, that is, addresses picked up from unallocated or private (so, not routable) address spaces. As you know, there are many subnets used only for private addressing (RFC 1918), other are reserved (RFC 3330), and few subnets are still not allocated by IANA… so, if your router is sending or receiving a packet to/from one of these addresses, there is something you should be concerned about (of course, some restrictions may apply!)
GNS3 Labs: Source-based Remote Triggered Black Hole (RTBH) Filtering with Unicast Reverse Path Forwarding (uRPF)
This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:
1. Remote Triggered Black Holing
2. BGP Customer triggered black holing
3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB
4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)
Stay tuned! 😉
Today I drew inspiration from a brand new RFC to add a post to this little series: RFC-5635, Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF).
Especially, I would like to focus on section 4 of this RFC, Source Address RTBH Filtering.
To fully understand this post I would suggest to read my previous post Remote Triggered Black Holing.
GNS3 Labs: BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB
This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:
1. Remote Triggered Black Holing
2. BGP Customer triggered black holing
3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB
4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)
Stay tuned! 😉
As I already wrote in my previous posts, an ISP can provide their customers some useful tools to mitigate (D)DoS attacks: Remote Triggered Black Holing and its NOC-independent version, Customer triggered black holing are tools that, once identified attacked hosts or networks, let us to stop malicious traffic at the provider’s edge.
Anyway, when we drop traffic toward attacked hosts, we can’t investigate the attack anymore; we would need a tool which allowed us to analyze traffic and, in the meantime, that would avoid wasting network resources. Our (dear) provider could provide it by implementing rate limiting and less-than-best-effort services using QoS Policy Propagation via BGP (QPPB).
GNS3 Labs: BGP Customer triggered black holing
This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:
1. Remote Triggered Black Holing
2. BGP Customer triggered black holing
3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB
4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)
Stay tuned! 😉
In this post I’ll show you how to let your customers to trigger black holing for their prefixes. What I will write is based on my previous post GNS3 Lab: Remote Triggered Black Holing: same scenario, same startup config (the final one of that post).