how to keep nimda and code red from filling apache logs
Hi all, here's a bit of a step-by-step description on how to keep nimda and codered from filling your apache logs. Parts used: - SuSE 7.2 Professional - SuSEfirewall2 - iptables 1.2.3 - linux kernel 2.4.13-pre5 steps: 1. install kernel sources for a kernel >> 2.4.9, running 2.4.13- pre5 here, works fine so far 2. get the sources for iptables 1.2.3 from http://netfilter.samba.org 3. unpack sources somewhere 4. export KERNEL_DIR=$(where you put the kernel tree) 5. cd into unpacked iptables sources, there's a subdirectory named patch-o-matic there 6. apply wanted patches by running ./runme $(name.of.patch)patch for this here You'll want the string patch You can also apply other patches, like the irc-conntrack patch 7. now there's a little bug in this patch... here's a diff: --- linux/net/ipv4/netfilter/ipt_string.c~ Sun Oct 21 00:16:29 2001 +++ linux/net/ipv4/netfilter/ipt_string.c Sun Oct 21 16:54:45 2001 @@ -62,7 +62,7 @@ sk = skip[haystack[right_end - i]]; sh = shift[i]; - right_end = max(int, right_end - i + sk, right_end + sh); + right_end = max(right_end - i + sk, right_end + sh); } return NULL; 8. now, make config/menuconfig/xconfig... as usual. You can import your running kernel's config first. 9. enable the experimental stuff 10. go to networking options->netfilter, there's an option there to enable string matching; set that to M 11. compile and install kernel as usual; remember to uncomment the export INSTALL_PATH=/boot in the main makefile. 12. now build a rpm file for the new iptables stuff by installing the source rpm which comes with suse, then edit the spec file, put the iptables source in /usr/src/packages/SOURCE and rebuild. 13. now there are some small changes to the firewall config files. a) uncomment the last line in /etc/rc.config.d/firewall2.rc.config: FW_CUSTOMRULES="/etc/rc.config.d/firewall2-custom.rc.config" b) edit that file, I got the following stuff in mine: for forbidden_string in root.exe cmd.exe .ida; do iptables -I input_ext -p tcp --dport http -m string \ --string $forbidden_string -m state \ --state ESTABLISHED -j REJECT --reject-with tcp-reset done put that in the last supfunction defined in the custom rc file. c) change the FW_LOG setting in firewall2.rc.config from reading -log-level warning to -log-level kernel.warning 14. last: some small changes to /sbin/SuSEfirewall2 search in the script for the parts where the modules are loaded and unloaded; be sure to add ipt_string (and the other new modules you created by patching the kernel and enabling them in make config) to the modules loading/unloading code there. 15. reboot 16. if you try now to access (from outside, of course) one of the nimda or codered URLS, all you get is a 'connection reset by peer', and the request doesn't show in apache log files. btw, no guarantees, and the usual YMMV :) bye [L]
Hi Mathias! On Sun, 21 Oct 2001, Mathias Homann wrote:
Hi all,
here's a bit of a step-by-step description on how to keep nimda and codered from filling your apache logs.
If filled up logs is the only concern (and not possible vulnerable machines behind firewall) why not: SetEnvIf Request_URI ".ida" no_log=1 SetEnvIf Request_URI ".exe" no_log=1 # add more matches here CustomLog /path/to/logs common env=!no_log that way you avoid matching all the packets to 80 to be matched against the signatures. ciao -- teodor
In article <20011022123933.B8376@gecadsoftware.com>, teo@gecadsoftware.com says...
Hi Mathias! On Sun, 21 Oct 2001, Mathias Homann wrote:
Hi all,
here's a bit of a step-by-step description on how to keep nimda and codered from filling your apache logs.
If filled up logs is the only concern (and not possible vulnerable machines behind firewall) why not: SetEnvIf Request_URI ".ida" no_log=1 SetEnvIf Request_URI ".exe" no_log=1 # add more matches here CustomLog /path/to/logs common env=!no_log
that way you avoid matching all the packets to 80 to be matched against the signatures.
Because I can :) or better, because I avoid a) load on webserver and b) traffic this way... mainly, someone here mentioned the string filtering in netfilter some time ago, and I wanted to try it. after getting it to work, I figured it to be of general interest here. bye [L]
Can you do the same with ipchains and SuSEfirewall1? If so, would you have an example? Thanks in advance. Alex ----- Original Message ----- From: "Mathias Homann" <admin@eregion.de> Newsgroups: eregion.lists.suse.security To: <suse-security@suse.com> Sent: Sunday, October 21, 2001 10:45 AM Subject: [suse-security] how to keep nimda and code red from filling apache logs
Hi all,
here's a bit of a step-by-step description on how to keep nimda and codered from filling your apache logs.
Parts used:
- SuSE 7.2 Professional - SuSEfirewall2 - iptables 1.2.3 - linux kernel 2.4.13-pre5
steps:
1. install kernel sources for a kernel >> 2.4.9, running 2.4.13- pre5 here, works fine so far
2. get the sources for iptables 1.2.3 from http://netfilter.samba.org
3. unpack sources somewhere
4. export KERNEL_DIR=$(where you put the kernel tree)
5. cd into unpacked iptables sources, there's a subdirectory named patch-o-matic there
6. apply wanted patches by running ./runme $(name.of.patch)patch for this here You'll want the string patch You can also apply other patches, like the irc-conntrack patch
7. now there's a little bug in this patch... here's a diff: --- linux/net/ipv4/netfilter/ipt_string.c~ Sun Oct 21 00:16:29 2001 +++ linux/net/ipv4/netfilter/ipt_string.c Sun Oct 21 16:54:45 2001 @@ -62,7 +62,7 @@
sk = skip[haystack[right_end - i]]; sh = shift[i]; - right_end = max(int, right_end - i + sk, right_end + sh); + right_end = max(right_end - i + sk, right_end + sh); }
return NULL;
8. now, make config/menuconfig/xconfig... as usual. You can import your running kernel's config first.
9. enable the experimental stuff
10. go to networking options->netfilter, there's an option there to enable string matching; set that to M
11. compile and install kernel as usual; remember to uncomment the export INSTALL_PATH=/boot in the main makefile.
12. now build a rpm file for the new iptables stuff by installing the source rpm which comes with suse, then edit the spec file, put the iptables source in /usr/src/packages/SOURCE and rebuild.
13. now there are some small changes to the firewall config files. a) uncomment the last line in /etc/rc.config.d/firewall2.rc.config: FW_CUSTOMRULES="/etc/rc.config.d/firewall2-custom.rc.config"
b) edit that file, I got the following stuff in mine:
for forbidden_string in root.exe cmd.exe .ida; do iptables -I input_ext -p tcp --dport http -m string \ --string $forbidden_string -m state \ --state ESTABLISHED -j REJECT --reject-with tcp-reset done
put that in the last supfunction defined in the custom rc file.
c) change the FW_LOG setting in firewall2.rc.config from reading -log-level warning to -log-level kernel.warning
14. last: some small changes to /sbin/SuSEfirewall2 search in the script for the parts where the modules are loaded and unloaded; be sure to add ipt_string (and the other new modules you created by patching the kernel and enabling them in make config) to the modules loading/unloading code there.
15. reboot
16. if you try now to access (from outside, of course) one of the nimda or codered URLS, all you get is a 'connection reset by peer', and the request doesn't show in apache log files.
btw, no guarantees, and the usual YMMV :)
bye [L]
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Hello, recently I have introduced to postfix the mime_header_check with the rule to bounce messages including attachments with executable files based on a suggestion in this list. I have tested that and it seemed to work fine. Nevertheless since Sunday I am receiving (and other users of the server, too) many mails containing the w32.swen.A. It's strange, as this mail contains a file xxxx.exe attached. Is there a way to modify the postfix conffiguration to stop these (and may be similar mails in the future) mails? Seems that this type of attachment bypasses somehow this filtre. I have checked the message, and did not find a difference with otrher types of attachments. Thanks in advance S pozdravem Vaclav Brunnhofer =============================================================== | Entomologicky ustav e-mail: vbru@entu.cas.cz | | Akademie Ved Ceske Republiky tel.: 038 7775251 | | Branisovska 31 fax: 038 5310354 | | 370 05 Ceske Budejovice mobil: +420 606 632822 | ==============================================================
Hi, don't know what's wrong with your postfix, but I'd suggest to install a virus scanner and a mail filter like amavisd-new. Depending on your virus scanner, this offers additional protection against macro viruses, infected zip files and so on. Having exe files filtered out by postfix is still useful to protect against yet unknown mail worms. By, Holger Am Dienstag, 23. September 2003 09:04 schrieb Vaclav Brunnhofer:
Hello,
recently I have introduced to postfix the mime_header_check with the rule to bounce messages including attachments with executable files based on a suggestion in this list. I have tested that and it seemed to work fine. Nevertheless since Sunday I am receiving (and other users of the server, too) many mails containing the w32.swen.A. It's strange, as this mail contains a file xxxx.exe attached. Is there a way to modify the postfix conffiguration to stop these (and may be similar mails in the future) mails? Seems that this type of attachment bypasses somehow this filtre. I have checked the message, and did not find a difference with otrher types of attachments.
Thanks in advance
S pozdravem
Vaclav Brunnhofer
===============================================================
| Entomologicky ustav e-mail: vbru@entu.cas.cz | | Akademie Ved Ceske Republiky tel.: 038 7775251 | | Branisovska 31 fax: 038 5310354 | | 370 05 Ceske Budejovice mobil: +420 606 632822 |
==============================================================
On Tue, 23 Sep 2003, Vaclav made the net somewhat safer by saying:
Hello,
recently I have introduced to postfix the mime_header_check with the rule to bounce messages including attachments with executable files based on a suggestion in this list. I have tested that and it seemed to work fine. Nevertheless since Sunday I am receiving (and other users of the server, too) many mails containing the w32.swen.A. It's strange, as this mail contains a file xxxx.exe attached. Is there a way to modify the postfix conffiguration to stop these (and may be similar mails in the future) mails? Seems that this type of attachment bypasses somehow this filtre. I have checked the message, and did not find a difference with otrher types of attachments.
Check Ralf Hildebrandts site <http://www.stahl.bau.tu-bs.de/~hildeb/postfix/postfix_sobigf.shtml> I'm using simpel headerchecks on the Subject and From myself, plus a message_size_limit of 64kB, which seems effective enough. /^Subject:.*Last Net Pack/ DISCARD Possible virus, don't need it anyway /From:.*(microsoft|ms)\s+(internet|corporation|program|technical|customer|email|network)/ DISCARD Possible virus, don't need it anyway /From:.*(customer|security)\s+(assistance|service|bulletin)/ DISCARD Possible virus, don't need it anyway /From:.*network\s+message/ DISCARD Possible virus, don't need it anyway All pcre. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 27N , 4 29 45E. SuSE 8.2 x86 Kernel k_Athlon 2.4.20-4GB See headers for PGP/GPG info.
On Tue, 2003-09-23 at 09:04, Vaclav Brunnhofer wrote:
recently I have introduced to postfix the mime_header_check with the rule to bounce messages including attachments with executable files based on a suggestion in this list. I have tested that and it seemed to work fine. Nevertheless since Sunday I am receiving (and other users of the server, too) many mails containing the w32.swen.A. It's strange, as this mail contains a file xxxx.exe attached. Is there a way to modify the postfix conffiguration to stop these (and may be similar mails in the future) mails? Seems that this type of attachment bypasses somehow this filtre. I have checked the message, and did not find a difference with otrher types of attachments.
Use the following "body_checks" postfix filters to perform filtering based on the real message body: /^begin\s+\d{3}\s+.+?\.(bat|chm|cmd|cnm|com|exe|hta|jse?|lnk|pif|reg|scr|shb|shs|vb[esx]|vdx|ws[fh])\n?$/ REJECT /^Content-(Disposition|Type):\s+.+?(file)?name="?.+?\.(bat|chm|cmd|cnm|com|exe|hta|jse?|lnk|pif|reg|scr|shb|shs|vb[esx]|vdx|ws[fh])"?\n?$/ REJECT /^\s+(file)?name="?.+?\.(bat|chm|cmd|cnm|com|exe|hta|jse?|lnk|pif|reg|scr|shb|shs|vb[esx]|vdx|ws[fh])"?\n?$/ REJECT This will stop nearly Windows-work-virus-carrying dangerous payload.
participants (7)
-
Alex Levit -
Felipe Alfaro Solana -
Holger Schletz -
Mathias Homann -
Teodor Cimpoesu -
Theo v. Werkhoven -
Vaclav Brunnhofer