A Stateful Packet Inspection (SPI) firewall, Login/Intrusion Detection and Security application for Linux servers.

This suite of scripts provides:

• Straight-forward SPI iptables firewall script
• Daemon process that checks for login authentication failures for:
• Courier imap, Dovecot, uw-imap, Kerio
• openSSH
• cPanel, WHM, Webmail (cPanel servers only)
• Pure-ftpd, vsftpd, Proftpd
• Password protected web pages (htpasswd)
• Mod_security failures (v1 and v2)
• Suhosin failures
• Exim SMTP AUTH
• Custom login failures with separate log file and regular expression matching

Firewall Change Control

A change management procedure is required to ensure that firewall configuration changes do not impact the business or generate any security vulnerabilities.

A firewall system must follow approved change management principles. This relates to hardware, software and configuration changes made on the firewall system(s).

A change management procedure is required to ensure that firewall configuration changes do not impact the business or generate any security vulnerabilities. An unauthorized security change may result in a firewall rule that inadvertently allows unauthorized access to the corporate internal network or that blocks key corporate services.

Latest security patches may be rushed to the market by consumer demand during the release of a security bulletin or publicized computer virus. It is critical that any new patches be tested prior to being deployed within the production environment. Sometimes a security vendor will release a patch without performing sufficient (security and stability) testing.

The minimum requirement with regards to “Firewall Change Control” is:

• All firewalls must follow approved change management principles and system management best practices. All firewall security changes must be documented within a change management system.
• Changes to the firewall security policy must be authorized and made by suitably trained and trusted security personal.
• All high-risk configuration changes (eg. software upgrades) must be tested before being implemented in the production environment.
• All firewall changes must have a roll-back procedure to reverse any changes made to the firewall system.
• The recommended requirement with regards to “Firewall Change Control” would need the following addition:
• All configuration changes (eg. software upgrades) must be tested and validated before being implemented in the production environment.

Firewall Change Control procedures must be followed at all times and approved by Information Owners. This will ensure that information processing facilities are operated and maintained correctly and securely.

External firewall has been discussed in the previous article, and another article about firewall physical security should be followed too in addition to this article. Firewall physical security assures the placement of any firewall system (or internal network) within a public accessible area is prohibited.

Firewalls Security Guidelines

Firewall network security provides guidelines for secured firewall in a computer networking infrastructure. Secured Internet Security Firewall in each entry point of the private network must be well-managed to provide protection against threats from external public (un-trusted) networks, such as the Internet. Networks must be segmented if distinct security boundaries are to be enforced.

A firewall is a system that controls the flow of traffic between networks and provides a mechanism for protecting hosts against network based security threats. It should be noted that Firewall network security cannot control (and protect against) traffic that does not flow through the security gateway (eg. a dialup modem will bypass any firewall), nor can it protect against internal or authorized attacks.

Firewalls are only as secure as the Firewall network security system and the implemented security policy (firewall rule base). Due to the number and variety of developing threats and security vulnerabilities being easily distributed on the Internet, Internet Security Firewall can never provide 100% protection against all possible threats, so that’s why Firewall network security is very essential in protecting the corporate networks.

Firewall topology

Firewall network security should cover the use of a suitable firewall, firewall topology and Firewall network security policy. This will be critical in ensuring protection against network security threats. A secured Internet Security Firewall must be used to provide protection against threats from external public (un-trusted) networks, such as the Internet. Networks must be segmented if distinct security boundaries are to be enforced. Read more detail about firewall topology here.

Firewall functional requirements

The corporate firewalls must adhere to certain minimum Firewall network security standards. This is a requirement to ensure that internal corporate assets are protected with a suitably supported and configured firewall. The minimum Firewall network security standard must define the functional requirements of a firewall that is to be used on the corporate network. Read more detail about firewall functional requirementshere.

Default firewall configurations

External facing firewalls must be configured by default to deny all traffic not specifically permitted by the Firewall network security policy. This is to ensure that maximum network security is enforced against all un-trusted and unauthorized networks. In order to protect against Internet based attacks all external facing firewalls must be configured to deny all traffic which is not explicitly permitted. Read more detail about default firewall configuration here.

Internal firewall connections

The Firewall network security standard in the use of internal firewall systems within the corporate is not encouraged. Internal Firewall network security systems should be avoided due to the potential risk in affecting the corporate core network services and applications such as email system; Domain Name System and domain controllers.

If an internal firewall is to be used then it must be configured accordingly as to not impede network services (e.g. the corporate Active Directory and Exchange Messaging) which are deemed critical to the operations of the corporate global network. If an internal firewall is being deployed then its Firewall network security policy configuration must be verified to ensure that the corporate cores services are not restricted. Read moredetail about internal firewall connections.

External facing firewall connections

Firewall network security standards about External facing firewalls must be configured to protect internal assets from Internet (eg. any public or un-trusted network) based security risks. This includes providing firewall connections on all external connections to the global corporate network. Read more detail about external facing firewall in Firewall network security standards.

Firewall auditing

One of the tasks in the Firewall network security standards that are essential to do is regular auditing. Regular security auditing of the corporate firewall systems must be undertaken to ensure that the firewall is performing its intended function and security has not been compromised. The auditing of the firewall system must be carried out by security personnel and include analysis of the firewall platform and its configured rule base, logging and alerting security measures. Read more detail about regular firewall auditing here.

Firewall logging

Firewall logging is essential in the Firewall network security standards. The collection and maintenance of firewall logs is critical in determining the security of a firewall system and the assets it protects. All suspicious activity as well as firewall configuration management must be logged in sufficient detail to assist with the identification of unauthorized access attempts. Logs must be routinely backed up and stored in a secure location. Read more detail about firewall logging here.

Contingency planning

Firewall network security standards require the management of disaster recovery and business continuity plan. Contingency planning must be prepared which address the response and action procedures that are to be taken in the event of various network firewall security related issues. These events include system\host compromise, security attacks, system malfunction and firewall (gateway) outages. Read more detail about firewall contingency planning here.

Firewall access privileges

Privileges to modify the firewall configuration (rule base) must be restricted to authorized security personnel. All firewalls should have at least two people who are adequately trained and are proficient in managing the internet security firewall system(s) and have a strong understanding of network and information security. Read more detail about firewall access privileges in Firewall network security standards here.

Firewall network management system

Internet security firewall systems must be configured so that they are visible to internal network management systems. This is a requirement so that security and network management alerts and reports can be accessed and acted on in a timely manner. Read more detail about firewall network management in Firewall network security standards here.

Dedicated firewall

Internet security firewall must be dedicated and hardened security systems. Due to the security nature of a firewall, it must not be used for alternative purposes (even in small or remote environments), such as a web, file and print or email services. Read more detail about dedicated firewall in Firewall network security standards here.

Firewall changed control

An Internet security firewall system must follow approved change management principles. This relates to hardware, software and configuration changes made on the firewall system(s). Read more detail about firewall changed control in the Firewall network security standards here.

The other solution for the business offices is a complete solution internet security appliance such as Safe@Office. Safe at Office 500 Series – a total internet security appliance for small to medium business organization, secure network access –anytime, anyplace. Besides the security appliances, the corporate organization can also adopt the security software for the corporate – BitDefender. The need of network management and security software in a large corporate organization is a need as part of the information security management.

Suggested reading: Sample risk assessment; firewall ports; business firewall

How To Test a DDoS Mitigation System

Knowledge of DDoS attacks is mostly through hearsay. Most people purchasing DDoS mitigation systems do not know how to decide one system from the other. This knol discusses a minimum feature set that you must test and benchmark to see the functionality and performance of a given DDoS mitigation system.

Introduction

Distributed Denial of Service (DDoS) attacks are becoming common now with the proliferation of botnets. Network managers and security managers are deploying DDoS mitigation systems. Since most DDoS mitigation systems are fewer than 5 year old today, there is a trust issue with them.  Those that have been tested by third parties such as Tolly Group are fewer. Most people would rather test them in their own lab before deploying them.

There are well know criteria for testing firewalls and Intrusion Prevention Systems (IPS). For DDoS mitigation systems, there is a need for a comprehensive test conditions.

This knol therefore focuses on idenifying different kind of floods that can be tested using DDoS mitigation systems.

The reader is expected to create test-benches and test scripts to create these tests.

 

Typical Test Benches

Following diagram shows a simple test bed. The appliances SmartBits and Avalanche are packet generator. Smartbits is used for creating session-less attack packets and Avalanche is used for creating sessions or attack sessions. Client PCs (PC1, PC2) and Server PCs (PC3 etc.) are used to seeing the results of mitigation.SmartBits and Avalanche here can be replaced with PCs runnig Linux/Windows with attack scripts.

Following diagram shows a more complex test bed. The appliances SmartBits and Avalanche are packet generators. Such setups are typically used for third-party performance tests.

DDoS Attack Types - A Broad Classification

DDoS attacks can be broadly classified into following categories:

• Spoofed floods vs. Non-spoofed floods
  • A spoofed flood sends packets that seem to come from an IP that either does not exist or did not actually send the packet.
  • A non-spoofed flood on the other hand comes from real IP addresses. Due to proliferation of botnets, it is quite common these days to see non-spoofed attacks coming from a large number of sources.

Anomalous header floods

• These are packets which are typically generated by scripts. Scripts simple use loops to increment certain header parameters. Since many of these header parameter values may not be valid from standards perspective, they are anomalous. Examples of these attacks are packets with invalid TCP flag combinations. If a packet has flags such as RST, FIN, SYN, and ACK set simultaneously, it is anomalous.

Anomalous state floods

• Protocols such as TCP are stateful. They follow predefined state transition rules. When scripted bots generate attacks, they violate many of these rules. Examples of such attacks are ACK packets coming without connection establishment, out of TCP window packets etc.

Limited sources vs. Large number of sources Floods

• Some DDoS attacks are launched using very limited numer of sources while some others are launched with a very large number of sources. It is easy to launch a spoofed attack with a seemingly large number of sources. To launch a non-spoofed large number source attack, you need a control over  a large botnet.

Layer 2, 3, 4 or 7 DDoS attack

• It is possible to launch DDoS attacks on different network layers.
• Within a LAN, it easy to launch a layer 2 DDoS attack. Examples could be a brodcast flood, ARP flood, RARP flood etc.
• Over the Internet, one can launch Layer 3, 4 or 7 attacks.
• Example of Layer 3 attacks are protcol floods such as ICMP floods, TCP floods, fragment floods. These are created using a variation in the layer 3 headers.
• Example of layer 4 floods are port floods (TCP or UDP). In these attacks, a single port is continuously attacked. ICMP echo flood are also of this kind.
• Example of layer 7 floods are URL floods. In this attack, a single URL is continuously attacked from mutliple sources.

Random header parameter attack

• It is easy to create DDoS attacks in which some specific header parameter is continuously varying. Examples are TCP random flag flooding, IP option flooding, TCP option flooding etc.

Blended attack

• It is easy to create DDoS attacks in which many attacks are combined to further confuse the destination. Examples are port floods on TCP and UDP simultaneously, .

Attacks To Test Functionality and Performance 

• Spoofed Syn Flood Attack
  • This is a layer 4 spoofed flood in which the attacker sends TCP SYN packets in which the IP addresses are continuously changing.
• Spoofed UDP Attack
  • This is a spoofed flood in which the protocol is UDP and source address keeps changing.
• Spoofed ICMP Attack
  • This is a spoofed flood in which the protocol is ICMP and source address keeps changing.
• Spoofed TCP SYN-ACK Attack
  • This is a spoofed TCP flood in which SYN-ACK packets are sent in an anomalous state manner. Connections are not established prior to this through a SYN packet.
• Spoofed TCP FIN-Ack Attack
  • This is a spoofed TCP flood in which FIN-ACK packets are sent in an anomalous state manner. Connections are not established prior to this through a SYN packet.
• Spoofed IP Attack
  • This is a spoofed IP protocol flood. Packets may not necessarily be TCP, UDP or ICMP and can be any protocol.
• Spoofed IP Fragments Attack
  • This is a spoofed IP flood in which packets are fragmented - the fragment bit is set in the layer-3 IP header.
• IP-UDP Fragments Attack
  • This is a IP flood in which packets are fragmented - the fragment bit is set in the layer-3 IP header and packets belong to protocol 17 (UDP).
• IP-ICMP Fragments Attack
  • This is a IP flood in which packets are fragmented - the fragment bit is set in the layer-3 IP header and packets belong to protocol 1 (ICMP).
• TCP/UDP Destination Port Attack
  • This is a layer 4 flood in which packets attack either a TCP or UDP destination port.
• Spoofed TCP-SYN / UDP / ICMP Blended Attack
  • This is a blended attack in which source IP addresses are spoofed and at the same time, the protocol keeps changing as TCP, UDP and ICMP. The TCP packets are SYN packets.
• Non-Spoofed TCP SYN-ACK
  • This is a limited source layer 4 flood in which TCP SYN-ACK packets are sent continuously without a formal connection establishment.
• Non-Spoofed TCP SYN Attack
  • This is a limited source layer 4 flood in which TCP SYN packets are sent continuously without further sending more packets within the connection. The connections will stay on the server until they timeout from the SYN-state.
• Non-Spoofed TCP FIN-ACK Attack
  • This is a limited source layer 4 flood in which TCP FIN-ACK packets are continuously sent without establishing formal connections.
• Non-Spoofed TCP ACK Attack
  • This is a limited source layer 4 flood in which TCP ACK packets are continuously sent without establishing formal connections.
• HTTP Half-Connection Attack
  • Half-connections or embryonic connections are connections that have not completed. When such a SYN flood occurs on HTTP port (80), it is called HTTP half-connection attack. This is obviously a spoofed layer 4 attack.
• Non-Spoofed UDP Attack
  • This is a limited source layer 3 protocol flood in which the sources send IP protocol 17 - UDP packets. Remember that this would be a layer 4 flood if the UDP port is fixed in all the packets.
• Non-Spoofed DNS Attack
  • This is a limited source layer 4 flood in which the sources send UDP packets with destination port set to 53 which corresponds to DNS protocol.
• Non-Spoofed ICMP Attack
  • This is a limited source layer 3 protocol flood in which the sources send IP protocol 1 which corresponds to ICMP. Remember that this would be a layer 4 ICMP type and code flood, if a specific ICMP type and code is used in the attack packets.
• Non-spoofed TCP ACK Flood
  • This is a limited source layer 4 flood in which TCP ACK packets are continuously sent without establishing formal connections.
• Spoofed TCP ACK Flood
  • This is a spoofed layer 4 flood in which TCP ACK packets are continuously sent without establishing formal connections.
• Non-spoofed TCP NULL Flood
  • This is a limited source layer 4 flood in which TCP packets are continuously sent without establishing formal connections. These packets don't have any flags set in them and therefore have a header anomaly in layer 4 header.
• Spoofed TCP NULL Flood
  • This is a spoofed layer 4 flood in which TCP packets are continuously sent without establishing formal connections. These packets don't have any flags set in them and therefore have a header anomaly in layer 4 header.
• Non-spoofed TCP Random flag Flood
  • This is a limited source layer 4 flood in which TCP packets are continuously sent with randomly changing TCP flags. Due to the randomization, there may be a header anomaly in layer 4 header. Some flag combinations are illegal. Example of legal combinations are SYN-ACK, FIN-ACK. Examples of illegal flag combinations are SYN-FIN-RST-ACK, SYN-RST etc.
• Spoofed TCP Random flag Flood
  • This is a spoofed layer 4 flood in which TCP packets are continuously sent with randomly changing TCP flags. Due to the randomization, there may be a header anomaly in layer 4 header. Some flag combinations are illegal. Example of legal combinations are SYN-ACK, FIN-ACK. Examples of illegal flag combinations are SYN-FIN-RST-ACK, SYN-RST etc.
• TCP random sequence, ackknowledgement numbers
  • TCP is a connection-based stateful protocol to complete datagram oriented IP protocol which it uses as an underlying protocol. It uses sequence numbers and acknowledgement numbers to ensure proper windowing and end-to-end ordered delivery. Normally sequence numbers are randomly chosen in a given connection. Once chosen, they follow a discipline. In a random sequence or acknowledgement number attack, these numbers are randomly chosen and varied. It can confuse the receiving end-point stack.
• TCP Random window size
  • TCP is a connection-based stateful protocol to complete datagram oriented IP protocol which it uses as an underlying protocol. It uses windowing to break large application packets to ensure proper end-to-end ordered delivery. The window size determines the number of bytes of data that can be sent before an acknowledgement from the receiver is necessary. In a random window size attack, the window sizes are randomly chosen and varied. It can confuse the receiving end-point stack.
• TCP random option value
  • The TCP Options are located at the end of the TCP Header. These options have been used to enhance TCP protocol. TCP options include Maximum Segment Size (MSS), Window Scaling, Selective Acknowledgement (SACK), etc. In a random option value flood, the option values are changed randomly. Some of the combinations may be anomalous while some values may be anomalous too as they may be unassigned values.
• TCP random data length
  •  The length of TCP payload is dependent on the MTU (Maximum Transmission Unit) supported by the network, for normal ethernet the MTU  is 1500. This is the maximum amount of data available to IP, TCP, and the application, it excludes the bytes for the ethernet header and  trailer. From this 1500 you need to subtract bytes for the IP and TCP  headers (normally 20 bytes each) leaving 1460 bytes available to the  application. If the RFC1323 Timestamp option is used (fairly common  nowadays) it extends the TCP header by 12 bytes leaving 1448 bytes. In a random data length attack, the payload size is randomly chosen.
• TCP checksum error flood
  • TCP checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header.  This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments. In a TCP checksum error flood, TCP segments with bad checksums are sent to overload the checksum validation logic.
• IP Random Identification flood
  • The IP-Identification (IP-ID) field value in the IP header is used to uniquely identify the fragments of  a particular datagram. Fragments of a particular datagram are assembled if  they have the same source, destination, protocol, and Identifier. The IP identifier field can have 65,536 different values. It is  important  for an operating system to have some sort of a mechanism in order to control  the identification numbers correctly. In this flood, the IP-ID file is randomly varied.
• IP Random fragment flag, offset flood
  
  • IP-V4 header has a field called Flags related to fragmentation. This 3-bit flag has a reserved bit followed by Don't Fragment (DF) and More Fragment (MF) bits. A flood that continuously varies the above bits can confuse network devices. Just after the flags, there is a 13-bit fragment offset field. A flood that continously varies this field can also cause confusion.
• IP Random TTL flood
  • 
    

    IPV4 header has an eight-bit time-to-live (TTL) field that helps prevent datagrams from going in circles on the Internet. Each packet intermediate network appliance that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and is discarded. This flood sends packets with random TTL values.




• IP random protocol
  

  • IPV4 protocol supports up to 256 protocol types. In this flood, the protocol field value is randomly changed while (may be) keeping rest of the packet header values similar.




• UDP checksum error
  • UDP header has a checksum field. By sending a wrongly computed checksum value, packets with anomalous header can be flooded on the network.



• Non-spoofed ICMP echo reply flood
  • ICMP echo request is typically used to identify the presence of a machine on the network. The machine responds with a ICMP echo reply. This flood that continuously sends ICMP echo replies to an IP address. The sources are non-spoofed.



• Spoofed ICMP Echo Reply
  • Unlike above, this flood uses spoofed IP addresses to send ICMP echo replies. 



• Un-spoofed ICMP Type/Code Flooding
  • ICMP allows 65535 combinations of type/codes. This is an un-spoofed flood from limited number of sources that randomly send a type/code flood.



• Spoofed ICMP Random Type/Code Flooding
  • This is a spoofed flood where a single but random ICMP type/code is flooded. Rest of the packet header may be similar in the packets.



• Non-IP Flooding
  • Ethernet header allows different protocols. IP version 4 or version 6 are just two of them. There are other protocols too. In a non-IP flood, un-common values of the protocol values are used.

  Conclusion

  There are many ways to test DDoS mitigation equipment. Conditions given above are just some examples. DDoS mitigation is a police and thief game. The hackers come up with new techniques and therefore the testers and equipment makers have to come up new techniques to test and benchmark the equipment. 

http://knol.google.com/k/how-to-test-a-ddos-mitigation-system

Reject IP packets with an ICMP error, or just drop them?

Consider an internet-facing host (the outer firewall). What should be done with undesired traffic: just drop it, or send back an ICMP error such as port unreachable? (In Linux terms: iptables -P DROP or iptables -j REJECT?)

This isn't about the security of our network, the packets aren't getting in either way. It's about being a good citizen. REJECT could make our firewall participate in a DDoS, if the incoming packets have a spoofed origin. But is it always the right choice? Are there circumstances where it's better to send back a proper ICMP error?

network firewalls ddos
linkimprove this question
asked Apr 23 at 14:27
Gilles
597112
1
as I mentioned on Unix SE, I would suggest putting a limit on any reject, that way if someone is sitting there sending packets you aren't sending a ton the other direction. I can't suggest how many to allow. – xenoterracide Apr 23 at 18:01
@xenoterracide the way DDoS reflection attacks work (the attack being initiated from thousands of bots that could theoretically use any "reflector), it's still enough for an interconnected host to produce just a little bit of unintended traffic in order to contribute to a major attack. Still such limits on rejects should be considered "Good Internet Citizen" practices – Georgios Apr 24 at 1:42
feedback
1 Answeractiveoldestvotes
up vote
5
down vote
accepted
I usually vote for sending back an ICMP error for UDP and a RST packet for TCP. It does make debugging issues so much easier. And it prevents annoying timeouts: Mail and IRC servers often attempt to do an ident query or check that the client is not an open proxy.

If it is done at the out-most firewall there will be no relevant information disclosed. Depending on the setup it may even conceal that there is a firewall. If there were no answer, it would be obvious that there is a black hole.

It's important that servers send no answer for packets sent to a broadcast address in order to prevent an amplifying effect in a DoS situation. It's okay for the firewall to send the error message in this situation, resulting in only one answer.

ICMP-errors and TCP-RST packets are not larger than the smallest original packet. So these are not interesting for DDoS attacks.

Edit: DNS authoritative servers (and missconfigured DNS resolvers) are a lot more interesting for reflective DDoS attacks because the DNS answers are larger than the queries and therefore grant the attacker an amplification free of charge.

linkimprove this answer
edited Apr 23 at 20:14

answered Apr 23 at 14:41
Hendrik Brummermann
3,3272525
1
Regarding your last paragraph: what about the case when a DDoS wants to hide which systems are infected? The bot, B, sends a packet to server S that claims to be from source address V, the victim. Then S sends an error/reset packet to V. There are many B, and many S. – Graham Lee♦ Apr 23 at 18:59
2
While this is theoretically possible, this is an extremely inefficient way for two reasons: a) ICMP unreachable and unsolicited TCP-RST are very easily filterable at or before the victim. And b) more important: The TCP-RST und ICMP unreachable packets are very small, so the botnet needs to be extremely large. As such large botnets are expensive, an attacker will likely try to get the amplification behind the botnet for free. That's why reflection attacks without amplification are not seen in the wild. You should worry about your DNS server more than about error responses. – Hendrik Brummermann Apr 23 at 20:06
really useful reply, thanks :)

http://security.stackexchange.com/questions/3290/reject-ip-packets-with-an-icmp-error-or-just-drop-them

Port Knocking is it a good idea?

Normally for a server I like to lock down SSH and other non-public service to only be accessible by certain IP addresses. However this is not always practical if the business doesn’t have static IP addresses or if outside developers need access.

I heard about Port Knocking a while ago and have finally had chance to look into it as a solution to the above problem. As a result of this I have a load of questions I hope people can help me out with.

Has anyone deployed it within their Business / Organisation and can offer any advise?
What is the best knocking Daemon to run under Linux?
What are the best clients for Linux, Windows and OSX?
What is the recommend length for knock sequence and is it best to use TCP, UDP or Both?
What are the associated downsides and issues with using it?
Is it just Security Through Obscurity?
Are there any alternatives to the port knocking approach?
network firewalls port-knocking
linkimprove this question
edited Dec 16 '10 at 21:34
AviD♦
9,29811546
asked Dec 16 '10 at 17:22
Mark Davidson
2,829425

71% accept rate
feedback
6 Answersactiveoldestvotes
up vote
7
down vote
accepted
While I have not deployed it yet, I know many people who have deployed it. Every single one of them have noted a significant reduction in the amount of bandwidth consumed by things like SSH brute-force attacks as a result.

However, that is not to say that there are not downsides. AFAIK, there are no kernel-based port knocking implementations available, which for me would be the real key to adoption. Port knocking daemons rely on reading failed (and filtered/prohibited) log file entries from a firewall system. That's all fine and dandy, but what happens if the filesystem gets full? What happens when the daemon gets killed because of some runaway process eating up the system's RAM and swap? What happens if something else which either of those two things depend on just up and stop working? You most likely end up with a server that you will have to physically access. That could wind up being more costly than is reasonable, especially if you are more than a few tens of miles away from the server and do not have anyone that you can call to get there in a hurry.

One thing that I can say is that it is not "security through obscurity". Port knocking is a form of authentication, and like any authentication system it can be made to be as simple or complex as desired. Something as simple as "knock on port 10,000 + realPortNumber" can be done, which would amount to a trivial break, or the port knocking might itself be used to transmit some form of real authentication (say, 1 block of AES encoded data given a key derived by some other method). It would not be feasible to use port knocking to transmit large amounts of data, though, because it would take significantly longer than just sending a single packet, and if the packet is over TCP than at least it can be known if it was received successfully or encountered some form of error.

One interesting question that this brings up, however, is how to manage the log files---userland implementations mostly require the log files in order to determine whether or not a knock has been successfully sent, and what happens if those logs are leaked? Authentication data becomes known, and that is obviously not a very good thing.

I cannot tell you whether or not to use port knocking in your setup. I am not yet, and I am not 100% certain that I ever will be. It makes more sense to me to use strong authentication systems that are based on strong cryptography (such as a PKI infrastructure) than it does to throw port knocking in the way. Also, adding a single point of failure to access critical infrastructure, to me anyway, seems like a bad idea, and way more difficult to properly support with any sort of guarantee. Again, though, that is based on the notion of the port-knocking software being not integrated with the firewall at the operating system kernel level; if that ever changes, I may also change how I feel about using it.

linkimprove this answer
answered Dec 16 '10 at 20:53
Michael Trausch
2084
1
+1, very nice answer - and gave me at least a better idea about port knocking. – AviD♦ Dec 16 '10 at 21:36
1
If you're concerned enough about security to consider port knocking, why not just go with real two-factor authentication instead of adding another layer of plain text auth? – Alex Holst Dec 16 '10 at 22:16
1
I absolutely agree. Among the options I am considering for deployment in my network setup are crytographic tokens and one-time-pads. – Michael Trausch Dec 16 '10 at 22:18
3
If its a linux based system (althuogh I imagine that the approach would be portable to most stateful packet filtering firewalls) you can implement a complete solution in iptables - which eliminates a lot of the complexity / reliability problems of a userspace program or custom kernel module. Have google. – symcbean Dec 17 '10 at 9:54
feedback
up vote
6
down vote
Port knocking is not just another plain text password - at least when used to protect services that listen on a TCP port like SSH. Port knocking implies that service discovery with nmap is no longer possible because of the use of a default-drop firewall policy. SSHD has had remotely exploitable vulnerabilities too, and these have nothing to do with weak passwords. I don't want anyone to be able to fire up nmap and see that I have SSHD listening.

Also, there is a stronger variant of port knocking called "Single Packet Authorization", but it also is a completely passive authentication scheme so it retains the benefits of port knocking but solves its limitations (replay attacks are easy, DoS attacks are easy, etc.).

linkimprove this answer
answered Dec 17 '10 at 3:42
Michael Rash
611
feedback
up vote
2
down vote
As per my comments elsewhere, although there are lots of implementations that use all sorts of special tricks to respond to the knock, it can be implemented purely using iptables on a Linux system. i.e. this is effectively a kernel-based port knocking implementation

Since the knock is visible on the network, using sequences of more that 3 knocks gives little benefit. I'd recommend using TCP - although it will be slower, you've got a better guarantees that the knock was delivered.

However, although it relies on userspace programs, my preference is for fail2ban since it requires no additional steps / software to connect, runs reliably, and if it did ever fail it wouldn't prevent me accessing the servers.

It does surprise me that there's is so little adoption of encrypted ident - although RFC1413 merely mentions this a possible approach using the protocol rather than defining how it should work.

But of course you should ensure that you've restricted access as much as possible independently of this (i.e. no root login, restrict access to nominated group, if practical, require key pairs). SSH is designed to be secure - and historically there have been relatively few vulnerabilities in the main stream implementations. The reason that attacks are successful is usually down to a combination of guessable usernames, simple passwords and brute-force attacks or social engineering. Note that I'm not advocating you enforce a complex passphrase validation (other than minimum length) nor that you require users to keep changing their passwords, there are better approaches (e.g. two-factor), but unfortunately very few implementations.

linkimprove this answer
answered Dec 17 '10 at 10:15
symcbean
8006
feedback
up vote
2
down vote
I have not implemented port knocking in a number of years, however, I suspect that it has not changed significantly in principle. Other comments contain many valid points and I will not simply repeat them here.

One aspect of port knocking that I always implemented as a matter of course is to base the knock sequence off of a pseudo-random but repeatable value, such as the current date and time. This strategy does not eliminate wholesale the danger of a replay attack, however, it does limit the exposure of a given knock sequence. Obviously for this to be successful a synchronized time, in my example, source would be required for consistency.

linkimprove this answer
answered Dec 17 '10 at 14:14
Tok
2562
It has changed though. – chiggsy Apr 24 at 19:34
feedback
up vote
2
down vote
It is an easily verified fact that all internet facing services have security vulnerabilities relatively often - services such as SSH, OpenSSL, etc. Attacks on these are tried en masse on the internet, targeting any systems that have suitable open ports.

Port knocking, in my mind, has the purpose of keeping away these random attackers from the internet, that are looking for generic vulnerabilities. That is, it is not supposed to keep away a dedicated attacker, or form any part of the actual security of the services. The benefit of port knocking should be that it would, really, be simple enough that it wouldn't be likely that there are any exploitable bugs in it, ever.

This usage means that port knocking can be as lax as can be, as long as it keeps away the majority of attackers. It may be just security by obscurity, but a better way is to have it as a weak form of "password" authentication.

So the "best" port knocking service would be one which it is inconceivable to imagine any attacks against, yet be trivial enough for any legitimate user to use from any sort of client machine.

linkimprove this answer
answered Dec 17 '10 at 18:21
Nakedible
1794
feedback
up vote
0
down vote
Port Knocking is just another plain text password. It can be brute-forced, discovered, captured and replayed like any other plain text password. Why re-invent telnet logins?

You have to trust something. So let's assume your trust your OS networking stack and you trust sshd when running with delayed compression, privilege separation and only allows some reasonable form of two-factor authentication (say, key-based).

You can use "simple" services like sshd that invokes authpf to protect your more complex, vulnerable services.

authpf allows you to modify your firewalls rulesets based on who authenticates successfully against sshd, so only IP addresses that manage to login to your ssh gateways are allowed to connect to your compile/compute/database farm.

linkimprove this answer
edited Dec 18 '10 at 12:03
Mark Davidson
2,829425
answered Dec 16 '10 at 21:53
Alex Holst
3927
1
To be fair port knocking is laid on top of SSH so it's not the same as telnet. Also, even if it is plaintext, your attacker now has to capture that password and then try brute SSH. The people brute forcing SSH accounts, generally aren't the same people that have ways to sniff your traffic. – rox0r Dec 18 '10 at 7:34
1
Port knocking is not a plain text password. – Rory Alsop♦ Jan 10 at 1:09
I submit section 4 of rfp2k03.txt as proof that port knocking is just another password. If there's no encryption, it's even plain text. wiretrip.net/rfp/txt/rfp2k03.txt – Alex Holst

http://security.stackexchange.com/questions/1194/port-knocking-is-it-a-good-idea

port knocking

Broadly, port knocking (PK on wikipedia) is a form of host-to-host communication in which information flows across closed ports. There are various variants of the port knocking method - information may be encoded into a port sequence or a packet-payload. In general, data are transmitted to closed ports and received by a monitoring daemon which intercepts the information without sending a receipt to the sender.
Recently a physical knock detecting device that does to the door what port knock does to your server has been reported. This knock detector is mounted on the inside of a door and listens to ... you guessed it, secret knocks. Once a knock is detected, the device unlocks the door.
In one instance, port knocking refers to a method of communication between two computers (arbitrarily named here client and server) in which information is encoded, and possibly encrypted, into a sequence of port numbers. This sequence is termed the knock. Initially, the server presents no open ports to the public and is monitoring all connection attempts. The client initiates connection attempts to the se

http://www.portknocking.org/view/about

TCP/IP Connection cutting on Linux Firewalls and Routers

• TCP/IP Connection cutting on Linux Firewalls and Routers(Introducing "Cutter 1.03")
  • Summary
  • Introduction
  • What is a "TCP/IP connection cutter"?
  • How to kill a TCP/IP connection using "IPTables REJECT with RESET"
    • Simply put: Fire the "RST" bullet.
    • But we cant take the first shot, or shoot on someone else's behalf
    • IPTables as a possible "gun" (but not a perfect one)
  • Better: How to cut a TCP/IP connection by sending a FIN
  • Better still: Without iptables rules
  • Cutter 1.03
    • Description and Synopsis
    • License
    • Status
    • How you can help me
    • Download
  • News and Announcements

Summary

Network security administrators sometimes need to be able to abort TCP/IP connections routed over their firewalls on demand. This would allow them to terminate connections such as SSH tunnels or VPNs left in place by employees over night, abort hacker attacks when they are detected, stop high bandwidth consuming downloads - etc. There are many potential applications.
This article describes how a Linux IPTables based firewall/router can be used to send the right combination of TCP/IP packets to both ends of a connection to cause them to abort the conversation. It describes the steps required to perform this task, and introduces a new open-source utility called "cutter" that automates the process.

Important Warning

The technique documented here, and the software referred to are designed for "legal" and "appropriate" use by network security administrators and the like. It has been written as part of a larger Linux firewall project, targetting at controlling traffic from peer-to-peer software such as Kazaa, iMesh and others into and out of a private network. It is not designed as a tool for malicious use and the author in no way sanctions such use.
Users of the software should be aware that it's actions are easily detectable using a number of readily available network monitoring tools, and it makes no attempt to disguise it's actions. Malicious use of "cutter" could result in a jail sentance in a number of countries around the world.
The author cannot be held responsible for inapropriate use of the documented technique or software (whether in it's original form, or modified).

Introduction

The use of linux systems as IP network firewalls and routers is becoming increasingly popular. The cheapness of the software and hardware combine with the flexibility and reliability of Linux's networking support to make such a solution highly attractive. It is often possible to deliver routing and fire walling facilities at a fraction of the cost associated with systems provided by industrial heavy-weights such as Cisco, Nortel and others.
For the knowledgeable, an out-of-the-box linux distribution such as "RedHat" has many of the features required to build highly personalized firewalls. For the less adventurous; there are cut-down distributions available that are designed specifically for this task. The UK based "SmoothWall" and it's clone "IPCop" are good examples of such an approach; they are highly optimized distributions that include a tiny subset of the software commonly installed by the likes of RedHat, but add a powerful web-based front end for the tasks of configuring and managing the system. These solutions are ideal for small office or home networks.
One advantage of using a Linux system in this way is the ease with which it can be extended or modified. Software can be downloaded from the Internet for free, compiled and installed onto the system to add features such as web proxying (Smoothwall and IPCop already have this), content filtering, anti-virus measures or any other feature you desire.
I have recently been working on a solution to the problems of peer-to-peer traffic filtering on a Linux firewall, and have had to develop a "connection cutter" as part of the system, and it is this tool that is described in this page.

What is a "TCP/IP connection cutter"?

Consider a "client workstation" system in a private network, connected to a server on the public Internet, as in the picture below. The connection passes through the firewall which has two network cards - one connected to each network.
The job of the firewall is typically to ensure the safety of the systems on the private network, and the security of any information held on them. It is common for firewalls to be set up to allow the hosts on the private network more or less unrestricted use of services on the public Internet while setting very tight limits on what private systems can be accessed from the outside world.
Firewalls often use a network address mapping technique ("NAT") in order to allow the private addresses to be hidden from the outside world. For example; when the user of the client at 10.0.0.2 accesses the server at 100.1.2.3, the messages that the server receives lead it to believe that it is being accessed by a host with address 200.4.5.6 - ie the public side of the firewall. The firewall "messes about with" (technical term!) the network traffic that passes through it in order to allow this little deception to work.

A TCP/IP connection cutter is a software tool that can be run on the firewall to forcibly abort the connection between the server and the client. This is done in a way that leaves both ends believing that it was the other that initiated the abort. Only a device that sits in the path of the connection (such as the firewall in our example) can do this.
The ability to abort a connection in this way can be useful to firewall administrators for any number of reasons. For example...

• A firewall administrator identifies that a workstation on his network is using a service on the public network that should not be permitted. He can force the closure of the connection. This might be because of the network bandwidth being used, or the nature of the service or some other reason that fits the organization's security policy.
• Or: a firewall administrator can forcibly close SSH tunnels or VPNs that rogue employees leave open over night between their office desktops and home networks. This can be a real problem, and it is a well known access route into private networks.
• Or a web server administrator can request that a rogue incoming connection is terminated without having to "kill" the web server process on the server.
  

A connection cutter is NOT a way for rogue systems to terminate connections made by others - it must be run on one of the routers through which the connection passes and as such has limited application for attackers interested in denial-of-service exploits.

How to kill a TCP/IP connection using "IPTables REJECT with RESET"

Simply put: Fire the "RST" bullet.

At the most basic level, it's dead easy - just send an "RST" packet to both ends of the connection.
The TCP/IP protocol defines a packet called "RST", which is short for "Reset". When an RST packet arrives on a connection it is understood to mean that something has gone badly wrong and that the application should abort the conversation. "Badly wrong" means something like a protocol error, unrecoverable corruption, breaks in the circuit etc. The RST packet does not include information about the nature of the problem but is simply a kind of "Panic button" that tells it's recipient to stop talking.

But we cant take the first shot, or shoot on someone else's behalf

Since RST packets present such a golden opportunity for attack, most systems will insist that the sequence number information contained in the packet, and the address from which it comes contain good "expected" values. Some systems even check the layer 2 MAC address before agreeing to act on the instruction to reset. These measures make RSTs harder to "spoof". In fact, the normal RST-sending logic embedded in the Linux kernel (and, I imagine: others) is to send RSTs only in response to incoming packets - that way, the sequence number can be guaranteed to be correct.

IPTables as a possible "gun" (but not a perfect one)

One solution for a Linux router using IPTables is to define a rule that says "reject packets sent from address 100.1.2.3 to 10.0.0.2 (and visa versa) with an RST".
To use this technique, we must..

• Discover which IP addresses and port numbers refer to both ends of the conversation, and the "NAT"ed addresses that are used to present them over the subnets. All the relevant information is held in the pseudo file /proc/net/ip_conntrack.
• Build an IPTables rule that rejects relevant outbound forwarded traffic by responding to it with an RST. For our example above, the iptables command will look something like the following (depending on how your tables are named, and the port numbers used)..
  • iptables -A FORWARD -p tcp -s 10.0.0.2 --sport 3245 -d 100.1.2.3 -dport 22 -j REJECT --reject-with tcp-reset 
• Build another rule that does the same for inbound traffic.
  • iptables -A FORWARD -p tcp -s 100.1.2.3 --sport 22 -d 10.0.0.2 --dport 3245 -j REJECT -reject-with tcp-reset
• Watch the network traffic using something like tcpdump to wait for the next incoming and outgoing packets from both ends of the connection, and observe that IPTables does indeed send the RST packets back, or keep a track of the iptables counters for the rules we have created.
• Finally; remove the IPTables rules so that they don't interfere with future traffic or clog up precious table space.
  • iptables -D FORWARD -p tcp -s 10.0.0.2 --sport 3245 -d 100.1.2.3 -dport 22 -j REJECT --reject-with tcp-reset
  • iptables -D FORWARD -p tcp -s 100.1.2.3 --sport 22 -d 10.0.0.2 --dport 3245 -j REJECT -reject-with tcp-reset
    

The result of all this activity is that the client end of the conversation thinks that the server has reset the link, and the server thinks that the client did it - so we have a clean closure of the connection.
However, there are a couple of issues with this approach.
First: IPTables will not send an RST until an incoming or outgoing packet arrives from the client or server for it to reject. If the application is connected but idle - this may take many minutes or hours to occur. An example is an SSH or telnet session where the user is typing nothing. The connection stays "up" until the user hits the first keystroke on the keyboard, at which point a packet is sent to the server (via the firewall), and firewall can respond to it with an RST.
Second; we cant abort both ends simultaneously. To take the SSH or telnet example already sited - the client will abort the connection when it gets it's RST after the user presses a key, but the server will know nothing about what has happened, and will still believe the connection to be open. This situation will persist until the server sends a packet - which it may never do.
It would be nice to be able to force the transmission of RST packets immediately, so closing the connection even when there is no application data being sent.

In effect, the firewall cant "shoot" it's RST bullet until client and/or server have sent something through the firewall that allows it to determine the sequence number that should be included in the RST packet. Simply guessing a sequence number wont work - the client and server will (if they are sensible) ignore the packet.

Better: How to cut a TCP/IP connection by sending a FIN

The idea of sending an "RST" packet to both ends is good, but we could do with a better way of getting it sent than turning on an IPtables "reject" rule and waiting for something to arrive that the firewall can reject. What is needed is some way of forcing the two ends of the connection to send a packet to the firewall that IPtables can then respond to.
There is a feature of the TCP/IP protocol that we could use to good effect here :- If a packet (other than an RST) is received on a connection that has the wrong sequence number, then the host responds by sending a corrective "ACK" packet back. This "ACK" reply is designed to put the sequence numbers at both ends back into step - and allows the protocol to retransmit packets that got lost. This is very nice for our needs - if the firewall sends a packet that is "correct" in all respects except for the sequence number, then the host very helpfully tells us what should have been used. We can then use this information to build the RST packet that will abort the connection.
Following this idea, we can do the following..

• Identify the IP addresses and port numbers of the hosts at both ends of the connection, and any NATted address that the firewall is using to present the private host to the public network by inspecting the /proc/net/ip_conntrack file.
• Build the IPtables rules that will send RST packets to both ends of the connection when an incoming packet arrives (the rules have already been described).
• Send a packet to both ends with bad sequence numbers.
  • use sequence_number = zero - it's pretty much bound to be wrong (which is what we want).
  • use a FIN packet - they fairly easy to put together and don't need to contain any "data" payload.
  • Send the packet using Layer 2 raw Ethernet access - so that the IP layers don't mess around with the headers.
    • We need the MAC address of the next hop to the target machine for this - which we can determine by inspecting the firewall's ARP and routing tables.
• Wait for the hosts to respond with their ACK, and for Iptables to send it's RST packet back.
• Remove the newly added Iptables rules.
  

This procedure is better than the previous one because the effect is immediate. We don't have to wait for the user of the offending SSH session to press a key because we have tricked his computer into sending us something to respond to.
But - we still have to have a process for determining when the FIN - ACK - RST packets have done their stuff so that we can clean up the iptables rules. Various options for doing this are possible. For example: the rules can be left in place, while a cron job does a periodic cleanup. Or we can "listen in" to the packet flow using Linux's raw packet mode. I'm sure there are any number of other "clean up" solutions that could be devised.

Better still: Without IPTables rules

It turns out that we can produce the same FIN -> ACK -> RST sequence of packets without using Iptables to generate the RST at all - so there are no IPTables rules to create or clean up.
The "raw packet socket" technique we have already suggested for the sending of the FIN packet can be used to listen for the incoming ACK, and send the resulting RST. This is how the "cutter" program works.

Cutter 1.03

Description and Synopsis

"Cutter" is an open source program that uses the FIN-ACK-RST packet technique described above to abort TCP/IP connections routed over the firewall or router on which it is run. It can be called using one of the following four syntaxes..

cutter ip-address

Example: "cutter 10.10.0.45"

Cuts all connections passing through the firewall between any ports on the specified ip-address (either a "private" or "public" address) and any other hosts. This can be used to close down all incoming connections to a particular server, all outgoing connections from a particular client or all outgoing connections to a server.

cutter ip-address port

Example: "cutter 200.1.2.3 80"

Cuts all connections to or from the specified ip-address/port pair. This allows the user to be a little more specific than the previous example and allows targetting of specific services on specific hosts.

cutter ip-address-1 port-1 ip-address-2

Example "cutter 200.1.2.3 22 10.10.0.45"

Cuts all connections between ip-address-2 and ip-address-1/port-1. This allows the user to cut connections between a specified "client" and a particular service on a specified host. Our example closes host 10.10.0.45's SSH connection to server  200.1.2.3.

cutter ip-address-1 port-1 ip-address-2 port-2

Example: "cutter 200.1.2.3 22 10.10.0.45 32451"

Cuts the specific connection between the two ip/port number pairs given.

License

Cutter 1.03 is released under the terms of GNU GENERAL PUBLIC LICENSE Version 2 (June 1991) and comes with all the usual freedom, openness and disclaimers associated with that license.

Status

Cutter 1.03 should be considered experimental. The author is releasing a tool that works on the systems he has access to (namely: IPCop and RedHat Linux), and he is seeking input on it's use on other systems, ideas for improvement, offers of sponsorship - etc.

Courtesy : http://www.lowth.com/cutter/

Using IPset with IPtables to block large IP ranges

There are a large number of firewall and security appliances on the market, some good some awful. I tend to use a lot of Cisco security products. With the current supply chain problems in getting hold of Cisco products I have been looking around the market. I have noticed that a number of products are systems which have FreeBSD or Linux at the heart under a nice shiny badge.
I thought I will put together a solution myself based on the same ingredients. The reason why is because I have realised that I have become dependent on main stream vendors to deploy solutions, and don’t always fully address the need. With the push to virtualisation, it would be good to have a powerful virtualised firewall just like the big boys. So he is what I have done so far.

High performance Ubuntu Firewall

If you run a webserver you will know that your webserver is scanned and probed from particular networks from originating from a hot-spot of countries. If your web application does not require then why not just block it.
Well it can prove expensive in terms of performance, to block a whole country can take 1000’s of rules (http://www.countryipblocks.net/). Well using this solution you can do things some of the big boys cant do ( Sonicwall !). Using iptables and IPset you can create 1000’s of rules and objects with impacting heavily on performance.
Iptables is already part of all Linux Distributions, However IPset is not. You have to install it and it can be a bit awkward. However it is a piece of cake in Ubuntu 10.04 LTS.

sudo apt-get install ipset ipset-source
m-a a-i ipset

Performing the previous commands will install the required kernel modules using module-assistant, and also the user space tools. You are know ready to create your very large firewall rules. This is so much easier than patching the kernel with patcho-matic and recompiling iptables. This is how you use it
Create your sets, you can get your network list from http://www.countryipblocks.net/ and write a script to generate the creation of the list.

ipset –create feckoff nethash
ipset –add feckoff 27.8.0.0/12
ipset –add feckoff 27.24.0.0/13
ipset –add feckoff 27.8.0.0/12
ipset –add feckoff 27.24.0.0/13
ipset –add feckoff 27.36.0.0/13
ipset –add feckoff 27.44.0.0/14
ipset –add feckoff 27.50.128.0/17
ipset –add feckoff 27.54.192.0/18
ipset –add feckoff 27.144.0.0/16
ipset –add feckoff 27.148.0.0/10
ipset –add feckoff 27.212.0.0/12
ipset –add feckoff 58.14.0.0/13
ipset –add feckoff 58.22.0.0/14
……. etc etc 100’s of subnets later you have added all your subnets, DONT MIX /32 networks or hosts

Now he comes the important bit. Now you have created your IPset you can now apply it to your rule base.

iptables -A INPUT -m set –set feckoff src -j DROP

You have just blocked 1000’s of subnets with one command in your ruleset
In an ideal world you would not really want to block a whole range of subnets like this, It is not the best use of resources. However there are times when this is required to increase security of you webserver against a particular type of attack.

Courtesy :  http://www.jsimmons.co.uk/2010/06/08/using-ipset-with-iptables-in-ubuntu-lts-1004-to-block-large-ip-ranges/

How to block huge amount of IP adresses

Sometime you need to block really big numbers of IP addresses. It could be for different reasons. For example, in case of password bruteforce, DDoS attack. Of course, you can block them just in iptables. But there can be a problem. If set of IP adresses contain thousands of items iptables perfomance decreases (actually, perfomance of netfilter, as soon as iptables is just a tool for managing firewall). Your CPU load can increase too. Fortunately there is a perfect solution – ipsets.
So here is a problem. You need to add thousand of IP to your firewall. In almost all cases there are random IPs from various network. Here we suppose you run Fedora 14 box so you don’t have to recompile kernel modules.
First of all you need to install xtables-addons. You can find it in RPM fusion repository.

yum install  xtables-addons

Next create ipset chain. We’ll call it autoban:

ipset -N autoban iphash ––hashsize 4096 ––probes 2 ––resize 50

Add it to your iptables chain. It can differ depending on your firewall settings. Here we use ethin chain.

iptables -I ethin 2 -p tcp -m multiport ––dport 80,443 -m set ––match-set autoban src -j DROP

Now you can add all bad IP to your ipset. For instance, you have text file called bots.txt with one IP per line. So you can add them to ipset using simple bash script:

for i in $( cat /tmp/bots.txt ) ; do ipset -A ban $i ; done

To check run:

ipset -L autoban

Save rules to config:

/etc/init.d/ipset save

Enable ipset startup script to load after reboot.

chkconfig ipset on

Note! To prevent blocking yourself you may add simple cron task:

*/5 * * * * ipset -F

In case you made some mistake it will flush all items from all ipsets.
Also you should know ipset supports different IP sets –– ipmap, macipmap, portmap, nethash and so on.
Refer to man ipset to choose which fit your requirements.
Starting with version 5.0 ipset supports IPv6. But Fedora 14 includes ipset 4.4.

Courtesy : http://supportex.net/2011/02/block-huge-amount-ip-adresses-ipset-fedora-14/

Endian Firewall

Endian Firewall Community (EFW) is a "turn-key" linux security distribution that turns every system into a full featured security appliance with Unified Threat Management (UTM) functionality. The software has been designed with "usability in mind" and is very easy to install, use and manage, without losing its flexibility.
The features include a stateful packet inspection firewall, application-level proxies for various protocols (HTTP, FTP, POP3, SMTP) with antivirus support, virus and spam-filtering for email traffic (POP and SMTP), content filtering of Web traffic and a "hassle free" VPN solution (based on OpenVPN).

General	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
Open Source License (GPL)
Free download	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A
Suggested number of users (not limited)	N/A	<25	<100	<250	250+	<1,000	<2,500	5-10	25+
Commercial support options
Ticket System Support
Direct support from Endian
Phone Support
Live/Remote Support (hands on)
Instant Hardware Replacement
Industrial Grade Hardware								N/A	N/A
LCD display with system status and management functionality	N/A	N/A						N/A	N/A
Network Security	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
Stateful Packet Firewall
Demilitarized Zone (DMZ)
Intrusion Prevention (Snort)
Multiple Public IPs
Quality of Service and Bandwidth Management
SNMP support
VoIP/SIP support
Portscan Detection
DoS and DDoS Protection
SYN/ICMP Flood Protection
Anti-Spoofing Protection
VLAN support (IEEE 802.1Q trunking)
DNS Proxy/Routing
Web Security	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
HTTP & FTP proxies	N/A
Anti-virus (100.000+ patterns)	N/A
Transparent Proxy support	N/A
Content Analysis/Filtering	N/A
URL Blacklist	N/A
Authentication: Local, RADIUS, LDAP, Active Directory	N/A
NTLM Single Sign-On	N/A
Group based web content filter	N/A
Group based web access policies	N/A
Time based access control with multiple time intervals	N/A
Sophos Antivirus (optional)	N/A
Mail Security - REVISED	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
SMTP & POP3 proxies	N/A
Anti-spam with Bayes, Pattern, SPF,	N/A
Heuristics, Black- and White-lists support	N/A
Anti-virus (100.000+ patterns)	N/A
Transparent Proxy support	N/A
Spam Auto-Learning	N/A
Transparent Mail Forwarding (BCC)	N/A
Greylisting	N/A
Commtouch RPD (optional)	N/A
Sophos Antivirus (optional)	N/A
Virtual Private Networks (VPN)	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
True SSL/TLS VPN (OpenVPN)
IPSEC
Encryption; DES, 3DES, AES 128-,192-, 256-bit
Authentication: Pre-Shared Key, Certification Authority, Local
Support for VPN over HTTPS Proxy (OpenVPN)
X.509 and 2 factor based authentication
PPTP Passthrough
Pushing of DNS settings and Routes to clients (OpenVPN)
Automatic connection failover (OpenVPN)
Native VPN Client for MS Windows, MacOSX and Linux
Hotspot	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
Captive Portal	N/A							N/A
Wired/Wireless support	N/A							N/A
Pre-/Post-paid and free Tickets	N/A							N/A
Traffic-based Tickets	N/A							N/A
Integrated RADIUS service	N/A							N/A
Connection Logging	N/A							N/A
No additional software/hardware required	N/A							N/A
Per-user and global bandwidth limiting	N/A							N/A
MAC-address based user accounts	N/A							N/A
User accounts import/export per CSV	N/A							N/A
Single-click ticket generation (Quick ticket)	N/A							N/A
Automatic client network configuration (support for DHCP and static IP)	N/A							N/A
Generic JSON-API for external accounting and third party integration	N/A							N/A
High Availability	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
Hot Standby (active/passive)	N/A							N/A
Node Data/Configuration	N/A							N/A
Synchronization	N/A							N/A
Multi-WAN with Failover	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
Support for multiple Uplinks/WANs
Automatic WAN Uplink Failover
Monitoring of WAN Uplinks
Uplink types: Ethernet (Static/DHCP), PPPoE, ADSL, ISDN, PPTP
UMTS/GPRS/3G support
Routing	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
Static Routes
Source-based Routing
Destination-based Routing
Policy-based Routing (based on interface, mac, protocol or port)
Network Address Translation (NAT)	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
Destination NAT
Incoming Routed Traffic
One-to-One NAT
Source NAT (SNAT)
IPSec NAT Traversal
Logging/Reporting	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
Real-time Dashboard
Event handling and notification
Live Log Viewer (AJAX based)
Detailed User Based Web Access Report	N/A
Network/System/Performance Statistics
Rule-based logging settings (Firewall Rules)
Syslog: Local or Remote
Management	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
Easy Web-based Administration (SSL)
Secure Remote SSH/SCP Access
Serial Console
Centralized Management through Endian Network (SSL)
Updates and Backup	4i Office / Industrial	Mini	Mercury	Macro X1	Macro X2	Macro R1	Macro R2	5-10 Users	25+ Users
Backup/Restore Firewall settings from Web-Interface
Centralized Updates through Endian Network
Anti-virus Definitions	N/A
URL Blacklist Definitions	N/A
Scheduled Automatic Backup
Encrypted Backups via E-mail
Instant Recovery/Backup to USB-Stick

Courtesy : http://www.endian.com/en/community/download/