Distributed Denial of Service (DDoS) Attacks

distributed denial of serviceIn the previous article, we discussed denial of service (DoS) attacks. These attacks involve the use of a single client to launch an attack on a system or service. Distributed denial of service (DDoS) attacks use the same basic attack methodologies as outlined in the previous article, with the exception that the attacks are initiated from multiple client systems.

The way this typically works is that malicious parties will use viruses to subtly gain control over large numbers of computers (typically poorly-defended home computers connected to broadband Internet connections). Unbeknownst to the owner of the computer (which generally continues to function as normal) the system is essentially a zombie waiting to be given instructions. Once the malicious party has gathered an army of zombie computers they are instructed to participate in massive distributed denial of service attacks on unsuspecting victims. A large enough volume of zombie systems can, and indeed have been known to bring down even the largest and most scalable enterprise infrastructure, and even bring parts of the Internet itself to a grinding halt. Merely purchasing more incoming bandwidth than the current volume of attack might not help, because the attacker might be able to simply add more attack machines.

Distributed Denial of Service Attacks: Advantages and Types

There are several advantages to launching a distributed denial of service attack:

  1. Multiple machines can generate more attack traffic than one machine.
  2. Multiple machines are harder to turn off than one attack machine.
  3. The behavior of each attack machine can be stealthier, making it harder to track and shut down.

Distributed denial of service can take several forms. Malware can carry distributed denial of service attack mechanisms. One of the better-known examples of this was MyDoom. Its DoS mechanism was triggered on a specific date and time. this type of distributed denial of service involved hardcoding the target IP address prior to the release of the malware. No further interaction was necessary to launch the attack.


A system may also be compromised with a trojan, allowing the attacker to download a zombie agent, or the trojan may contain one. Attackers can also break into systems using automated tools that exploit flaws in programs that listen for connections from remote hosts. A compromised system becomes known as a bot, and they are controlled by handlers run by the attacker, known as botnets. Many of these tools use classic DoS attack methods centered on IP spoofing and amplification like smurf and fraggle attacks, as well as SYN floods.

A distributed denial of service attack may involve sending forged requests to a very large number of computers that will reply to the requests. Using Internet Protocol address spoofing, the source address is set to that of the targeted victim, which means that all the replies will go to and flood the target.

The primary line of defense for blocking distributed denial of service attacks, as with DoS attacks, is the firewall. Firewalls can be set up to have simple rules to allow or deny protocols, ports or IP addresses. In the case of a simple attack coming from a small number of unusual IP addresses for instance, one could put up a simple rule to drop all incoming traffic from those attackers. But most complex attacks will be hard to block with simple rules. Additionally, firewalls may be too deep in the network hierarchy, although they can prevent users from launching simple flooding type attacks from machines behind the firewall.

Some stateful firewalls, like OpenBSD’s pf (and pfSense, since it’s based on pf), can act as a proxy for connections. Normally when a client initiates a TCP connection to a server, PF will pass the handshake packets between the two endpoints as they arrive. pf can proxy the handshake: pf itself will complete the handshake with the client, initiate a handshake with the server, and then pass packets between the two. In the case of a TCP SYN flood attack, the attacker never completes the three-way handshake, so the attacker’s packets never reach the protected server, but legitimate clients will complete the handshake and get passed. this minimizes te impact of spoofed TCP SYN floods on the protected service, handling it in pf instead.

Most switched also have some automatic and system-wide rate limiting, traffic shaping, delayed binding, deep packet inspection and Bogon (bogus IP) filtering to detect and block denial of service attacks. This will work as long as the distributed denial of service attack is something that can be prevented by using them. SYN floods can be prevented using delayed binding. Content-based DoS or DDoS may be prevented using deep packet inspection. And attacks originating from dark addresses can be prevented using Bogon filtering.


External Links:

Denial of service attack on Wikipedia

PF: Packet Filtering at www.openbsd.org

Traffic Shaping Wizard: Introduction

traffic shaping wizard

These are the options seen under the Wizards tab in the Traffic Shaper in pfSense 2.1.

Traffic Shaping Wizard Introduced

You can configure the traffic shaper through one of the traffic shaping wizards, manually through the pfSense web GUI, or even at by editing pf.conf in FreeBSD at the command line. It is recommended, however, that when you are using the traffic shaper for the first time, you use the traffic shaping wizard, which will guide you through the process. Due to the complexity of the shaper queues and rules, it is not a good idea to attempt starting out configuring the traffic shaper manually. If you need custom rules, step through the wizard and approximate what you will need, then make the custom rules afterward. Each screen will set up unique queues and rules that will control what traffic is assigned to the queues. If you want to configured everything manually, simply specify your WAN speed at the first screen, then click Next through all the remaining screens without actually configuring anything.


To start the traffic shaping wizard under pfSense 2.1, navigate to Firewall -> Traffic Shaper, and click on the “Wizards” tab. There are several different wizards, each one pertaining to a different pfSense network interface setup:

  • Single LAN multi WAN: There is one local network, but there are multiple interfaces for the WAN (this would be common in a load balancing scenario, in which outgoing and incoming traffic is distributed among two or more WAN interfaces). NOTE: You would also use this in the case where you only have one WAN and one LAN. Just specify 1 for the number of WAN links when going through the wizard
  • Single WAN multi LAN: There is only a single WAN interface, but there are multiple local networks.
  • Multiple LAN/WAN: This will set up traffic shaping in cases where you have both multiple local networks and multiple WAN networks.
  • Dedicated Links: This is for when you want to manage more than one link which gets routerd to a separate, different LAN in the same box. For example, assume you were providing services to 4 different customers in one building and they each had their own separate internet connections. You could run all 4 internet connections through a single pfSense box and provide different traffic shaping configurations for each. Thus, you could have several “virtual” links through a single interface.

In the next article, we will begin working our way through the traffic shaping wizard and look at the different options available within it.


Other Articles in This Series:

Traffic Shaping in pfSense: What it Does
QoS Management Using the Traffic Shaper Wizard
Queue Configuration in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Layer 7 Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

Traffic shaping at Wikipedia

External Links:

Traffic Shaping Guide at doc.pfsense.org

Link Ads:


Traffic Shaping in pfSense: What it Does

traffic shapingTraffic shaping is a computer network traffic management technique designed to delay some or all datagrams to bring them into compliance with a traffic profile. Without traffic shaping, packets are processed on a first in/first out basis by the firewall. Traffic shaping, or Quality of Service (QoS) offers a means of prioritizing different types of traffic. This ensures that higher priority services receive the bandwidth they need before lesser priority services. This helps to optimize or guarantee performance, improve latency, and/or increase usable bandwidth for some kinds of packets by delaying other kinds.

Another way of managing computer traffic is traffic policing. The difference between policing and shaping is that traffic policing propagates bursts. When the traffic rate reaches the configured maximum rate, excess traffic is dropped or remarked. The result is an output rate that appears on a graph as a saw-tooth with crests and troughs. In contrast to policing, traffic shaping retains excess packets in a queue and then schedules the excess for later transmission over increments of time. The result of traffic shaping is a smoothed packet output rate.


For purposes of this discussion, we are concerned mainly with traffic shaping in pf (and therefore pfSense). The way traffic shaping is accomplished in pf is that incoming traffic from the Internet going to a host on the LAN is actually shaped coming out of the LAN interface from the pfSense system. In the same manner, traffic going from the LAN to the Internet is shaped when leaving the WAN. This is because traffic has to be limited in a place where pf/pfSense can actually control the flow of data.

There are two means by which traffic shaping is accomplished: traffic shaping queues and traffic shaping rules. The queues are where bandwidth and priorities are actually allocated, while traffic shaping rules control how traffic is assigned into those queues. If a packet matches a shaper rule, it will be assigned into the queues specified by that rule. In that manner, traffic shaping rules are similar to firewall rules, with matching criteria and with outcomes dictated based on whether a packet matches the criteria.

Traffic Shaping: Reasons

The primary reasons you would use traffic shaping are to control access to available bandwidth, to ensure that traffic conforms to the policies established for it, and to regulate the flow of traffic in order to avoid congestion that can occur when the sent traffic exceeds the access speed of its target (remote) interface. Here are some examples why you might want to use traffic shaping:

  • Control access to bandwidth when policy dictates that the rate of a given interface should not on the average exceed a certain rate even though the access rate exceeds the speed.
  • If the network has differing access rates. Suppose that one end of the link in a Frame Relay network runs at 256 kbps and the other end of the link runs at 128 kbps. Sending packets at 256 kbps could cause failure of the applications using the link.
  • If you offer a subrate service. In this case, traffic shaping enables you to use the router to partition your T1 or T3 links into smaller channels.
  • Smoothing out asymmetric links, where the download speed differs from the upload speed (such as DSL connections). Some links are so out of balance that the maximum download speed is unattainable because it is difficult to send out enough ACK packets to keep traffic flowing. By using the traffic shaper to prioritize ACK packets you can achieve faster and more stable download speeds on asymmetric links.
  • Prioritizing VoIP calls. If your VoIP calls use the same circuit as data, then uploads and downloads may degrade your call quality. pf/pfSense can prioritize the call traffic above other protocols and ensure the calls make it through without breaking up.
  • Network gaming. There are also options to give priority to the traffic associating with networking gaming, even if you are downloading while playing.
  • P2P applications. By lowering the priority of traffic associated with known peer-to-peer ports, pf/pfSense ensures that P2P applications will not interfere with other traffic on your network.


Other Articles in This Series:

Traffic Shaping Wizard: An Introduction
QoS Management Using the Traffic Shaper Wizard
Queue Configuration in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Layer 7 Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

Traffic shaping at Wikipedia

Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting [QoS Policing] at www.cisco.com

Ad Links:


Failover with CARP in PF: Part Three (Checking for CARP & pfsync)

In the previous two articles in this series, I mentioned some of the advantages of using CARP and outlined a hypothetical CARP implementation involving two redundant firewalls. In this article, I will take it one step further and discuss how to configure the firewalls, starting by making sure your flavor of BSD has both CARP and pfsync enabled.

Making Sure CARP and pfsync Are Enabled

pfsync

Checking the value of the net.inet.carp variables at the command prompt in FreeBSD.

If you are setting this up on a pfSense box, then both the carp and pfsync devices should be compiled into the kernel. But if it isn’t, and you are running FreeBSD, then you need to check that the kernel has both these devices are compiled in. You can check for CARP with the following command:

sysctl net.inet.carp.allow

If you see:

net.inet.carp.allow=1

then your system comes equipped with CARP. If, however, you see something like:

sysctl: unknown old ‘net.inet.carp.allow’

then your kernel is not configured for CARP.

If you are running OpenBSD or NetBSD, you should heed the following regarding CARP and pfsync:

  • OpenBSD: Both carp and pfsync devices are in the default GENERIC and GENERIC.mp kernel configurations, so unless you are running a custom kernel, you should be OK.
  • NetBSD: NetBSD’s default generic kernel does not have CARP compiled in, and NetBSD does not yet support pfsync.

There are actually four CARP-related variables: net.inet.carp.allow, net.inet.carp.preempt, net.inet.carp.suppress_preempt, net.inet.carp.log, and net.inet.carp.arpbalance. Setting net.inet.carp.log to 1 gives you debug information about the CARP traffic you logged, but this is turned off by default. The inet.carp.arpbalance command load balances local network traffic using ARP. net.inet.carp.suppress_preempt is a read-only variable showing the status of preemption suppression. Preemption can be suppressed if the link on an interface is down. A value of 0 means that preemption is not suppressed. Every problem increments this variable.

The important variables are net.inet.carp.allow and net.inet.carp.preempt. Setting net.inet.carp.allow to 1 allows the system to accept incoming CARP packets (this option is enabled by default). For graceful failover between the gateways in our hypothetical network, we need to set the net.inet.carp.preempt variable to 1. Setting the net.inet.carp.preempt variable means that on hosts with more than one network interface, all CARP interfaces will set their advskew to the extremely high value of 240 in order to prod other hosts in the CARP group to start failover when one of the interfaces goes down. This setting needs to be identical on all hosts in the CARP group, so you need to repeat the setting on all hosts.


Creating the CARP Interfaces

Once we’re sure both CARP and pfsync are enabled, we want to set up the network interfaces. In part two, I specified that the external CARP interface (carp0) would have an IP of 50.87.147.42, and the internal CARP interface (carp1) would have an IP address of 192.168.10.1.

We first create the interfaces using ifconfig:

ifconfig carp0 50.87.147.42 vhid 1
ifconfig carp1 192.168.10.1 vhid 2

Here we do not need to set the physical interface explicitly The cp0 and cp1 virtual interfaces here will bind themselves to the physical interfaces that are already configured with addresses in the same subnets as the assigned CARP address. with ifconfig you should be able to check that each CARP interface is properly configured.

On the backup firewall, the ifconfig command is similar, except that you add the advskew parameter:

ifconfig carp0 50.87.147.42 vhid 1 advskew 100
ifconfig carp1 192.168.10.1 vhid 2 advskew 100

The advskew parameter indicates how much less preferred it is for the specified machine to take over for the current master. In this case, the master will announce every second (1 + 0/256), while the backup will wait for 1 + 100/256 seconds. Since we set net.inet.carp.preempt to 1, when the master stops announcing or announces it is not available, the backups will take over. Smaller advskew values mean shorter announcement intervals and higher likelihood for becoming the new master.

In the next article in this series, I will continue with configuration of our hypothetical CARP setup.

Correction

In Part Two of this series, I erroneously referred to the CARP interfaces as cp0 and cp1. They need to be carp0 and carp1. This has been corrected. I apologize for any inconvenience.


External Links:

Common Address Redundancy Protocol (CARP) at freebsd.org – a section from the FreeBSD handbook.

Book Review: The Book of PF

The Book of PFThe Book of PF: A No-Nonsense Guide to the OpenBSD Firewall (2nd Edition)
Author: Peter N.M. Hansteen
Publisher: No Starch Press
Publishing Date: November 19, 2010 (2nd Edition)
216 pages (paperback edition)

Book Review

In all my years in IT, I have read a number of computer books, but relatively few of these books I would count as indispensible. For C/C++, there was the elegantly written C Programming Language book written by Kernighan and Ritchie. When I learned Windows programming, Programming Windows® by Charles Petzold proved to be an invaluable resource. Around 1995-96 when I became interested in Java, I used one of the O’Reilly books as my tutorial. Some of the O’Reilly books (as well as ones produced by Sams Publishing) were invaluable in providing some of my initial education in Linux in the 1990s. So when I came across The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall by Peter N.M. Hansteen (2nd Edition, No Starch Press, 2010), I was curious to see how it would measure up.

As it turned out, The Book of PF is a worthwhile read, and for those seeking a more detailed understanding of PF, it should prove quite useful. The book is not a cookbook, as the author states fairly explicitly in the introduction. Thus it does not contain a series of how-to instruction sets; nonetheless, those with little knowledge of pf need not fear, as Hansteen starts with simple concepts and builds on these concepts in subsequent chapters. In this way, he is able to progress from very simple PF rule sets (e.g. block all outside traffic except the ports that need to be open, and only the protocols that are needed) sets to somewhat more involved rule sets (ones for networks that run SSH, FTP, and e-mail services), to even more complex rule sets that start to approximate real world scenarios. It also stresses the importance of making rule sets that are as granular as possible so as to allow only the traffic you really want. I like Hansteen’s attitude as well: he challenges readers not to cut and paste rule sets, but to think for themselves, and he also seems to disdain what he considers overly prophylactic policies such as blocking ping and traceroute. The book will also be a good guide for those who want to effectively protect their networks using such services as synproxy, relayd (for expiring nonfunctional hosts from a load balancing pool), and spamd (for blocking spam).


For those techies who only want to learn about pfSense, there are other books. If you just want to know the basics about how to configure your pfSense box, there’s the pfSense 2 Cookbook by Matt Williamson. If you want a more comprehensive explanation of pfSense’s features, pfSense: The Definitive Guide by Christopher M. Buechler (one of the co-founders of pfSense), Jim Pingle and Michael W. Lucas is likely the book for you. But for the network tech or admin who does not mind working primarily at the command line and editing rule sets manually, “The Book of PF” is a potentially valuable guide. Whether or not its worth your time to understand the nuances of pf is a cost-benefit analysis you will have to make yourself. But you will gain a greater degree of control you could ever hope to have working with the pfSense user interface alone. For example, take the problem of SSH brute force attacks. pfSense allows you to set a maximum number of connections per second, and you can block an IP address or a range of IP addresses. But as far as I know, pfSense does not enable you to set a maximum connection rate and add an IP address to a table of blocked IP addresses if it exceeds the rate. pf makes this possible, and this book shows you how. And this is just one example of how this book demonstrates how you can fine-tune your firewall’s settings; there are many other such instances.


For those really wanting to acquire an in-depth knowledge of pf, BSD and networking in general, Hansteen has included a list of resources as the first appendix to the book. Needless to say, it is chock full of helpful links and contains a bibliography which should provide a good starting point for anyone whose interest in BSD has been piqued.

In conclusion, The Book of PF is not for everyone, but if you are serious about network security, it can potentially be a useful guide. Not only will you be able to customize your firewall rules to meet your requirements, a working knowledge of pf is arguably even more valuable in the long term than a working knowledge of pfSense. pfSense superseded m0n0wall as the firewall/router of choice among many network security experts and will likely be superseded itself someday. pf may or may not be replaced as the primary packet filter for BSD users, but even if it is, my guess is that the structure of the rules will likely be similar, so if you have a good knowledge of pf, the learning curve should not be that steep. As the only in-depth book on pf, The Book of PF is recommended for anyone who wants to gain a better understanding of OpenBSD’s packet filtering engine.

External Links:

The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall at Amazon

Packet Filter: The Engine of pfSense

Packet FilterpfSense is, as most users know, a specialized version of FreeBSD. It can be configured an upgraded through a web-based interface and often runs on embedded systems; it requires no knowledge of the underlying FreeBSD system. Those curious enough to find out, however, will be interested to know that pfSense is based on OpenBSD’s powerful pf (Packet Filter) software, which was released in late 2001 and has since been ported to many other operating systems including FreeBSD, NetBSD, DragonFly BSD, Debian GNU/Free BSD, and Mac OS X 10.7 “Lion” and later.

OpenBSD and the other BSD variants are direct descendants of BSD Unix. BSD, sometimes called Berkeley Unix, is a Unix operating system derivative developed and distributed by the Computer Systems Research Group (CSRG) of the University of California, Berkeley, from 1977 to 1995. The final release from Berkely was 1995’s 4.4BSD-Lite Release 2, after which the CSRG was dissolved and development of BSD at Berkeley ceased. In the meantime, as CSRG was winding down, small groups of enthusiasts around the world began working on further development of the code. Several different variants of BSD Unix came into existence. The OpenBSD group became known as the most security-oriented of the BSDs. For its packet filtering needs, it used a program called IPFilter, written by Darren Reed.


The packet filter’s main function is to filter network packets by matching the properties of individual packets and the network connections build from those packets agains the filtering criteria defined in its configuration files. The packet filter is responsible for deciding what to do with those packets, which could mean passing them through or rejecting them, or triggering events that other parts of the operating system or external applications are set up to handle.

The IPFilter subsystem performed this function within OpenBSD, but in May 2001, IPFilter was removed from the OpenBSD source tree due to licensing issues. The OpenBSD version of IPFilter contained several changes and customizations that, as it turned out, were not allowed under the licensing agreement. For a few weeks, the development version of OpenBSD did not include any firewalling software.


Enter Packet Filter

However, Daniel Hartmeier had already begun work on his own packet filtering software, called PF, and after a few months of development, it was ready to be added to OpenBSD. PF was added as a default part of the OpenBSD 3.0 base system in December 2001. Migrating from IPFilter to PF sense did not pose major problems, as their configuration languages were similar. Moreover, PF has done well in performance tests, performing equally well or better under stress on OpenBSD 3.1 than either IPFilter on OpenBSD 3.1 (or iptables on Linux). PF’s overhead is relatively low, and is capable of running effectively on rather modest hardware.

Future installments of this series of articles will go into greater depth on how to configure and run PF. For now, it should be mentioned that in order to run PF, you need to install and run a BSD system such as OpenBSD, FreeBSD, NetBSD, or DragonFly BSD. OpenBSD is the BSD variant of choice for many, as this is where PF was first introduced and where essentially all PF development happens. Moreover, the newest and most-up-to-date PF code is always to be found on OpenBSD. If you are planning to run PF on FreeBSD, NetBSD, DragonFly BSD, or another system, you should check your system’s release notes and other documentation about which version of PF is included.

External Links:

PF documentation in the OpenBSD FAQ

© 2013 David Zientara. All rights reserved. Privacy Policy