hello, I tried to activate blocking of nimda files (*.eml) via squid. but squid did not block any elm-file. I tested it with squid coming qith suse 6.3 and with the newest swuid from suse for suse 7.0. the same config file works with the current squid on a freebsd box, and I heard that squid also works on some debian boxes. cu, Tilo
On Wed, Sep 19, 2001 at 06:50:58PM +0200, Tilo Riemer wrote:
hello,
I tried to activate blocking of nimda files (*.eml) via squid. but squid did not block any elm-file. I tested it with squid coming qith suse 6.3 and with the newest swuid from suse for suse 7.0. the same config file works with the current squid on a freebsd box, and I heard that squid also works on some debian boxes.
AFAIK it's important to insert the deny-line for the worm *before* the allow-line for your clients, e.g.: acl nimda [...] acl clients [...] http_access deny nimda http_access allow clients hth
cu, Tilo -- Mit freundlichen Gruessen / Yours sincerely
Wolfram Schlich * E-Mail: wolfram@schlich.org * ICQ: UIN 35713642 Postal: Berghof, D-56626 Andernach-Kell * Phone: +49-(0)2636-941194
Wolfram Schlich wrote:
AFAIK it's important to insert the deny-line for the worm *before* the allow-line for your clients, e.g.: it isn't ...
# nimda wrum acl nimda urlpath_regex -i \.eml$ acl nimda urlpath_regex -i \.nws$ http_access deny nimda look at the second one, another way for the worm (news instead of mail)... HTH -- intraDAT AG http://www.intradat.com Wilhelm-Leuschner-Strasse 7 Tel: +49 69-25629-0 D - 60329 Frankfurt am Main Fax: +49 69-25629-256
Wolfram Schlich wrote:
AFAIK it's important to insert the deny-line for the worm *before* the allow-line for your clients, e.g.: it isn't ...
It's very important to put the deny-line before the allow-line. I've tested it with denying .gif and it only worked having the order first deny and then allow.
# nimda wrum acl nimda urlpath_regex -i \.eml$ acl nimda urlpath_regex -i \.nws$ http_access deny nimda
look at the second one, another way for the worm (news instead of mail)...
HTH
-- intraDAT AG http://www.intradat.com Wilhelm-Leuschner-Strasse 7 Tel: +49 69-25629-0 D - 60329 Frankfurt am Main Fax: +49 69-25629-256
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Michael Schorr System-Administration, soft-gate gmbh
It's very important to put the deny-line before the allow-line. I've tested it with denying .gif and it only worked having the order first deny and then allow.
Of course, first rule it hits that matches it applies. Ditto for most systems. Some systems like IPF OTOH runs packets through all rules and whatever the last action on the packet was is taken. Not to many ways to skin the proverbial cat. Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
On Thu, 20 Sep 2001, Kurt Seifried wrote:
Of course, first rule it hits that matches it applies. Ditto for most systems. Some systems like IPF OTOH runs packets through all rules and whatever the last action on the packet was is taken. Not to many ways to skin the proverbial cat.
Heya Kurt, Hope all is well. FWIW: You can use "quick" with IPF to force the packet end at that rule. Section 2.3: http://www.obfuscation.org/ipf/ipf-howto.txt Cheers, -- ..Yashy <curiosity> I can't wait til' we can directly interface to the brain - that way the voices in my head can talk on IRC.
Heya Kurt,
Hope all is well. FWIW: You can use "quick" with IPF to force the packet end at that rule. Section 2.3: http://www.obfuscation.org/ipf/ipf-howto.txt
Yes, I know, I wrote an article or two on IPF way back when =). My point was logically there are only so many ways to parse rules (and since squid ACL's do NOT have a "quick" keyword or equiv.....). BTW one quick hint: lump acl's together, so if you have: acl deny-ads dstdomain .ads.tucows.com acl deny-ads dstdomain .tucows.com you will get a warning when restarting squid that they overlap, thus making it easy to squirrel out duplicate rules/overlaps.
Cheers,
Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
participants (6)
-
Kurt Seifried -
Michael Schorr -
Sven Michels -
Tilo Riemer -
Wolfram Schlich -
Yasholomew Yashinski