I have updated my original post to address some of the comments made here on Slashdot. Peer review is always good, and thank you all for the insights.
Re:Does anybody still filter based on ports?
on
Linux Firewalls
·
· Score: 1
By running fwsnort (covered extensively in the Linux Firewalls book), iptables is endowed with true application layer matching capability for Snort rules, and this takes Linux firewalling far beyond port-based filtering. Many fwsnort iptables rules apply to port 80 for example, but only trigger when malicious data is sent at the application layer.
Portsentry is dead, and while it was interesting several years ago, it has serious architectural problems that in my mind make it unsuitable for use as a security application when compared to something like psad. Here are the reasons why: http://www.cipherdyne.org/psad/docs/faq.html#diff_portsentry
True, port knocking is outdated technology for several reasons:
1) Difficult to solve the replay problem.
2) Extremely easy to bust knock sequences just by connecting to spurious ports.
3) Knocking sequences appear like a port scan to any intermediate IDS.
4) Cannot transfer a reasonable amount of data.
Setting up a daemon that waits for a password before allowing access to a protected service would definitely provide better security than nothing at all. This is because a lightweight authorization server is most likely much less complex than whatever service it is protecting.
Port knocking has the additional advantage of allowing the authentication layer to be pushed as low in the stack as possible. This means that the number of code paths (which could contain known/unknown vulnerabilities) is minimized. Also, if the authorization packets are sniffed off the wire as they travel to an unrelated IP, it becomes difficult to know where the actual knock server is running.
Yes, libpcap has had vulnerabilities before. However, the complexity of the libpcap code vs. that of services fwknop protects (such as OpenSSH) is much lower. Fwknop can be used to protect multiple servcies as well. Also, fwknop can simply read the Netfilter log file if you want to use the old port knocking method.
fwknop prevents replay attacks in server mode by keeping track of MD5 sums of valid (decrypted) messages. The fwknop client prepends all messages with 16 bytes of random data which ensures that no two messages are the same. This way the same command can be sent without matching to a previously seen MD5 sum.
No one is claiming that Netfilter (or any other software) is perfect. One of the main advantages of this strategy is that at least the number of code paths is minimized by intercepting packets at the lowest level possible; i.e. within the kernel. In addition, because fwknop uses libpcap, the authentication packet can be destined for a seemingly totally unrelated IP but open up the firewall in a system that can watch this traffic go by on the wire.
In the fwknop implementation, there are _no_ open ports, just as you suggest above. Fwknop relies on iptables to do two things: 1) log all connection attempts to ports that are not open by design, and 2) drop all such connection attempts. This way the knock client never receives any traffic from the server whatsoever (e.g. no tcp resets or successful connection completions) as it sends the knock sequence across the network. Fwknop exclusively uses the resulting iptables log messages to validate the knock sequence and to passively fingerprint the source operating system. Fwknop could have used a packet capture library to get the same data, but implementing it around iptables logs seemed like an elegant solution since it requires the proper configuration of your firewall at the same time.
Protecting a service with port knocking is only practical if gaining access to the service does not have to happen quickly. Protecting a web server with a port knocking scheme is not practical. However, if Microsoft wanted to build an extra layer into their OS so that their tcp stack would simply not allow a session to be established from any non-Microsoft OS, that is a different matter.
Because certain things should not be implemented within iptables. For example, fwknop supports encrypted knock sequences with the Rijndael block cipher; psad supports email alerts to DShield, parsing of Snort rulesets, whois and reverse dns lookups, etc. Such functionality does not belong in iptables itself.
Yes, that is a cool idea. I would need to use libnet and so the client code would be a bit more complicated, but this would be very interesting to implement.
Yes. It is just another hoop we can make an attacker jump through. If someone sniffs the knock sequence, they can always replay it but it will only be honored if they replayed the sequence correctly (fwknop implements timing delays in knock sequences) _and_ they generate the sequence from the required OS. Of course, using something like Packet Purgatory OS neuances can be spoofed, but at least the bar is just a little higher.
What about the set of hackers (crackers) that have found 0-day attacks? Granted the number of people that fall into this category is extremely small, but the data on my personal system is just too important to risk it. I want an additional layer of security. Although security through obscurity is not good if it is the _only_ protective mechanism, having another layer always helps:
Slashdot Mirror
I have updated my original post to address some of the comments made here on Slashdot. Peer review is always good, and thank you all for the insights.
By running fwsnort (covered extensively in the Linux Firewalls book), iptables is endowed with true application layer matching capability for Snort rules, and this takes Linux firewalling far beyond port-based filtering. Many fwsnort iptables rules apply to port 80 for example, but only trigger when malicious data is sent at the application layer.
Portsentry is dead, and while it was interesting several years ago, it has serious architectural problems that in my mind make it unsuitable for use as a security application when compared to something like psad. Here are the reasons why: http://www.cipherdyne.org/psad/docs/faq.html#diff_portsentry
True, port knocking is outdated technology for several reasons:
1) Difficult to solve the replay problem.
2) Extremely easy to bust knock sequences just by connecting to spurious ports.
3) Knocking sequences appear like a port scan to any intermediate IDS.
4) Cannot transfer a reasonable amount of data.
To name a few...
There is a better way that actually offers a real security benefit and solves all of the above problems; Single Packet Authorization (see http://www.cipherdyne.org/fwknop/). Here is a paper that describes all of the benefits of SPA over port knocking: http://www.cipherdyne.org/fwknop/docs/SPA.html).
Try fwknop. The single-packet strategy it implements provides many advantages beyond port knocking: http://www.cipherdyne.org/fwknop/
Setting up a daemon that waits for a password before allowing access to a protected service would definitely provide better security than nothing at all. This is because a lightweight authorization server is most likely much less complex than whatever service it is protecting.
Port knocking has the additional advantage of allowing the authentication layer to be pushed as low in the stack as possible. This means that the number of code paths (which could contain known/unknown vulnerabilities) is minimized. Also, if the authorization packets are sniffed off the wire as they travel to an unrelated IP, it becomes difficult to know where the actual knock server is running.
Yes, libpcap has had vulnerabilities before. However, the complexity of the libpcap code vs. that of services fwknop protects (such as OpenSSH) is much lower. Fwknop can be used to protect multiple servcies as well. Also, fwknop can simply read the Netfilter log file if you want to use the old port knocking method.
fwknop prevents replay attacks in server mode by keeping track of MD5 sums of valid (decrypted) messages. The fwknop client prepends all messages with 16 bytes of random data which ensures that no two messages are the same. This way the same command can be sent without matching to a previously seen MD5 sum.
No one is claiming that Netfilter (or any other software) is perfect. One of the main advantages of this strategy is that at least the number of code paths is minimized by intercepting packets at the lowest level possible; i.e. within the kernel. In addition, because fwknop uses libpcap, the authentication packet can be destined for a seemingly totally unrelated IP but open up the firewall in a system that can watch this traffic go by on the wire.
In the fwknop implementation, there are _no_ open ports, just as you suggest above. Fwknop relies on iptables to do two things: 1) log all connection attempts to ports that are not open by design, and 2) drop all such connection attempts. This way the knock client never receives any traffic from the server whatsoever (e.g. no tcp resets or successful connection completions) as it sends the knock sequence across the network. Fwknop exclusively uses the resulting iptables log messages to validate the knock sequence and to passively fingerprint the source operating system. Fwknop could have used a packet capture library to get the same data, but implementing it around iptables logs seemed like an elegant solution since it requires the proper configuration of your firewall at the same time.
Protecting a service with port knocking is only practical if gaining access to the service does not have to happen quickly. Protecting a web server with a port knocking scheme is not practical. However, if Microsoft wanted to build an extra layer into their OS so that their tcp stack would simply not allow a session to be established from any non-Microsoft OS, that is a different matter.
Because certain things should not be implemented within iptables. For example, fwknop supports encrypted knock sequences with the Rijndael block cipher; psad supports email alerts to DShield, parsing of Snort rulesets, whois and reverse dns lookups, etc. Such functionality does not belong in iptables itself.
Yes, that is a cool idea. I would need to use libnet and so the client code would be a bit more complicated, but this would be very interesting to implement.
Yes, but fwknop also offers the following capabilities which cannot (easily) be emulated with iptables rulesets alone:
-encrypted sequences with the Rijndael algorithm
-timing delays (both min and max) between successive ports in a knock sequence
Yes. It is just another hoop we can make an attacker jump through. If someone sniffs the knock sequence, they can always replay it but it will only be honored if they replayed the sequence correctly (fwknop implements timing delays in knock sequences) _and_ they generate the sequence from the required OS. Of course, using something like Packet Purgatory OS neuances can be spoofed, but at least the bar is just a little higher.
You might want to check this link out:
Hos is psad different from portsentry?
What about the set of hackers (crackers) that have found 0-day attacks? Granted the number of people that fall into this category is extremely small, but the data on my personal system is just too important to risk it. I want an additional layer of security. Although security through obscurity is not good if it is the _only_ protective mechanism, having another layer always helps:
"Security Through Obscurity" Ain't What They Think It Is