Back in April we announced Rate Limiting of requests for every Cloudflare customer. Being able to rate limit at the edge of the network has many advantages: it’s easier for customers to set up and operate, their origin servers are not bothered by excessive traffic or layer 7 attacks, the performance and memory cost of rate limiting is offloaded to the edge, and more.
In a nutshell, rate limiting works like this:
Customers can define one or more rate limit rules that match particular HTTP requests (failed login attempts, expensive API calls, etc.)
Every request that matches the rule is counted per client IP address
Once that counter exceeds a threshold, further requests are not allowed to reach the origin server and an error page is returned to the client instead
This is a simple yet effective protection against brute force attacks on login pages and other sorts of abusive traffic like L7 DoS attacks.
Doing this with possibly millions of domains and even more millions of rules immediately becomes a bit more complicated. This article is a look at how we implemented a rate limiter able to run quickly and accurately at the edge of the network which Continue reading
A look at what's inside HCI and the cost considerations.
Don't ever underestimate the impact of randomization in a test environment
In episode 5 the Network Collective panel dives deep into the inner-workings of EIGRP and how to tune the protocol to work best for you. This isn’t your run of the mill EIGRP training session though, so buckle up and dig in to learn a lot about a protocol which appears pretty straight forward on the surface.
On another note… If you like the technical and community aspects of Network Collective, we wanted to tell you about a podcast that our friends over at Gestalt IT have just started up that you’ll probably enjoy as well. The name of their podcast is the On-Premise IT Roundtable and in addition to networking they will be covering topics like system architecture, storage, big data, virtualization, hyper-converged, and a slew of other topics. You should check them out.
Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/
Audio Only Podcast Feed:
The post Episode 5 – All You Ever Wanted To Know About EIGRP appeared first on Network Collective.
In episode 5 the Network Collective panel dives deep into the inner-workings of EIGRP and how to tune the protocol to work best for you. This isn’t your run of the mill EIGRP training session though, so buckle up and dig in to learn a lot about a protocol which appears pretty straight forward on the surface.
On another note… If you like the technical and community aspects of Network Collective, we wanted to tell you about a podcast that our friends over at Gestalt IT have just started up that you’ll probably enjoy as well. The name of their podcast is the On-Premise IT Roundtable and in addition to networking they will be covering topics like system architecture, storage, big data, virtualization, hyper-converged, and a slew of other topics. You should check them out.
Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/
Audio Only Podcast Feed:
The post Episode 5 – All You Ever Wanted To Know About EIGRP appeared first on Network Collective.
During Shawn Zandi’s presentation describing large-scale leaf-and-spine fabrics I got into an interesting conversation with an attendee that claimed it might be simpler to replace parts of a large fabric with large chassis switches (largest boxes offered by multiple vendors support up to 576 40GE or even 100GE ports).
As always, you have to decide between implicit and explicit complexity.
Read more ...Cybersecurity professionals know that security cannot be a bolt on process or technology. Likewise, I also believe that that the thought of including the security team is rarely goes far enough. To be effective, security should be ingrained and it should be pervasive. With a this commitment, there is at least one primary question that every organization should be asking in regards to Cybersecurity. That question is simply “Why?”
Not only should this question be asked organizationally, it should also be asked by individuals that are assuming security related roles within an organization. Some would think that the answer is simple or obvious. In many cases it is, but the complete answer WILL differ from organization to organization and differ based on the type of organization. What is important is that the organization itself agree upon the answer to this question.
Relevant answers to the Why question might be any or all of the following:
Governance—Specific regulatory requirements that the organization is required to meet. When these exist, they are often considered a top priority and a baseline requirement to transact business.
Cost/Expense—This could be direct and/or indirect. A direct example would be the typical scenario that occurs with ransomeware. Continue reading
Two interesting things I saw when listening to the output from my microwave:
Separate measurement some rooms away.
# Edit usrp_spectrum_sense.py so that it prints time.time() instead of datetime.now()
./usrp_spectrum_sense.py --dwell-delay=0.1 -A RX2 -s 8000000 --real-time 2.4e9 2.5e9 > near-microwave.txt
# Edit near-microwave to remove the stupid verbose messages from the top.
cat > microwave.plot << EOF
set view map
set size ratio .9
set object 1 rect from graph 0, graph 0 to graph 1, graph 1 back
set object 1 rect fc rgb "black" fillstyle solid 1.0
set xlabel 'Time in seconds'
set ylabel 'Frequency'
set zlabel 'dB'
set terminal epslatex color
set output "near-microwave.eps"
splot 'near-microwave.txt' using ($1-1496693552.11):((($5/1000-2400000)/1000)):4 with points pointtype 5 pointsize 3 palette linewidth 30 title 'Signal'
EOF
gnuplot microwave.plot
convert near-microwave.{eps,png}
I can’t have GNUPlot output PNG directly because it hangs.
The magic value 1496693552.11
is the first timestamp in the file.
An interesting incident this last week brings password managers back to the front of the pile—
I used to use LastPass, but moved off of their product/service when LogMeIn bought them—my previous encounters with LogMeIn have all been negative, and I have no intention of using their service again in any form. During that move, I decided it was important to make another decision about the tradeoff between an online (cloud based) password manager, or one that keeps information in a local file. The key problem with cloud based services of this kind are they paint a huge target onto your passwords. The counter argument is that such cloud based services are more likely to protect your passwords than you are, because they focus their time and energy on doing so.
First lesson: moving to a cloud based application does not mean moving to a situation where the cloud provider actually knows what you are storing, nor how to access Continue reading