On 2017 Jan 12 (Thu) at 11:18:58 +0100 (+0100), Uday MOORJANI wrote: :Dear OpenBSD-Misc, : :First of all, awesome work on the OpenBGPd and BFD code. I'm working on a :WAN setup for an enterprise and we are migrating from static route WAN to a :full fledge BGP transit in a multi home environment for the specific :purpose of providing the best possible path/route to our service catalogue. :The service catalogue within the enterprise is orchestrated by a private :vmware cloud with added software defined networking (micro-segmentation) :capabilities within the private cloud via NSX. : :My concern is about DDoS protection from the ingress traffic, in my logic :it makes no sense to contract a service such as Imperva or Cloudflare as :DDoS protection on the network level, as proper PF (firewall) rules in :place should protect us at line rate. My doubts are: :
There are basically two types of DDoS seen in the wild. The first type is "overload the pipes". Lots of massive packets, 50Gbps and larger, etc, etc. This is the kind that hits the news. By definition, you cannot defend against this on-site. The other type is "overload the application". Small packets, usually. Something that is "too small" to be detected by your anti-DDoS mechanisms, but is painful for the end application. A common method is SYNs without ACKs, overloading the sockets or state table on a web server. OpenBSD cannot help with the first type, as the pipes to the OpenBSD system are already full. OpenBSD *can* help with the second type, depending on how many pps the system can handle. If the OpenBSD machine can protect at the line rates needed, then you can set up rules that protect. For upsream DDoS protection, there are also two types. Block. Scrub. Blocking is usually included in your transit provider and is pretty limited. You announce the victim IP with a blackhole community, and your upstream provider blocks traffic to that destination at their edge. Depending on your provider, this can be granular to the Country or Region you are in; or even to specific Protocol/Port combinations. Scrubbing services will take all of the traffic, use $$$ magic to figure out what is safe and what isn't, charge you, then send the "clean" traffic to the original destination. :- Are the rules provided for anti-ddos sufficient? Is there a good soul to :share some rulesets? :- Am I out of my mind for choosing OpenBGPd/OpenBSD for my transit WAN? I :love the fact that we're sandboxed and hyperthreaded and am particularly :content with the resolution of convergence time problems ( :http://undeadly.org/cgi?action=article&sid=20151106171337&mode=expanded) At work we use OpenBSD/OpenBGPd on most of our edge routers, and are very happy with them. They perform well enough for our traffic requirements. :- Is there a way to contract a support in case sh*t hits the fan with Yes, there are several listed at http://www.openbsd.org/support.html. The company I work for also has support available. :OpenBGPd? :- What are the best tools to supervise and test bed the performance of an :OpenBGPd instance? (most the definately the dumbest question) : This is surprisingly complicated. There are lots of potential things to test performance. Most likely the one you care about is how many packets-per-second the router can handle, and for that you just need a packet blasting system. There are commercial entities and there are free software tools. For testing BGP itself, I use either self-written scripts using exabgp/bird, or live internet traffic by updating one of our edge routers. :Again, love the fact I can get some sleep with OpenBSD/OpenBGPd, please do :get back to me for commercial support to calm the nerves. : :Sincerely, : :Uday MOORJANI : -- There are no games on this system.
