In previous blog postings, I have discussed how the open source community has created powerful packet sniffing tools, and how they can be used either to administer your network or to attack it. Because these sniffing tools are open source, and because it is relatively easy to place a Linux host on your company network, you need to consider ways to minimize improper use of packet capturing tools. Encryption solutions, such as Secure Shell (SSH) and Kerberos, are two common solutions to this problem.

Algorithms are the underlying foundation of cryptography. Thus, we will look at the basics of algorithms first, starting with symmetric and asymmetric encryption.

Cryptography Defined

Cryptography predates the computer era; as long as people have been writing down information, there has been a need to keep some information secret, either by hiding its existence or changing its meaning. Encryption, a type of cryptography, refers to the process of scrambling information so that the casual observer cannot read it. An algorithm is a set of instructions for mixing and rearranging an original message (called plaintext), with a message key to create a scrambled message, referred to as ciphertext. Similarly, a cryptographic key is a piece of data used to encrypt plaintext to ciphertext, and ciphertext to plaintext, or both, depending on the type of encryption.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

The word crypto has its origins in the Greek word kruptos, which means hidden. The objective of cryptography is to hide information so that only the intended recipients can read it. In crypto terms, the hiding of information is called encryption, and when information becomes readable, it is called decryption. A cipher is used to accomplish the encryption and decryption. The information that is being hidden is called plaintext; once it has been encrypted, it is called ciphertext. The ciphertext is transported to the intended recipient or recipients, where it is decrypted back into plaintext.

Finally, there are two different subclasses of algorithms: block ciphers and stream ciphers. Block ciphers work on blocks or chunks of text in a series. In contrast a stream cipher operates on each individual unit, either letters or bits, of a message.

There are many different encryption algorithms, and in each case, there are tradeoffs between security, speed, and ease of implementation. Here, security indicates the likelihood of an algorithm to stand up to current and future attacks, speed refers to the processing prower and time required to stand up to current and future attacks, speed refers to the processing power and time required to encrypt and decrypt a message, and ease of implementation refers to an algorithm’s predisposition (if any) to hardware or software usage. Each algorithm has different strengths and drawbacks and none of them are ideal in every way. The key algorithms fall into three main categories:

• Symmetric cryptography
• Asymmetric cryptography
• Hashing algorithms

In the next few articles, we will review each of these categories.

External Links:

Cryptography at Wikipedia

Cryptography I – enroll in a free 6-week course in cryptography at coursera.org

The post Cryptography: An Introduction appeared first on pfSense Setup HQ.

Data Encryption Standard (DES).

The most commonly used type of encryption is symmetric encryption, which is aptly named because it uses one key for both the encryption and decryption process. Symmetric encryption is also commonly referred to as secret-key encryption and shared-secret encryption, but all terms refer to the same class of algorithm.

The reason why symmetric encryption systems are abundant is speed and simplicity. The strength of symmetric algorithms lies primarily in the size of the keys used in the algorithms, as well as the number of cycles each algorithm employs. The cardinal rule is “fewer is faster”.

By definition, all symmetric algorithms are theoretically vulnerable to brute-force, which are exhaustive searches of all possible keys. Brute-force attacks involve methodically guessing what the key to a message may be. Given that all symmetric algorithms have a fixed key length, there are a large number of possible keys that can unlock a message. Brute-force attacks methodically attempt to check each key until the key that decrypts the message is found. However, brute-force attacks are often impractical, because of the amount of time necessary to search the keys is greater than the useful life expectancy of the hidden information. No algorithm is truly unbreakable, but a strong algorithm takes so long to crack that it is impractical to try. Because brute-force attacks originate from computers, and because computers are continually improving in efficiency, an algorithm that may be resistant to attacks by computers 5 to 10 years in the future.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

Data Encryption Standard

Among the oldest and most famous encryption algorithms is the Data Encryption Standard (DES), the use of which has declined with the advent of algorithms that provide improved security. DES was based on the Lucifer algorithm invested by Horst Feistel. Essentially, DES uses a single 64-bit key – 56 bits of data and 8 bits of parity – and operates on data in 64-bit chunks. This key is broken into 16 48-bit subkeys, one for each round, which are called Feistel cycles.

Each round consists of a substitution phase, wherein the data is substituted with pieces of the key, and a presentation phase, wherein the substituted data is scrambled (re-ordered). Substitution operations, sometimes referred to as confusion operations, occur within S-boxes. Similarly, permutation operations (sometimes called diffusion operations) are said to occur in P-boxes. Both of these operations occur in the “F Module”. The security of DES lies in the fact that since the substitution operations are non-linear, the resulting ciphertext does not resemble the original message. The permutation operations add another layer of security by scrambling the already partially encrypted message.

Triple DES (3DES) and DESX are methods that attempt to use the DES cipher in a way that increases in security. Triple DES uses three separate 56-bit DES keys as a single 168-bit key, though sometimes keys 1 and 3 are identical, yielding 112-bit security. DESX adds an additional 64 bits of key data. Both 3DES and DESX are intended to strengthen DES against brute-force attacks. it would take many years to decrypt 3DES encrypted date (depending on available computing power). However, 3DES is inefficient because it requires two to three times the processing overhead as a single DES.

Shortcomings of Data Encryption Standard

For Data Encryption Standard, questions were raised about the adequacy of its key size from the start, even before it was adopted as a standard, and it was the small key size which dictated a need for a replacement algorithm. In academia, various proposals for a DES-cracking machine were advanced. Although there is no known publicly acknowledged implementation of these Data Encryption Standard-cracking machines, by the late 1990s, the vulnerability of DES was practically demonstrated. In 1997, RSA Security sponsored a series of contests, offering a $10,000 prize to the first team that broke a message encrypted with DES for the contests. That contest was won by the DESCHALL Project. The feasibility of cracking DES quickly was demonstrated in 1998 when a custom DES-cracker was built by the Electronic Frontier Foundation (EFF) at the cost of approximately $250,000 (u.S.). They were able to crack a DES key using a brute-force attack in less than two days. Subsequent improvements in processing power employed by other DES crackers reduced this time to less than a day. Because of the ease with which DES could be cracked, the National Institute of Standards and Technology (NIST) selected the Advanced Encryption Standard (AES) as the authorized Federal Information Processing Standard (FIPS) 197 for all non-secret communications by the U.S. government, which became effective in May 2002.

External Links:

Data Encryption Standard (DES) on Wikipedia

The post Data Encryption Standard (DES) appeared first on pfSense Setup HQ.

The subbytes step of AES encryption.

AES Encryption

Because of the small key size of 56 bits, DES can’t withstand coordinated brute-force attacks using modern cryptanalysis; dedicated machines can now break DES within a day. Consequently, The National Institute of Standards and Technology (NIST) selected the Advanced Encryption Standard (AES) as the authorized Federal Information Processing Standard (FIPS) 197 for all non-secret communications by the U.S. government, which became effective in May 2002. AES is included in the ISO/IEC 18033-3 standard. AES has the following important characteristics:

• Private key symmetric block cipher (similar to DES)
• Stronger and faster than 3DES
• Life expectancy of at least 20 to 30 years
• Supports key sizes of 128 bits, 192 bits, and 256 bits
• Freely available to all; royalty free, non-propriety, and not patented
• Small footprint: AES can be used effectively in memory and in central processing unit (CPU) limited environments such as smart cards

It should be noted that the AES (Rjindael) algorithm was selected by NIST from a group that included four other finalists: MARS, RC6, Serpent, and Twofish. It was developed by Belgian cryptographers Dr. Joan Daemen and Dr. Vincent Rijmen. (The name Rjindael is a play on the names of the two inventors, Daemen and Rijmen.) It seems resistant to side-channel attacks such as power- and timing-based attacks, which are attacks against a hardware implementation, not against a particular algorithm. For example, power-and timing-based attacks measure the time it takes to encrypt a message or the minute echanges in power consumption during the encryption and decryption process. Occassionally, these attacks are sufficient enough to allow hackers to recover keys used by the device.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

Unlike DES, which uses Feistel cycles in each round, Rijindael uses iterative rounds like International Data Encryption Algorithm (IDEA). It is a minor revision of an earlier cipher, Proposed Encryption Standard (PES). Data operates on 128-bit chunks, which are grouped into four groups of 4 bytes each. The number of rounds is also dependent on the key size, such that 128-bit keys have 9 rounds, 192-bit keys have 11 rounds, and 256-bit keys have 13 rounds. Each round consists of a substitution step of one S-box per data bit, followed by a pseudo-permutation step in which bits are shuffled between groups. Then each group is multiplied out in a matrix fashion and the results are added to the subkey for the round.

IDEA Encryption

The European counterpart to the DES algorith is the IDEA. Unlike DES, which it was intended as a replacement for, it is a considerably faster and more secure. IDEA’s enhanced speed is due to the fact that each round consists of simpler operations than in the Feistel cycle in DES. IDEA uses simple operations like exclusive or (XOR), addition and multiplication, which are more efficient to implement in software than the substitution and permutation operations of DES. Addition and multiplication are the two simplest binary calculations for a computer to perform, and XOR is also a simple operation.

IDEA operates on 64-bit blocks with a 128-bit key, and the encryption/decryption process uses eight rounds with six 16-bit subkeys per round. The IDEA algorithm is patented both in the U.S. and in Europe, but free non-commercial use is also permitted. IDEA is widely recognized as one of the components of Pretty Good Privacy (PGP) version 2.0. It is also an optional algorithm in the OpenPGP standard. IDEA was developed in the early 1990s by cryptographers James Masey and Xuejia Lai as part of a combined research project between Ascom and the Swiss Federal Institute of Technology. The algorithm was patented in a number of countries, but was freely available for non-commercial use. “IDEA” is also a trademark. The last patents expired in 2012, and IDEA is now free to use for both commercial and non-commercial purposes.

External Links:

Advanced Encryption Standard (AES) at Wikipedia

International Data Encryption Algorithm (IDEA) at Wikipedia

The post AES and IDEA Encryption Algorithms appeared first on pfSense Setup HQ.

The biggest disadvantage to using symmetric encryption algorithms relates to key management. In order to ensure confidentiality of communication between two parties, each communicating pair needs to have a unique secret key. As the number of communicating pair needs to have a unique secret key, As the number of communicating pairs increases, there is a need to manage a number of keys related to the square of the communicators, which quickly becomes a complex problem.

Introducing Asymmetric Encryption

Asymmetric encryption algorithms were developed to overcome this limitation. Also known as public-key cryptography, these algorithms use two different keys to encrypt and decrypt information. If cleartext is encrypted with an entity’s public key, it can only be decrypted by the public key. The basic principle is that the public key can be freely distributed, while the private key must be held in strict confidence. The owner of the private key can encrypt cleartext to create cyphertext that can only be decoded with its public key, thus assuring the identity of the source, or it can use the private key to decrypt cyphertext encoded with its public key, assuring the confidentiality of the data. Although these keys are generated together and are mathematically related, the private key cannot be derived from the public key.

Instead of relying on the techniques of substitution and transportation that symmetric key cryptography uses, asymmetric encryption algorithms rely on the use of large-integer mathematics problems. Many of these problems are simple to do in one direction but difficult to do in the opposite direction. For example, it is easy to multiply two numbers together, but it is more difficult to factor them back into the original numbers, especially if the integers used contain hundreds of digits. Thus, in general, the security of asymmetric encryption algorithms is dependent not upon the feasibility of brute-force attacks, but the feasibility of performing difficult mathematical inverse operations and advances in mathematical theory that may propose new “shortcut” techniques.

Asymmetric encryption  is much slower than symmetric encryption. There are several reasons for this. First, it relies on exponentiation of both a secret and public exponent, as well as generation of a modulus. Computationally, exponentiation is a processor-intensive operation. Second, the keys used by asymmetric encryption algorithms are generally larger than those used by symmetric algorithms, because the most common asymmetric attack, factoring, is more efficient than the most common symmetric attack: brute force.

Because of this, asymmetric encryption algorithms are typically used only for encrypting small amounts of information. In subsequent articles, we will example different asymmetric algorithms, such as Diffie-Hellman, RSA, and El Gamal.

External Links:

Public-key cryptography at Wikipedia

The post Asymmetric Encryption appeared first on pfSense Setup HQ.

In the previous article, I provided an overview of asymmetric encryption. Today, we begin our look at asymmetric algorithms, starting with Diffie-Hellman.

The biggest problem in symmetric cryptography is the security of the secret key. Obviously, you cannot transmit transmit the key over the same medium as the ciphertext, since any unauthorized parties observing the communications could use the key to decode the messages. Prior to the development of asymmetric cryptography and the Diffie-Hellman key exchange, secret keys were exchanged using trusted private couriers and other out-of-band methods.

In the mid-1970s, Whitfield Diffie and Martin Hellman published the Diffie-Hellman algorithm for key exchange, which allowed a secret key to be transmitted securely over an insecure line. This was the first published use of public-key cryptography, and one of the cryptography field’s biggest advances. With the Diffie-Hellman algorithm, the DES secret key – sent with a DES-encrypted payload message – could be encrypted via Diffie-Hellman by one party, and decrypted only by the intended recipient.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

Because of the inherent slowness of asymmetric cryptography, the Diffie-Hellman algorithm was not intended for use as a general encryption scheme. Rather, its purpose was to transmit a private key for DES (or a similar symmetric algorithm) across an insecure medium. In most cases, Diffie-Hellman is not used for encrypting a complete message, because it is much slower than DES, depending on implementation.

The Diffie-Hellman Key Exchange in Practice

In practice, this is how a key exchange using Diffie-Hellman works:

1. Two parties agree on two numbers; one is a large prime number, the other is a small integer number. This can be done in the open, as it does not affect security.
2. Each of the two parties separately generate another number, which is kept secret. This number is equivalent to a private key. A calculation is made involving the private key and the previous two public numbers. The result is sent to the other party. THe result is effectively a public key.
3. The two parties exchange their public keys. They then perform a calculation involving their own private key and the other party’s public key. The resulting number is the session key. Each party should arrive at the same number.
4. The session key can be used as a secret key for another cipher, such as DES. No third party monitoring the exchange can arrive at the same session key without knowing one of the private keys.

The simplest and the original implementation of the protocol uses the multiplicative group of integers modulo p, where p is prime and g is primitive root mod p. Actual implementations require using large numbers to achieve security. The protocol is considered secure if the initial numbers are chosen properly. The eavesdropper would have to solve the Diffie-Hellman problem to obtain the secret keys. This is currently considered difficult. An efficient algorithm to solve the discrete logarithm problem would make it easy to compute a or b and solve the Diffie-Hellman problem, making this and many other public key cryptosystems insecure.

Diffie-Hellman’s greatest strength is that anyone can know either or both of the sender’s and recipient’s public keys without compromising the security of the message. Both the public and private keys are actually very large integers. The Diffie-Hellman algorithm takes advantage of complex mathematical functions known as discrete logarithms, which are easy to perform forward, but extremely difficult to inverse. Secure Internet Protocol (IPSec) uses the Diffie-Hellman algorithm in conjunction with the Rivest, Shamir, & Adleman (RSA) authentication to exchange a session key used for encrypting all traffic that crosses the IPsec tunnel.

External Links:

Diffie-Hellman key exchange at Wikipedia

The post Diffie-Hellman Algorithm appeared first on pfSense Setup HQ.

In the previous article, we discussed the Diffie-Hellman algorithm. In this article, we will cover two more asymmetric encryption algorithms, El Gamal and RSA.

El Gamal Algorithm

The El Gamal algorithm is essentially an updated and extended version of the original Diffie-Hellman algorithm based on discrete logarithms. The security of the algorithm is roughly on par with that of the Rivest-Shamir-Adleman (RSA) algorithm. El Gamal has a few drawbacks, mainly its larger output and random input requirement. Encrypted El Gamal ciphertext is much longer than the original plaintext input, so it should not be used in places where bandwidth is a limiting factor, such as over slow wide area network (WAN) links. The El Gamal algorithm also requires a suitable source of randomness to function properly. It is worth noting that the Digital Signature Algorithm (DSA) was based on the El Gamal algorithm. DSA is a complementary protocol to RSA that is widely used in the OpenSSH implementation of the Secure Shell (SSH) protocol.

RSA Algorithm

Shortly after the appearance of the Diffie-Hellman algorithm, Ron Rivest, Adi Shamir and Leonard Adleman proposed another public key encryption system. Their proposal is now known as the RSA algorithm, named for the last initials of the researchers.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-8834983181171783"
data-ad-slot="8926342897">

The RSA algorithm shares many similarities with the Diffie-Hellman algorithm in that RSA is also based on multiplying and factoring large integers. However, RSA is significantly faster than Diffie-Hellman, leading to a split in the asymmetric cryptography field that refers to Diffie-Hellman and similar algorithms as Public Key Distribution System (PKDS), and RSA and similar algorithm as Public Key Encryption (PKE). PRDS systems are used as session-key exchange mechanisms, while PKE systems are considered fast enough to encrypt small messages. However, PKE systems like RSA are not considered fast enough to encrypt large amounts of data such as entire file systems or high-speed communications lines.

RSA involves a public key and a private key. The public key can be known by everyone and is used for encrypting messages. Messages encrypted with the public key can only be decrypted in a reasonable amount of time using the private key. The keys for the RSA algorithm are generated the following way:

1. Choose two distinct prime numbers p and q: For security purposes, the integers p and q should be chosen at random and should be of similar bit-length.
2. Compute n = pq: n is used as the modulus for both the public and private keys; its length is the key length.
3. Compute φ(n) = φ(p)φ(q) = (p-1)(q-1), where φ is Euler’s totient function.
4. Choose an integer e such that 1 < e < φ(n) and gcd(e, φ(n)) = 1; i.e. e and φ(n) are coprime.
5. Determine d and d^-1 ≡ e(mod φ(n)), i.e., d is the multiplicative inverse of e (modulo φ(n)).

The public key consists of the modulus n and the public (or encryption) exponent e. The private key consists of the modulus n and the private (or decryption exponent d, which must be kept secret. p, q and φ(n) must also be kept secret because they can be used to calculate d.

External Links:

ElGamal encryption on Wikipedia

RSA on Wikipedia

The post El Gamal and RSA Algorithms appeared first on pfSense Setup HQ.

Introduction to Hash Functions

Hashing is a technique in which an algorithm (also called a hash function) is applied to a portion of data to create a unique digital “fingerprint” that is a fixed-size variable. If anyone changes the data by so much as one binary digit, the hash function will produce a different output (called the hash value or a message digest) and the recipient will know that the data has been changed. Hashing can ensure integrity and provide authentication. The hash function cannot be reverse-engineered: in other words, you cannot use the hash value to discover the original data that was hashed. Thus, hashing algorithms are referred to as one-way hashes. A good hash function will not not return the same result from two different inputs (returning the same result from two different inputs is known as a collision). The collision domain of the function should be large enough to make it extremely unlikely to have a collision. All of the encryption algorithms studied so far, both symmetric and asymmetric, are reversible. However, there is no reversible function for hashing algorithms, so original material cannot be recovered. For this reason, hashing algorithms are commonly referred to as one-way hashing functions. Irreversible encryption techniques, however, are useful for determining data integrity and authentication. It is easy to generate hash values from input data and easy to verify that the data matches the hash, but hard to fake a hash value to hide malicious data. This is the principle behind the Pretty Good Privacy algorithm for data validation.

Sometimes it is not necessary or even desirable to encrypt a complete set of data. Suppose someone wants to transmit a large amount of data, such as a CD image. If the data on the CD is not sensitive, they may not care that it is openly transmitted, but when the transfer is complete, they want to make sure the image you have is identical to the original image. The easiest way to make this comparison is to calculate a hash value on both images and compare results. If there is a discrepancy of even a single bit, the hash value of each will be radically different. Provided they are using a suitable hashing function, no two inputs will result in an identical output, or collision. The hashes created, usually referred to as digital fingerprints, are usually of a small, easily readable fixed size. Sometimes these hashes are referred to as secure checksums, because they perform similar functions as normal checksums, but are inherently more resistant to tampering.

Encrypted passwords are often stored as hashes. When a password is set for a system, it is generally passed through a hashing function and only the encrypted hash is stored. When a person later attempts to authenticate, the password is hashed and that hash is compared to the stored hash. If these are the same, they are authenticated, otherwise access is rejected. In theory, if someone were to obtain a password list for a system, it would be useless, since by definition it is impossible to recover the original information from its hashed value. However, attackers can use dictionary and brute-force attacks by methodically comparing the output hash of a known input string to the stolen hash. If they match, the password has been cracked. Thus, proper password length and selection are crucial.

There are several different types of hashing, including division-remainder, digit rearrangement, folding, and radix transformation. These classifications refer to the mathematical process used to obtain the hash value. Here are two popular hashing algorithms:

• Message Digest 4/Message Digest 5 (MD4/MD5): The message digest (MD) class of algorithms were developed by Ron Rivest for use with digital signatures. They both have a fixed 128-bit hash length, but the MD4 algorithm is flawed and the MD5 hash has been adopted as its replacement. However, the security of the MD5 hash function has been severely compromised, and a collision attack exists that can find collisions within seconds on a computer with a 2.6 GHz Pentium 4 processor. MD6 was introduced in 2008 and is designed to take advantage of the full potential of future hardware processors with tens and thousands of cores instead of the conventional uni-core systems.
• Secure Hash Algorithm (SHA): This hashing algorithm was created by the U.S. government (NIST and the National Security Agency [NSA]) and operates similarly to the MD algorithms. The most common is SHA-1, which is typically used in IPsec installations, and has a fixed hash length of 160 bits. SHA-2 has a fixed hash length of up to 512 bits and has a word size of 64 bits, as does SHA-3.

External Links:

Cryptographic hash function at Wikipedia

The post Hash Functions appeared first on pfSense Setup HQ.

Cryptography Basics

Cryptography is a word derived from the Greek word kryptos (“hidden”), and the use of cryptography pre-dates the computer age by thousands of years. In face, the history of cryptography was documented over 4000 years ago, where it was first allegedly used in Egypt. Keeping secrets has long been a concern of human beings, and the purpose of cryptography is to hide information or change it so that it is incomprehensible to people for whom it is not intended. Cryptographic techniques include:

• Encryption: Involves applying a procedure called an algorithm to plaintext to turn it into something that will appear to be gibberish to anyone who doesn’t have the key to decrypt it.
• Steganography: A means of hiding the existence of the data, not just its contents. This is usually done by concealing it within other, innocuous data.

The first goal of cryptography is confidentiality. Through the use of cryptography, users are able to ensure that only an intended recipient can “unlock” (decrypt) an encrypted message. Most modern algorithms are secure enough that those without access to the message “key” cannot read the message. Thus, it is extremely important to keep the secret key or private key completely secret. If a secret or private key is compromised, the message essentially loses all confidentiality.

Guaranteeing message integrity is another important aspect of cryptography. With cryptography, most asymmetric algorithms have built-in ways to validate that all the outputs are equivalent to the inputs. Usually, this validation is referred to as a message digest, and, on occasion, can be vulnerable to man-in-the-middle (MTM) attacks.

Digital signatures serve to enforce data integrity and non-repudiation. A digital signature ensures that the message received was the message sent, because a hash was performed on the original message using a hashing algorithm. The hash value created by this process is encrypted by the author’s private key and appended to the message. To verify that the message has not been modified, the recipient uses the author’s public key to decrypt the hash created by the author. The recipient also creates a hash of the message body. If the recipient’s hash matches the hash created by the author of the message, the recipient knows that the message is unaltered.

Some types of asymmetric algorithms are immune to MITM attacks, which are only successful the first time two people try to communicate. When a third party intercepts the communications between the two trying to communicate, the attacker uses his own credentials to impersonate each of the original communicators.

Beware of the key exchange mechanism used by any PKE system. If the key exchange protocol does not authenticate at least one and preferably both sides of the connection, it may be vulnerable to MITM-type attacks. Authentication systems generally use some form of digital certificates, and require a PKI infrastructure.

Also, note that MITM-based attacks can only occur during the initial correspondence between two parties. If their first key exchange goes unimpeded, then each party will authenticate the other’s key against prior communications to verify the sender’s identity.

Because there isn’t any authentication built into the Diffie-Hellman algorithm, implementations that use Diffie-Hellman-type key exchanges without some sort of authentication are vulnerable to MITM attacks. Since the protocol itself does not authenticate the client or the server, it’s possible for someone to eavesdrop on the communications. This deficiency was one of the main reasons that the SSH-2 protocol was completely redeveloped from SSH-1. The SSH-2 protocol authenticates both the client and the server, and warns of or prevents any possible MITM attacks, depending on configuration, so long as the client and server have communicated at least once. However, even SSH-2 is vulnerable to MITM attacks prior to the first key exchange between the client and the server.

External Links:

Cryptography at Wikipedia

The post Cryptography Basics appeared first on pfSense Setup HQ.

What Is a Firewall?

What is a firewall? A firewall is basically any component (software or hardware) that restricts the flow of network traffic. This is a sufficiently broad definition to allow for all of the various ways people have chosen to implement firewalls. Some firewalls are notoriously limited in capability and others are extremely easy to use. The question of “what is a firewall” has evolved over time as the capabilities of firewalls have increased.

Within the realm of firewalls there are many different ways to restrict network traffic. Most of these methods vary in the level of intelligence that is applied to the decision-making process. For example, to permit or deny traffic based on which network device is the sender or recipient, you would use a packet-filtering firewall. In reality, even the simplest packet-filtering firewalls can typically make decisions based on the source Internet Protocol (IP) address, the destination IP address, and the source and/or destination port number. While this type of firewall may sound overly simplistic, consider the case where you have a server running a web site for use on the Internet. In all likelihood, the only traffic that you need to allow to the server uses a destination port of TCP (Transmission Control Protcol) 80 or 443. As a result, you could configure your firewall to permit only that traffic. Because the server is available for the Internet, you can’t filter traffic based on the source address or source port, which will be different for each connection.

The primary drawback with a simple packet filter is that the packet filtering firewall has to rely on very primitive means to determine when traffic should be allowed (e.g. synchronous [SYN] or acknowledgement [ACK] bits being set). While this was adequate in the early data of the Internet when security was not as big of a concern, it won’t work anymore. It is trivial to set the bits on the packet using freely available software to make the traffic look like it is a reply to another connection.

What Is a Firewall: Stateful Firewalls (Second Generation)

Thus the stateful inspection firewall was born of necessity. Developed initially at AT&T Bell Laboratories in 1989-90, this type of firewall performs the work of their first-generation predecessors but operates up to layer 4 (transport layer) of the OSI model. It monitors all connections (inbound or outbound), and as the connection is permitted (based on the firewall’s rules), it enters the connection into a table. When the reply to this connection comes back, even if the reply uses a port that the firewall was not previously configured to permit, it can intelligently realize the traffic is a response to a permitted session and permit the traffic.

Unfortunately, even as the firewalls get better, so do the methods hackers use to circumvent them. Suppose you have configured your firewall perfectly and there are no holes: every permitted port is one you expressly want to allow. Using the previous example, no traffic is allowed to the web server except web traffic. This sounds like a solid policy, but the problem is even if the firewall is completely secure, the server might not be. Flaws in the web server software could allow the attacker to send the server an HTTP request that is 10,000 characters long, overflowing the buffers and allowing the attacker to execute the code of his choice. The packets used to transport the 10,000-character HTTP request are all legal TCP packets as far as the firewall is concerned: therefore, it would permit them to pass through to the web server. The next step in firewall evolution serves to combat this type of attack: application gateways, or layer 7 firewalls. The first transparent application level firewall was Gauntlet, an outgrowth of Toolkit, developed by Marcus Ranum, Wei Xu, and Peter Churchyard.

What Is a Firewall: Application Layer Firewalls (Third Generation)

This type of firewall not only filters network traffic based on the standard network parameters, but they also understand the higher layer protocol information contained within the packet. In this example, the firewall would be looking for HTTP requests. The firewall knows what a legitimate HTTP request looks like and can out a malformed or malicious request even though, from a network perspective, it might otherwise be a permitted packet. There is a down side to this type of approach: the firewall must be programmed with all the same intelligence needed to filter normal traffic, plus the firewall must fully understand the protocols it is inspecting. This means additional programming for any protocol you want the firewall to understand. Most of the major commercial application gateways offer support for the major protocols such as HTTP, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP).

Generally speaking, you can find many free varieties of firewalls that perform some type of stateful inspection. Application layer gateways are not really available for free. In reality, few organizations have the funds to use application gateways extensively. One ramification of not using an application gateway is that you need to ensure that the service that is exposed to untrusted traffic is configured as securely as possible and that the server itself is hardened against attack. Keeping the service patches up-to-date will help reduce the odds that an application-level attack will be successful.

External Links for “What Is a Firewall – Answered”:

Firewall (computing) at Wikipedia

What Is a Firewall at Indiana University Information Technology Services Knowledge Base

What Is a Firewall at searchsecurity.techtarget.com

What Is a Firewall? at Netgear Support

The post What Is a Firewall – Answered appeared first on pfSense Setup HQ.

The most securely configured firewall in existence will not provide much protection if a network was not designed properly. For example, if the firewall was installed into an environment that allows an alternate network path that bypasses the firewall, the firewall would only be providing a false sense of security. This is an firewall architecture error that would render the firewall useless. Thus, where the firewall is implemented is every bit as important as how it is implemented. The first step to installing anything is always planning. What follows in this article is a discussion of the most common firewall architectures, in increasing order of security.

Firewall Architecture: Screened Subnet

A screened subnet is the simplest and most common firewall architecture implementation. Most small businesses and homes use this type of firewall. This design places the firewall on the edge of your network, dividing everything (from the firewall’s point of view) into internal and external, with nothing in between.

The screened subnet firewall (or edge firewall) is a straightforward as you can get. Internet users who need access to an internal server must traverse the firewall to do so. Internal users needing access to those same servers would able to access them directly. Internet traffic not destined for any server the admin does not want to provide access to would be blocked at the firewall to prevent attacks on internal systems. All internal users must also traverse firewalls to access the Internet. This is the same type of firewall you would have at home with a small network behind, say, a Linksys or Netgear router. This configuration has several advantages. The primary advantage is simplicity. With only two interfaces, the Access Control Lists (ACLs) – the filters that define the criteria for permitting or denying traffic – are much simpler.

Although this configuration is cost effective and simple to implement, it is not without its drawbacks. In this arrangement, the hacker has several chances to penetrate your network. If they can find a security hole in the firewall, or if the firewall is improperly configured, the hacker might be able to gain access to the internal network. Even if the firewall is executed flawlessly, the hacker has a second opportunity to gain access. If the hacker can compromise any available web-based services and take control of the servers, they would have an internal system from which to launch additional attacks. Finally, if the servers are critical to the business function, by allowing the internal users to access them without going through the firewall, you may lose some audit capability that the firewall might otherwise offer. By far the biggest security weakness in the configuration is that if you are exposing any web-based services: the servers hosting those services will be attacked frequently, and a compromise of one of those servers may expose your entire network. Thus, we are led to consider other forms of firewall architecture: the one-legged DMZ and true DMZ.

Firewall Architecture: One-Legged DMZ

The one-legged demilitarized zone (DMZ) still has the advantage of cost, because you are building a DMZ using only a single firewall. Commonly, the firewall interfaces are called Internal or Inside, External or Outside, and DMZ.

With this type of firewall architecture you get to keep the low-cost benefit, but add some isolation to your Internet-based servers. Internal users must traverse the firewall to access the servers or the Internet. External users must traverse the firewall to access the Web-based services. The real strength of this type of configuration is that if the servers that are hosting the web-based services are compromised, the hacker still needs to contend with the firewall to continue attacking the internal network. As an added feature, because all users (internal and external) must traverse the firewall to access the web-based servers, you may gain a higher degree of auditing from the firewall logs. If you wanted to provide even further isolation, assuming you have the available interfaces on the firewall, you could implement a separate DMZ for each web-based server you needed.

The only real disadvantages to this configuration are complexity, and to a small degree, cost. As you add interfaces to the firewall, the configuration will become more complex. not only does this complexity add to the time and labor for configuration and maintenance, it also increases the chance that an error could be made in the configuration. As you add interfaces there will often be additional costs associated with them. In most cases this cost will be minor and far less than an additional firewall, but with some high-speed interfaces, they can become very costly. Lastly, with this configuration, if the firewall itself is defeated, the entire network is open to attack.

Firewall Architecture: True DMZ

The true DMZ is generally considered the most secure of firewall architectures. With this design, there is an external and internal firewall. Between the two is sandwiched any Internet accessible devices.

Internet traffic is only permitted to a server in the SMZ, and only on the port that server is listening on. For example, if you had a web server in the DMZ and an FTP server in the DMZ, traffic with a destination port of 80 would only be permitted to the web server. For users accessing the same servers, the same rules would apply. Internal users would have to have permission through both firewalls to access the Internet. Obviously, this type of design costs more, typically double, but that cost buys you increased security. In a true DMZ, if the web server is compromised the hacker is still trapped between two firewalls. For those who want to go the extra mile, the inside and outside firewalls can be of different types. In this way, a hacker that finds a security hole in one firewall is unlikely to be able to apply the same techniques to the other firewall.

Firewall Architecture: Conclusion

Now that we have covered the basics of firewall architecture, you should be in a better position to make a decision about proposing and implementing a firewall solution for your network. In the next article, we will cover firewall implementation.

External Links:

DMZ at Wikipedia

SolutionBase: Strengthen Network Defenses by Using a DMZ at techrepublic.com

Four Tips for Securing a Network DMZ at fedtechmagazine.com

Designing and Using DMZ Netwroks to Protect Internet Servers at linuxjoural.com

The post Firewall Architecture appeared first on pfSense Setup HQ.

When it comes to firewall implementation there are a host of factors to consider. For commercial offerings there is the up front cost in addition to ongoing maintenance costs, which in some cases can be considerable. Some commercial offerings run their own base system. The underlying Linux system has been so heavily modified it is now considered proprietary. In the case of a Linux firewall, you also have the option of installing the firewall software on a CD-ROM or pen drive. These steps are discussed in more detail in the following sections, along with specific configuration examples for setting up a free firewall on both Linux and Windows.

Firewall Implementation: Hardware-Based Firewalls vs. Software-Based Firewalls

Another consideration in firewall implementation is whether the firewall decision-making logic is run as software that sites on top of another functional system, or if the firewall is a dedicated piece of hardware. In the case of a Cisco PIX firewall, the smallest models are the size of a small cigar box and there is no OS other than the PIX software. This is a dedicated hardware device used to perform the firewall function, also called a firewall appliance. The other alternative is that the firewall is not a dedicated box, but a software component. Many popular firewalls take this approach as well, such as a checkpoint firewall that can be installed on top of a Windows system. Of these two approaches, if you want a free solution the choice is made for you: since there is no free hardware-based firewall, you will be using a software-based firewall.

Firewall Implementation: netfilter

When it comes to Linux-based firewall, there is only one choice, which is netfilter. This is partially because it was the best option available for the longest time. Since version 2.4, however, netfilter has been built into the Linux kernel. Even many commercial firewalls are running a modified Linux OS with netfilter inside their own custom case. netfilter is the underlying software that makes up the built-in firewall on Linux systems. It is the netfilter component that reads the contents of the network packet and permits or denies network traffic. Often people incorrectly refer to the firewall as iptables or ipchains. In fact, iptables is the software command that is used to configure the rules that netfilter uses to make decisions to permit or deny traffic and ipchains is the previous version of iptables. Even after you have settled on using Linux as your base OS for your firewall, there are some additional choices to make before you start any configuring.

Firewall Implementation: Choosing a Linux Distro

While all versions of Linux share some characteristics, there will be differences. Depending on the specific Linux distribution, the differences could be significant and each distribution will likely offer some different sets of software packages. Because there are so many free versions of Linux available, it doesn’t cost anything but the time to download and install several different versions and see which one you like. I tend to use Fedora, because it is the community version of Red Hat, one of the oldest and most well-established Linux distributions. However, Fedora has fallen out of favor with many Linux users over the years, and your mileage may vary. Ubuntu is also very popular, although power users may find it annoying. Most likely you will want to try out the Live CD version of a distribution (if one is available) before you make up your mind. When it comes to choosing the specific version of Linux you want to use, this decision must be made in parallel with choosing an installation media, because not all versions are supported on all media.

In the next article, we will continue our look at firewall implementation, including the choice of distribution media.

External Links:

netfilter at Wikipedia

Distrowatch – a good site for information and links to various Linux distributions

The post Firewall Implementation: Part One appeared first on pfSense Setup HQ.

One of the more interesting features that Linux has over Windows is that it can be run from a variety of media. While Windows is notoriously difficult to configure to run from a CD-ROM (but still possible: see www.ubcd4win.com for the Ultimate Boot CD for Windows), there are Linux distributions that are capable of running off a traditional hard disk install, CD-ROM, a Universal Serial Bus (USB) drive, or even a floppy disk. Each media type offers some security pros and cons, and not every distribution will be available on every media type. If you need the features of a specific distribution that doesn’t come on the media you prefer, you may need to make a compromise. You will need to research the different media options and choose one that fits in your environment. We will review some of the pros and cons of each for Linux firewall installations.

Linux Firewall: Hard Disk Installation

The full install is the traditional install to a system’s hard disk. Much like Windows, you boot up an install CD and walk through a guided install process. Most of the Linux distributions installed on the hard disk offer graphical user interface (GUI) install programs that walk you through the installation steps. There is no great advantage to using this type of distribution other than that the size of the hard disk allows you to install a lot of extra software. For a firewall, you generally want to keep the software running to a minimum to enhance security, so this shouldn’t be a very big consideration. This type of installation also has the advantage that it will be easy to modify and alter the configuration if needed.

On the down side, this type of installation has all of the same disadvantages of a Windows bastion host: the entire system is sitting on the hard drive, and if a hacker manages to compromise the root account, they will be able to install a virus or Trojan on the system that can survive future reboots. This type of install isn’t any better or worse than if you were using Windows for your bastion host OS. Despite these concerns, it is the most common type of Linux firewall installation, and most versions of Linux install the firewall components by default. This means if you download a version of Linux you like and install it to a hard disk, you will have a firewall waiting to be configured when you’re done.

Linux Firewall: CD-ROM Installation

While you can get Windows running off of a bootable CD-ROM or live CD, it takes a lot more work than it does with Linux. There are many versions of Linux designed specifically to run from a CD-ROM, allowing you to turn virtually any machine into a Linux firewall, router, or general-purpose PC. There is an obvious security advantage to having all of your configuration information on read-only media media. Even if a hacker manages to compromise the system, all it takes is a reboot and it can be restored to its previous condition. The system can still fall victim to a hardware failure such as a failed central processing unit (CPU), all you would need to do to restore your firewall would be to move the CD to a new system and reboot.

The primary advantage to a CD-ROM-based Linux firewall installation is also the primary disadvantage. If you burn the entire OS and configuration settings to a CD, any time you need to make adjustments you would need to burn a new CD-ROM. The cost of the CD media should not be an issue, but such a configuration may hinder your ability to remotely administer the system, which would be limited to making changes to the running configuration. Changes that remained after a reboot would require someone local to insert the CD-ROM containing the new configuration. If you needed to implement and test changes that required a reboot to take effect, this type of setup would make things more difficult. Finally, due to simple space limitations on a CD-ROM, you may not be able to fit all of the needed software or functionality on a CD-ROM. That being said, if the firewall rules are relatively static and don’t require frequent adjustment, a live CD could be a very attractive option.

Linux Firewall: USB Drive Installation

If the space limitations are acceptable, a Linux firewall booting from a USB disk may offer the best compromise in security and flexibility. Having the operating systems and firewall software on a pen drive offers the same type of flexibility that a CD-ROM-based system provides, with increased storage capacity over that of a CD-ROM. If you purchase a USB disk that includes a physical write protect switch, you can make changes on the fly, like a live system, and then write protect the disk against modification when you are done. As the storage capacity of USB drives increases, you will be able to use a USB-based distribution that includes increasingly greater functionality. One key consideration with this type of media is that not all systems will support booting from a USB disk. While almost all newer systems support this option, some of the older systems that you may wish to install a free firewall on do not.

Linux Firewall: Floppy Disk Installation

Although the functionality is typically very limited, there are many versions of Linux that can fit on a 3.5-inch disk, and that can be used for Linux firewalls. The primary advantage of these distributions is their low resource requirements. Often, the systems only require 8 or 16 megabytes of memory and a 486 to function. The ability to toggle the write-protect switch on the floppy can also provide a high degree of configuration flexibility and security. Considering the unreliable nature of floppy disks, it probably wouldn’t be appropriate for use if an outage cannot be tolerated. At the very least you should have duplicate floppy disks available in the event of a failure. Another disadvantage to these is functionality. Generally, these floppy-based distributions are single purpose devices and lack much in the way of functionality. Another consideration is that due to the space restrictions on a floppy disk, these floppy-based distributions are almost always command line only, with no GUI for configuration or management.

Now that we’ve covered installation media for Linux firewalls, we can cover the operation of a Linux firewall, which we will in the next article.

External Links:

Ultimate Boot CD for Windows site

Devil-Linux – a distribution which boots and runs completely from a CD-ROM or USB flash drive

Damn Small Linux – the original Linux on a CD-ROM/USB drive distro

The post Linux Firewall Installation Media appeared first on pfSense Setup HQ.

Before covering some of the specific commands used to configure the Linux firewall, I will cover some basic Linux firewall vocabulary and some of the basics of netfilter operation. netfilter contains the firewall logic, and iptables is the program that is used to modify the rules that the firewall uses. These rules (or ACLs) define the rules used to permit or deny packets and how to react to denied packets. The current iptables use both tables and chains. Tables are the blocks of processing where various actions are performed on the packets. Different tables process different chains. Chains are a set of rules (or ACLs). There are four built-in tables that help define netfilter operation: nat, mangle, filter and raw, each of which processes different chains.

netfilter Operation: Tables and Chains

The following tables and chains are not listed in any particular order, as a given packet may be impacted by multiple tables and chains as it is processed. The primary built-in chains are INPUT, OUTPUT, and FORWARD. In addition to these, you can create your own user-defined chains to customize netfilter operation.

• Nat Table: In netfilter operation, this table is referenced with a packet that is used to create a new connection.
  • PREROUTING: This chain is processed as soon as a packet is received and before any routing decisions are made.
  • POSTROUTING: This chain is processed before a packet is sent to an interface but after any routing decisions have been made.
  • OUTPUT: This chain is processed for packets generated locally.
• Filter Table: This is the default table that is used when the iptables command is used to modify the rules and do not specify an alternate table. This is where the bulk of a firewall’s processing is consumed.
  • INPUT: This chain is processed for packets destined for the local system.
  • FORWARD: This chain is processed for processed for packets passing through the local system.
  • OUTPUT: This chain is processed for packets generated by local system.
• Mangle Table: This table is used for any specialized packet alterations that are needed. Examples are performing Network Address Translation (NAT) or manipulating various bits within the packet.
  • PREROUTING: This chain is processed on incoming packets before a routing decision is made.
  • POSTROUTING: This chain is processed last before a packet is sent to an interface.
  • OUTPUT: This chain is processed before a routing decision is made for packets generated locally.
  • INPUT: This chain is processed for packets destined for the local system.
  • FORWARD: This chain is processed for packets passing through the local system.
• Raw Table: This table is primarily used for packets that are exempt from connection tracking, and if required, are called before any other netfilter table.
  • PREROUTING: This chain is processed as soon as a packet is received.
  • OUTPUT: This chain is processed for packets generated locally.

Now that we have reviewed all the various tables and chains, we can continue our look at netfilter operation by discussing the overall packet flow, which we will do in the next article.

External Links:

Netfilter Overview at www.shorewall.net

How the netfilter System Works at www.mad-hacking.net

The post netfilter Operation: Part One appeared first on pfSense Setup HQ.

Now that we have covered the various tables and chains, we can discuss the overall packet flow. The key to remember is that not all packets traverse all chains. To further complicate matters, packets will traverse different chains depending on whether they are sourced from the netfilter host, destined for the netfilter host, or just passing through the netfilter host. Knowing this will save you time when troubleshooting your firewall rules in the future.

Targets are the actions that should be taken when a packet matches a given rule. A target is specified using the -j syntax (for jump). The primary targets used for a firewall are ACCEPT and DENY.

• ACCEPT: The packet is accepted and processed by the rest of the TCP/IP stack.
• DENY: The packet is dropped and no notice is given to the sender. While this does not honor the TCP/IP protocol specifications, it is considered the most secure option, because it denies a hacker useful information about the firewall. This behavior also has a negative side effect, which is if a system is trying to initiate a connection to a port that is blocked by a firewall, the connection attempt must time out before the initiating host gives up. If you use REJECT, the Internet Control Message Protocol (ICMP) port will allow the initiating system to abort the connection attempt immediately.
• LOG: This allows you to perform kernel logging, which appears in the syslog log. Further options allow you to specify the log level and a descriptive prefix for the log entry.
• RETURN: Processing continues in the previous chain at the rule just after the last rule processed in that chain.
• QUEUE: This is a special target that will hold (or queue) a packet for processing by a userspace process.

Unlike some firewalls, netfilter allows you to apply multiple rulesets (chains) to the same interface. Although it may seem minor, this option creates a lot of powerful possibilities. For example, suppose you have an ACL and you want to permit all packets originating on the 192.168.1.0 network except those from 192.168.1.25, which is a host that a third party uses and is not a completely trusted system. You want packets sourced from 192.168.1.25 with a destination port of 22, 25, 53, 80 and 443 to be permitted, while all other packets are to be blocked.

Using netfilter and iptables, you can create a rule to implement this policy:

1 somerule
2 iptables -A FORWARD -p tcp -s 192.168.1.25 -j CUSTOM
2.1 iptables -A CUSTOM -p tcp -s 192.168.1.25 –dport 22 -j ACCEPT
2.2 iptables -A CUSTOM -p tcp -s 192.168.1.25 –dport 25 -j ACCEPT
2.3 iptables -A CUSTOM -p tcp -s 192.168.1.25 –dport 53 -j ACCEPT
2.4 iptables -A CUSTOM -p tcp -s 192.168.1.25 –dport 80 -j ACCEPT
2.5 iptables -A CUSTOM -p tcp -s 192.168.1.25 –dport 443 -j ACCEPT
2.6 iptables -A CUSTOM -p ip -s 192.168.1.25 -j DROP
2.7 iptables -A CUSTOM -j RETURN
3 iptables -A FORWARD -p ip -s 192.168.1.0/24 -j ACCEPT
4 somerule

Using netfilter and iptables, we created rule #2, which says that the source address is 192.168.1.25 for processing the CUSTOM chain. You can create the CUSTOM chain with the iptables -N CUSTOM command. Within the CUSTOM chain, you check for the five permitted destination ports (rules 2.1-2.5) and then reject everything else (rule 2.6). Rule #2.7 has no matching criteria and will therefore match on nay packet and instruct the packet to return to the FORWARD chain where processing can continue. FORWARD chain rule #3 permits all other packets from the 192.168.1.10/24 network. This means that packets not sourced from 192.168.1.25 only have to be checked against rule #2 and can then move through the chain(s) instead of being checked against all the rules.

External Links:

Using Custom Chains in iptables at my.safaribooksonline.com

The post netfilter Operation: Part Two appeared first on pfSense Setup HQ.

The firewall GUI in Fedora.

The next step is to demonstrate how to configure the netfilter firewall. This is a critical step and the firewall should only be installed and configured after the underlying OS has been installed, updated, and hardened. We assume here that you are working with an otherwise secure system and now need to configure the firewall’s functionality.

To make sure the firewall is enabled, you can run chkconfig –list, which lists all of the services and the run levels they are configured to start in. For example, you may get the following output:

chkconfig –list | grep iptables

iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off

This output tells you that iptables will start in run levels 2-5. You can set it to run in run levels 2-5 by using the chkconfig -level 2345 iptables on command. If you are using a GUI window manager, you probably have another graphical application to see this information. For example, in Fedora, you can navigate to System -> Administration -> Security Level and Firewall.

You can enable or disable the firewall by going to the Firewall Options tab and selecting Enabled or Disabled. The interface in Fedora allows you to perform limited configurations of the firewall rules (e.g., by checking the Trusted Service SSH, a rule would be added to allow inbound connections on TCP port 22). Because any graphical interface provided will likely vary from one distribution to another, we use the command line to configure the firewall.

netfilter Operation: Deleting Rules and Chains

With many Linux distributions, the netfilter firewall will become enabled, but with an empty ruleset. In others, it might come with the firewall enabled and a very liberal ruleset in place. We can start configuring a Linux firewall by deleting any default rules that are present. You can use iptables -L (or –list) to list the current rules. An empty default ruleset should look like this:

iptables -L
Chain INPUT (policy ACCEPT)
Target prot opt source destination

Chain FORWARD (policy ACCEPT)
Target prot opt source destination

Chain OUTPUT (policy ACCEPT)
Target prot opt source destination

If there are any default rules present, they can be deleted using the iptables -F command. The -F option means to flush, which is equivalent to using -flush. This will clear all rules out of any existing chains. If distribution has any additional chains created beyond the default, you can delete a custom chain by using the iptables -N customchain command. In addition to the individual rules within a chain, the built-in chains have a default policy associated with them. This policy tells netfilter what to do if a packet reaches the end of the chain without finding a match. While the default policy is to ACCEPT, it is better to change this to DROP by using the -P option, which sets the default policy for that chain, as follows:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

We will continue our look at netfilter configuration in the next article.

External Links:

Basic Fedora Linux Firewall Configuration at www.techtopia.com

The post netfilter Operation: Part Three appeared first on pfSense Setup HQ.

pfSense 2.1.1 pre-release snapshots are available via pfsense.org’s snapshot server, at snapshots.pfsense.org.

A list of changes between 2.1 and 2.1.1 can be found here: https://doc.pfsense.org/index.php/2.1.1_New_Features_and_Changes.

The post pfSense 2.1.1 Pre-Release Snapshots Available appeared first on pfSense Setup HQ.

Permitting Firewall Traffic

In the previous article, we set up netfilter with a default policy of DENY. Now that we have done that, we want to make sure that management traffic is permitted to the firewall itself. This is done first, because once you have enabled the firewall with a default policy of DENY, you will not be able to manage the firewall remotely until you have configured the firewall rules to permit the management traffic. This traffic is processed against the INPUT chain, because the destination is the netfilter host itself. To allow secure shell (SSH) connections to the firewall, use the following command:

iptables -A INPUT -p tcp -s 192.168.1.0/24 –dport 22 -j ACCEPT

In this example, you are appending (-A) a rule to the INPUT chain to allow traffic from the 192.168.1.0/24 network to a destination port of TCP 22. With no other configurations, all other traffic through or to the firewall would be dropped. This will show up in the rule listing as follows:

iptables -L INPUT
Chain INPUT (policy DROP)

Target prot opt source destination
ACCEPT tcp — 192.168.1.0/24 anywhere tcp dpt:ssh

Although the aforementioned rules will permit the inbound SSH session, there is currently no rule to permit the reply traffic for the SSH session. If you were to change the default policy for the OUTPUT chain to ACCEPT, this would permit the reply packet, but we will instead address this more securely in the next few examples.

If you wanted to allow 192.168.1.99 access to the firewall with a destination of TCP port 80, you could use the same syntax with -A to append the rule, which would put the new rule for port 80 after the rule for port 22. You could also use -I for insert, as in the iptables -I INPUT 1 -p tcp -s 192.168.1.99 -dport 80 -j ACCEPT command. This would insert the new rule in the INPUT chain as rule #1, meaning the rule for port 80 would come before the rule for port 22. Remember, this is still permitting only half the conversation; you still need to permit the outbound reply packets. It is sometimes useful to list the chains with rule numbers using the iptables -L (or –line-numbers) command.

For outbound traffic (i.e. traffic generated by the firewall), you need to create rules in the OUTPUT chain. To enable syslog traffic from the firewall to a remote syslog server (192.168.1.99), you would enter the following:

iptables -A OUTPUT -p udb -d 192.168.1.99 –dport 514

This assumes you are using the default UDP syslog port of 514. Because syslog over UDP is a one-way conversation, you will not need to permit any inbound replies for permitted traffic that you allowed inbound in the preceding examples. You could create rules to permit SSH and HTTP specifically, but there is also a way to permit all traffic that is a reply to a permitted session. You can enter:

iptables -A OUTPUT -m state –state RELATED, ESTABLISHED -j ACCEPT

This will instruct netfilter to permit any outbound traffic that is part of an established session (ESTABLISHED). The RELATED keyword is similar, but is for traffic that is part of a different session, but where the session is related to an established session. Some protocols will open additional ports (such as FTP) as part of their normal behavior. For those that netfilter understands, it can see the request for the additional port and permit that new session.

External Links:

Simple Firewall Configuration Using NetFilter/iptables at www.novell.com

The post netfilter Operation: Part Four appeared first on pfSense Setup HQ.

Simulating the Windows Firewall

Now it’s time to configure the firewall. The built-in firewall on Windows XP/Vista/7/8 is enabled by default (on XP Service Pack 2 or better). The standard configuration is to allow outbound connections from the host system and deny inbound connections unless they are explicitly configured. The Windows firewall also allows any traffic that is a reply to traffic that the host originally generated. After you execute the iptables -F command to flush out all the previously configured rules, the following commands would configure the Linux host similarly:

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

The –state extensions track the current status of the connections. By specifying ESTABLISHED or RELATED, the firewall allows packets that are starting a new session, but where the session is related to an existing session (such as an FTP data session). If you were hosting a service on this system, such as a Web server, you would need to configure the INPUT chain appropriately. This configuration would afford any Linux system a minimum level of firewall security with virtually no impact to its overall functionality.

Simulating a Consumer-Grade Home Router

With the basics of iptables configuration out of the way, let’s consider a more practical example. For a typical firewall, there is very little traffic destined to or from the firewall itself. In general, the only traffic that would fit this profile would be administrative sessions to configure the firewall itself. The vast majority of a firewall’s traffic is passing through the firewall, and will thus be checked against the FORWARD chain. The following examples would configure the Linux firewall with the same access controls as a typical home network router such as a Linksys or Netgear router/firewall. This example assumes that 192.168.1.0/24 is the internal network on interface eth0 and the external interface is eth1.

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -s 192.168.1.0/24 -i eth0 –dport 80 -j ACCEPT

iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -0 eth1 -j ACCEPT

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

One important element is to always remember that if you have configured the default policy for a chain to DROP (for example, iptables -P FORWARD DROP) that you will need to include an explicit rule to permit the return traffic. This can be done by using the following command:

iptables -A -m state –state ESTABLISHED,RELATED -j ACCEPT

So if you wanted to permit the return traffic for a FORWARD chain, you would enter:

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

Many hours of troubleshooting Linux firewalls have been spent by overlooking a rule that permits the return traffic.

We will continue our look at netfilter firewall configuration in the next article.

External Links:

Simulating windows firewall with iptables at ittopix.wordpress.com

The post netfilter Operation: Part Five appeared first on pfSense Setup HQ.

In the previous article, we began the process of simulating a home router with netfilter. We will continue that process in this article.

We began with the these iptables commands:

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -s 192.168.1.0/24 -i eth0 –dport 80 -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -o eth1 -j ACCEPT
 iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

The INPUT chain allows port 80 to go to the firewall itself from the internal network. Many of the home routers have a Web interface for configuring them, and while your configuration may not need this port open to the firewall, it is included here to help emphasize how the different chains are used. It is important to specify the input interface (using -i) so that the source IP cannot be spoofed by an external attacker. In this way, you ensure that even if a packet was generated with the proper source IP, if it came in on the outside interface (eth1) it would not match the rule and would thus not be permitted. The FORWARD rule allows any outbound traffic from the internal network to the external network. This configuration is simple to implement; however, the 192.168.1.0 IP range is a private IP range and is not routable on the Internet. Thus, this range would not allow traffic from the internal network to the Internet quite yet. To make this Linux firewall a useful replacement for a home network router, you need to enable NAT, which allows all of the systems on your internal network to appear as a single IP address when communicating on the Internet.

Enabling NAT

In principle NAT is simple, but in a complex environment it can get confusing. Basically, NAT means that the NAT device (in this case the Linux netfilter firewall) will change the IP address in apacket and retransmit that packet. Depending on your needs, you can alter the source IP address (source NAT, or SNAT), the destination IP address (destination NAT, DNAT), or both (double NAT). With a home router, the objective behind the NAT capability is to allow all of the internal hosts to communicate on the Internet using the single public IP provided by your Internet Service Provider (ISP). (In this case, SNAT is being used). As each of the hosts on your private network make a connection to an Internet server, the firewall is altering the source address to look like the public IP from your ISP. By doing this, the return traffic can find its way back to the firewall and be retranslated and sent to the originating host.

In this example, assume that the internal host has a private IP address of 192.168.1.11. The public address of the firewall is 5.5.5.5, which is provided by the ISP. If a host on the private network wants to make a connection to pfsensesetup.com. The firewall alters the source address to its own public IP address of 5.5.5.5 and sends the packet on its way. When the server replies to destination 5.5.5.5, the firewall again edits the packet, this time inserting a new destination of 192.168.1.11. All of this takes place and is transparent to the 192.168.1.11 host and the pfsensesetup.com server. When multiple hosts are using SNAT, the firewall tracks which connections belong to which private hosts using the port numbers. While the destination port of the Web server remains static (typically port 80 for the Web), the source port is usually a random port above 1024. By tracking the source port, the firewall knows which address belongs to which session. In the event that two hosts attempt to use the same source port, the NAT device edits the source port of one of the connections and replaces it with another random source port. When the return traffic is received, it translates the source port back, just like it did for the IP address. because this method of NAT relies heavily on using the source port number, it is sometimes referred to as port NAT (PNAT).

To add the SNAT functionality to the example firewall, use the following command:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT –to-source 5.5.5.5

The -r option is used to specify the table we want to modify, and -A option specifies that we are going to append this rule to the POSTROUTING chain. By specifying the outbound interface, we are ensuring that the SNAT only occurs as traffic leaves the private network, meaning only in the proper direction.

The jump target SNAT is self explanatory. The –to-source option specifies what IP address we want to use as the new source address. SNAT assumes we have a static IP address to SNAT the outgoing packets to. While this is likely the case in a corporate environment, a more appropriate solution to more closely mimic the configuration of a home router would be to use the MASQUERADE command:

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

The masquerade command does not require an IP specification, and will use the IP address of the firewall interface. You might be wondering why you would not use the masquerade target all of the time instead of the SNAT target. Because the source IP is static, the SNAT target will cause the NAT calculations to be performed once for a given session. Subsequent packets belonging to that session are handled the same way as the first. With the masquerade target, each packet is checked for the source IP to use, which requires more overhead than with SNAT. This is why SNAT is preferable if you have a static source IP address, and masquerade is your only option if you do not have a static source IP address to use.

External Links:

Linux 2.4 NAT HOWTO at www.netfilter.org

The post netfilter Operation: Part Six appeared first on pfSense Setup HQ.

By this point, you should have a relatively solid grasp of how to configure a Linux firewall. So far we have covered all of the core commands to permit and deny the traffic. Another useful command for your Linux firewall deals with logging packets. If you want to log everything passing through the firewall, use the iptables -A FORWARD -j LOG command. While simple, this would likely generate an excessive amount of logging traffic. You also might want some additional control of how the logging occurs. There are some additional options to provide this functionality. Of particular note are the –log-level and –log-prefix options.

The –log-level option allows you to specify what logging level is used for the LOG rule, The effect this log level has depends on how you have your kernel logging configured (via syslog or syslog-ng). When you combine the custom logging level of iptables with the syslog configuration, you can have syslog act in any manner of ways based on the firewall logs, including sending e-mails for certain events. The –log-prefix option allows you to insert up to a 29-letter string in front of the log entry. This can be useful for troubleshooting purposes. Some examples of information you could place in log prefix would be the name of the chain that generated the log entry such as iptables -A FORWARD -j LOG –log “from FORWARD chain.”

Saving and Restoring a Ruleset

Now that you can create a working ruleset for netfilter, you will want to save it. There are two commands of note: one for saving the configurations and one for loading a save configuration. You can use the iptables-save command to generate output that is the current active ruleset. By default, it will only generate the output to the stdout, meaning it will display in the console. To save this output, redirect it to a file. To redirect the current ruleset to a file called /etc/ruleset, you would type iptables-save > /etc/ruleset. If you want to save the current packet counts and rule counts, use the iptables-save -c > /etc/ruleset command. Individual tables can be saved separately by specifying the -t option using the iptables-save -t mangle > /etc/ruleset command.

Restoring a ruleset is accomplished using the iptables-restore command. Like iptables-save, the restore function takes only two optional arguments. The -c option will cause iptables to load the saved packet and byte counts, overwriting the current count values. The default behavior when using iptables-restore is to flush the ruleset before loading the saved ruleset, thus all previous rules are lost. If you wish to override this behavior, you can use the -n option, in which case the fules will be added to the existing ruleset, and will only overwrite if there is a duplicate rule. You can use the iptables-restore < /etc/ruleset command to pipe the saved configuration to iptables-restore.

External Links:

How to Log Linux iptables Firewall Dropped Packets to a Log File at The Geek Stuff

The post netfilter Operation: Part Seven appeared first on pfSense Setup HQ.