Silent Drop vs Reject Firewall rules
We received several comments about firewall rules and silently dropping packets vs. sending the correct icmp or TCP reset codes. While it violates some rfc's silent drop is my standard recommendation.
Some might ask why I choose silent drop. I will explain but first a few questions.
What does it help if the firewall sends notification of traffic it rejects?
Why tell the bad guy what you're blocking? (And what your not blocking).
Which good guy is permitted to scan my systems for open ports or protocols?
1: Silent drop prevents some reflective attacks.
In some cases the source address of the attack victim is spoofed. The desire is to cause firewalls, routers and other systems to send traffic back against the spoofed source.
2: Silent drop prevents reverse mapping.
In other cases by sending back a "port closed" type message your firewall can be negatively mapped. (e.g Denied 1-1024 except 22, 23, 25,...). That is how nmap udp port scan and protocol scan work. They basically assume a port or protocol is open unless they get a message stating its closed.
3: Silent drop might not be effective, as a reject might never reach the intended target.
With the recently discovered blind TCP resets via forged icmp errors the rfc's governing some of these reactions will probably be changed. Gont the author of the vulnerability suggested a larger amount of the original packet be returned with the icmp error packet. In the mean time one of the primary mitigations for this issue is to ignore the first few icmp errors that could cause a reset. Many networks blocked some incoming icmp error messeges as a result of that vulnerability.
I personally require silent drop (no icmp, no TCP resets) as a standard feature from firewalls and other filtering devices.
The jury is still out on the "correct" thing to do but if a firewall or filtering devices doesn't support silent drop I would not buy it or recommend it. It should be an option the end user can choose.
Additional comments were contributed by fellow handler Swa Frantzen and Johannes Ulrich respectively
"I try to build "drop" to the "bad" side and reject to the "good" side. Good
and bad might not always be in and outside. I permit the
network admin stations to initiate traceroute and icmp echoes,
in order to not have the reaction "it's the firewall" all over the place when the firewall is working as intended."
Swa
One reason to have internal reject rules that prevent systems from 'calling out' but send correct error report: is rejects make it easier to debug issues. In these cases its more about mistakes then malicious users.
Johannes
Some might ask why I choose silent drop. I will explain but first a few questions.
What does it help if the firewall sends notification of traffic it rejects?
Why tell the bad guy what you're blocking? (And what your not blocking).
Which good guy is permitted to scan my systems for open ports or protocols?
1: Silent drop prevents some reflective attacks.
In some cases the source address of the attack victim is spoofed. The desire is to cause firewalls, routers and other systems to send traffic back against the spoofed source.
2: Silent drop prevents reverse mapping.
In other cases by sending back a "port closed" type message your firewall can be negatively mapped. (e.g Denied 1-1024 except 22, 23, 25,...). That is how nmap udp port scan and protocol scan work. They basically assume a port or protocol is open unless they get a message stating its closed.
3: Silent drop might not be effective, as a reject might never reach the intended target.
With the recently discovered blind TCP resets via forged icmp errors the rfc's governing some of these reactions will probably be changed. Gont the author of the vulnerability suggested a larger amount of the original packet be returned with the icmp error packet. In the mean time one of the primary mitigations for this issue is to ignore the first few icmp errors that could cause a reset. Many networks blocked some incoming icmp error messeges as a result of that vulnerability.
I personally require silent drop (no icmp, no TCP resets) as a standard feature from firewalls and other filtering devices.
The jury is still out on the "correct" thing to do but if a firewall or filtering devices doesn't support silent drop I would not buy it or recommend it. It should be an option the end user can choose.
Additional comments were contributed by fellow handler Swa Frantzen and Johannes Ulrich respectively
"I try to build "drop" to the "bad" side and reject to the "good" side. Good
and bad might not always be in and outside. I permit the
network admin stations to initiate traceroute and icmp echoes,
in order to not have the reaction "it's the firewall" all over the place when the firewall is working as intended."
Swa
One reason to have internal reject rules that prevent systems from 'calling out' but send correct error report: is rejects make it easier to debug issues. In these cases its more about mistakes then malicious users.
Johannes
donald.smith
Keywords:
0 comment(s)
Phishing: Saudi style
On a very slow day the majority of the messages that reached us were about phishing. It consisted of the usual phishing for ebay, amazon, ... accounts, but one jumped up that was somewhat unusual:
Suliman brought a phishing attempt to our attention that was written in Arab aiming at a bank out there and diverting the clicks to http://www_sambaonlineaccess_com/ instead of the bank's http://www.samba.com/ normal address. According to the submitter -I can't read Arab- it was linked to an online registration of a large IPO for a chemical company.
Aside of the IPO relation, it was also noteworthy because of the language used (Arab) and of the location of the server where the clicks were directed to: Israel. I cannot help to note that at the very least this is quite provocative.
The website supposedly collecting the information wasn't responding at time I tried to look at it, which might be a good sign after all.
The lesson for the end users remains the same: never follow links you get in email. If possible turn off the rendering of HTML for email, it's a serious risk from a security perspective.
The warning for those of us fighting abuse is also clear.
--
Swa Frantzen
Suliman brought a phishing attempt to our attention that was written in Arab aiming at a bank out there and diverting the clicks to http://www_sambaonlineaccess_com/ instead of the bank's http://www.samba.com/ normal address. According to the submitter -I can't read Arab- it was linked to an online registration of a large IPO for a chemical company.
Aside of the IPO relation, it was also noteworthy because of the language used (Arab) and of the location of the server where the clicks were directed to: Israel. I cannot help to note that at the very least this is quite provocative.
The website supposedly collecting the information wasn't responding at time I tried to look at it, which might be a good sign after all.
The lesson for the end users remains the same: never follow links you get in email. If possible turn off the rendering of HTML for email, it's a serious risk from a security perspective.
The warning for those of us fighting abuse is also clear.
- Some attacks might aim at very shortlived events.
- You won't be able to understand it all, so you will have to make sure you have processes in place that can deal with language in abuse complaints you can't understand yourself.
--
Swa Frantzen
Keywords:
0 comment(s)
Evolutions in the honeypot/honeynet arena
Over the past days we have received some interesting links on the collection of malware using new variations on the honeypot theme.
Traditionally a honeypot was a (somewhat) vulnerable system that you let get infected in order to learn something form it. This newer breed is more an an automated system to catch malware without getting the system infected.
mwcollect (http://www.mwcollect.org/) is an automated downloader of malware. Georg Wicherski, mwcollect head developer, sent us some collected samples of his setup and I must say I'm still impressed by the number of collections he's sent us then.
Along the same lines is nepenthes (http://nepenthes.sourceforge.net/) a system that emulates known vulnerabilities in order to catch the exploits thrown at it.
Fellow handler Daniel Wesemann suggested a look at the Argos system, (http://www.few.vu.nl/~porto/argos/), designed to detect arbitrary control flow and arbitrary code execution attacks. It is build on top of QEMU for the emulation of x86 processors. I have one big gripe about the approach and that is the comment in the FAQ of QEMU (quoting):
Q: "I want to set up a honeypot. Can I use QEMU for that purpose ?"
A: "It is possible, but the QEMU code has not been reviewed for security issues."
With recent vulnerabilities in the commonly used vmware and the trend of malware detecting vmware and debugging, great care is needed to the quality and security of these tools. So my suggestion would be to carefully inspect the source code of any of these before deciding to deploy it, even for a test run.
There are for sure more efforts in this arena, I'm just summarizing what we received recently.
As always, use these systems at your own risk.
Collecting all these samples is however just the first step. Somebody needs to analyze it and with the increase of malware that race might be tough on some. See also Kevin Liston's on Dasher article.
--
Swa Frantzen
Traditionally a honeypot was a (somewhat) vulnerable system that you let get infected in order to learn something form it. This newer breed is more an an automated system to catch malware without getting the system infected.
mwcollect (http://www.mwcollect.org/) is an automated downloader of malware. Georg Wicherski, mwcollect head developer, sent us some collected samples of his setup and I must say I'm still impressed by the number of collections he's sent us then.
Along the same lines is nepenthes (http://nepenthes.sourceforge.net/) a system that emulates known vulnerabilities in order to catch the exploits thrown at it.
Fellow handler Daniel Wesemann suggested a look at the Argos system, (http://www.few.vu.nl/~porto/argos/), designed to detect arbitrary control flow and arbitrary code execution attacks. It is build on top of QEMU for the emulation of x86 processors. I have one big gripe about the approach and that is the comment in the FAQ of QEMU (quoting):
Q: "I want to set up a honeypot. Can I use QEMU for that purpose ?"
A: "It is possible, but the QEMU code has not been reviewed for security issues."
With recent vulnerabilities in the commonly used vmware and the trend of malware detecting vmware and debugging, great care is needed to the quality and security of these tools. So my suggestion would be to carefully inspect the source code of any of these before deciding to deploy it, even for a test run.
There are for sure more efforts in this arena, I'm just summarizing what we received recently.
As always, use these systems at your own risk.
Collecting all these samples is however just the first step. Somebody needs to analyze it and with the increase of malware that race might be tough on some. See also Kevin Liston's on Dasher article.
--
Swa Frantzen
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments