Snort

# This is a template for submitting snort signature descriptions to
# the snort.org website
#
# Ensure that your descriptions are your own
# and not the work of others.  References in the rules themselves
# should be used for linking to other's work.
#
# If you are unsure of some part of a rule, use that as a commentary
# and someone else perhaps will be able to fix it.
#
# $Id$
#
#

Rule:
ICMP Ping SpeedEra
--
Sid:
480
--
Summary:
Benevolent ping used by SpeedEra.net to find closest cache for you.
--
Impact:
Minimal to none, usually not an attack.
--
Detailed Information:
After visiting certain speedera.net sites, you will recieve several pings to
your host.  These pings are sent so that speedera can find the closest cache
to your computer.  This rule was added so that Snort could distinguish the
usually benevolent speerera pings from normal, possibly malevolent pings.
--
Attack Scenarios:
This is not really an attack.  However an attacker could disguise their
pings as speedera pings, but this is unlikely.
--
Ease of Attack:

--
False Positives:
This is usually not an attack.
--
False Negatives:

--
Corrective Action:
None required, unless none of your users have ever visited a site run by
speedera.
--
Contributors:
Drew Hintz ( http://guh.nu )
--
Additional References:
http://www.linuxsecurity.com/articles/firewalls_article-2064.html

Hello,

Does anybody have or know of a sig that will log messages sent out via
hotmail? I've tried to analyze the traffic myself and there is just so much
chatter going on between server and browser that I don't know where to
start... not to mention the fact the the mails seem to be spread across
multiple packets.

All I need is to record the message body of outbound hotmail messages.
Anyone got any ideas? Thanks in advance.


____
dave

plokij


******************************

This e-mail message, including any attachment(s), is intended only for the
use of the individual or entity to which it is addressed and may contain
information that is privileged and/or confidential.  If the reader of this
message is not the intended recipient or the employee or agent responsible
for delivering the communication to the intended recipient, please notify
the sender immediately by telephone or by replying to this message and then
please delete this message from your system.  You are hereby notified that
any use, dissemination, distribution and/or reproduction of this message and
or any attachment(s) by unintended recipients is unauthorized and may be
unlawful. Thank you for your cooperation.

  

Lightship Telecom 
 http://www.lightship.net 

******************************

Dear all,

I recently saw a post from Ian Macdonald that asked for a tool to dump a mysql
data packed into a format that ethereal could decode the payload.

I do not have this but I do have a tool that I put together in Perl that will
allow the snort sig_id and a target ip to be specified and it will show the
packet payloads for that particular payload and ip combo.

You will need to make some modifications to this for it to work, e.g. the
server you wish to connect to, db, user and password info.  The section is
marked in the script.

Your mileage may vary but for those that are interested, here it is:

----------------->8--------------->8--------------->8---------------
#!/usr/bin/perl

use Mysql;

$sig_id = $ARGV[0] || die "Must specify the sig_id";
$tgt_ip = $ARGV[1] || die "Must speificy the target ip";

$switch = $argv[2];
if ($switch =~ /-d/) {
	$print_data = 1;
} else {
	$print_data = 0;
}

$cur_date = `date`;
chomp $cur_date;

$q_sig_data = <<"ENDQUERY";
select	sig_name
from	signature
where	sig_id = $sig_id
ENDQUERY

$q_ids = <<"ENDQUERY";
select	e.sid, 
	e.cid
from	event e,
	iphdr i
where	e.signature = $sig_id
and	e.sid = i.sid
and	e.cid = i.cid
and	inet_ntoa(i.ip_dst) = '$tgt_ip'
ENDQUERY

# Modify below for your database
$server = "your.server";
$db = "snort";
$user = "snort";
$pass = "";
# Modify above for your database

$dbh = Mysql->connect($server, $db, $user, $pass);

#print "Query:\n$q_sig_data\n";
$sth = $dbh->query($q_sig_data);

if ($sth->numrows > 0) {
	@rowdata = $sth->fetchrow;
	$sig_name = $rowdata[0];
}

print "                  Incident Response Snort Payload Trace Report\n";
print "\n";
print "Date: " . $cur_date . "\n";
print "Signature: " . $sig_name . "\n";
print "IP Dest: " . $tgt_ip . "\n";
print "\n";
print "                         --==[ Payload Trace START ]==--\n\n";

#print "Query:\n$q_ids\n";
$sth = $dbh->query($q_ids);

$x = 0;
while (@rowdata = $sth->fetchrow) {
	$sids[$x] = $rowdata[0];
	$cids[$x] = $rowdata[1];
	$x++;
}
$loop_limit = $x - 1;

for ($y = 0 ; $y <= $loop_limit ; $y++) {
	$sid = $sids[$y];
	$cid = $cids[$y];

	$q = <<"ENDQUERY";
select	data_payload,
	timestamp,
	inet_ntoa(ip_src)
from	data d,
	event e,
	iphdr i
where	e.sid = $sid
and	e.cid = $cid
and	d.sid = e.sid
and	d.cid = e.cid
and	d.sid = i.sid
and	d.cid = i.cid
ENDQUERY

	$sth = $dbh->query($q);
	if ($sth->numrows > 0) {
		@rowdata = $sth->fetchrow;
		$data = $rowdata[0];
		$dt = $rowdata[1];
		$from_ip = $rowdata[2];
	
		print $dt . " SID: " . $sid . " CID: " . $cid . 
			" Src: " . $from_ip . " Dest: " . $tgt_ip . "\n";
		if ($print_data) {
			print "Data:\n" . $data . "\n";
		}
#		print "Text:\n";

		$l = length($data);
		for ($x = 0; $x < $l; $x+=2) {
			$piece = substr($data, $x, 2);
			$out = pack "H2", $piece;
			$out =~ tr/\x00//d;
			$out =~ tr/\x01-\x1f/./d;
			$out =~ tr/\x80-\xff/./d;
			printf "%s", $out;
#		printf "%c", $out;
#			if (!(($x/4) % 80)) {
#				printf "\n";
#			}
		}
		print "\n\n";
	}
}

print "                         --==[ Payload Trace END ]==--\n\n";

----------------->8--------------->8--------------->8---------------

Ed Davison

The rule I sent yesterday afternoon is based on a line of the actual
exploit.  I think I used the subject "sig for openssl exploit".
There's also some explanation of how I decided on the content I did.

On Tue, 17 Sep 2002, Tim Bogart wrote:

> Does anybody have a signature for the Linux.Slapper.Worm that is
> based on the actual exploit itself rather than the formation of the
> request?

-- 
Public key #7BBC68D9 at            |                 Shane Williams
http://pgp.mit.edu/                | Systems Administrator UT-GSLIS
=----------------------------------+-------------------------------
All syllogisms contain three lines |        shanew@...
Therefore this is not a syllogism  |   http://www.gslis.utexas.edu/~shanew

For those who want to know more about the SSL/OpenSSL vulnerability:

Have a look at http://www.e-secure-db.us

This is a very complete free online ICT Security Vulnerability database.
It contains over 60,000 items, categorised over 2500 folders, in tree
structure on anything to do with ICT security, vulnerabilities on 
product level, incl. history, security product vulnerabilities, 
product comparisons, and thousands of other subjects.

Specific info on the SSL worm:

Suse folder:

http://www.e-secure-db.us/dscgi/ds.py/View/Collection-229

Although we also make refernece to it in the Apache and modssl folders,
all info on SSL worm is combined in:

SSL/OpenSSL folder:
http://www.e-secure-db.us/dscgi/ds.py/View/Collection-348

In there you find a very complete audittrail on Slapper/SSL worm.
Batch updated up to Sept 16 3 AM New Zealand Time (GMT +12)

Comments (very) welcome.

Best regards,
Arjen de Landgraaf
New Zealand
 http://www.e-secure-it.co.nz

-----Original Message-----
From: Robert Wagner [mailto:rwagner@...]
Sent: Tuesday, 17 September 2002 9:00 a.m.
To: Robert Wagner; Intrusions @ Incidents (E-mail)
Cc: Snort-Sigs (E-mail)
Subject: RE: Apache Scalp distributing ->bugtrac.c UDP DOS tool sig yet?


Is there a SNORT IDS Signature for this yet?

Johannas Ullrich mention this analysis:
ust put up a little advisory for the https / openssl stuff
going on. looks like there are some new and improved exploits
making the round.

http://isc.incidents.org/analysis.html?id=167

I will add to it as we get to analyze the exploit code we have
around so far.



-----Original Message-----
From: Robert Wagner [mailto:rwagner@...]
Sent: Monday, September 16, 2002 3:34 PM
To: Intrusions @ Incidents (E-mail)
Subject: Apache Scalp distributing ->bugtrac.c UDP DOS tool


I found a server with Apache 1.3.22 - .bugtrac.c in the /tmp/ folder - with
apache/apache id/group.

I have the full program, appears to be a UDP DDOS (port 2002)

/***************************************************************************
*  *
*  *           Peer-to-peer UDP Distributed Denial of Service (PUD)
*  *                         by contem@...
*  *
*  *         Virtually connects computers via the udp protocol on the
*  *  specified port.  Uses a newly created peer-to-peer protocol that
*  *  incorperates uses on unstable or dead computers.  The program is
*  *  ran with the parameters of another ip on the virtual network.  If
*  *  running on the first computer, run with the ip 127.0.0.1 or some
*  *  other type of local address.  Ex:
*  *
*  *           Computer A:   ./program 127.0.0.1
*  *           Computer B:   ./program Computer_A
*  *           Computer C:   ./program Computer_A
*  *           Computer D:   ./program Computer_C
*  *
*  *         Any form of that will work.  The linking process works by
*  *  giving each computer the list of avaliable computers, then
*  *  using a technique called broadcast segmentation combined with TCP
*  *  like functionality to insure that another computer on the network
*  *  receives the broadcast packet, segments it again and recreates
*  *  the packet to send to other hosts.  That technique can be used to
*  *  support over 16 million simutaniously connected computers.
*  *
*  *         Thanks to ensane and st for donating shells and test beds
*  *  for this program.  And for the admins who removed me because I
*  *  was testing this program (you know who you are) need to watch
*  *  their backs.
*  *
*  *         I am not responsible for any harm caused by this program!
*  *  I made this program to demonstrate peer-to-peer communication and
*  *  should not be used in real life.  It is an education program that
*  *  should never even be ran at all, nor used in any way, shape or
*  *  form.  It is not the authors fault if it was used for any purposes
*  *  other than educational.
*  *
*
****************************************************************************
/

-----BEGIN PGP SIGNED MESSAGE-----

On Sun, 15 Sep 2002, Brian Caswell wrote:

> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"EXPERIMENTAL WEB-MISC bad HTTP/1.1 request, potentual worm attack"; flow:to_server,established; content:"GET / HTTP/1.1|0a 0d 0a 0d|";  offset:0; depth:18; reference:url,securityresponse.symantec.com/avcenter/security/Content/2002.09.13.html; classtype:web-application-activity; sid:1881; rev:1;)

Wow, you were near right on with that.

Just change the content:"GET / HTTP/1.1|0a 0d 0a 0d|";
to
content:"GET / HTTP/1.1|0d 0a 0d 0a|";

I've checked this and it works.

- -- 
Public key #7BBC68D9 at            |                 Shane Williams
http://pgp.mit.edu/                | Systems Administrator UT-GSLIS
=----------------------------------+-------------------------------
All syllogisms contain three lines |        shanew@...
Therefore this is not a syllogism  |   http://www.gslis.utexas.edu/~shanew

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBPYYLema83yV7vGjZAQHSMgP/abO++Gb24zVVmcZvrosVlMTfjLIrMNsR
i+jb3HVkvD+77yq+KreXiLhGXC93CdkZ8JO3zzAPykQFKowTs5oUkttfpGPJP9pG
ciux+o2F1Mhh0bpc5uD4dkvh2YBDiaP+s9UwgHgBHUF64eBdW7bgm92S+xYMrz3d
mnOc4vWaUIw=
=Bnul
-----END PGP SIGNATURE-----

Well, lucky me, I had a compromise this morning, so I've got packet
capture of the attack.

I ran my network log through my rule tester, and the sig as currently
written didn't seem to get detected.

I'll try to pass on some dump files later.

On Sat, 14 Sep 2002, Brian Coyle wrote:

> Based on the CERT advisory for the OpenSSL probing, I slapped this
> rule together:
> 
> 
> 
> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"OpenSSL worm \
> probe"; flags:A+; content:"GET /mod_ssl\:error\:HTTP-request HTTP/1.0"; \
> nocase; sid:9999999; classtype:web-application-attack; rev:1; \
> reference:url,www.cert.org/advisories/CA-2002-27.html;)
> 
> 
> 
> ENJOY!
> 
> 
> 

-- 
Public key #7BBC68D9 at            |                 Shane Williams
http://pgp.mit.edu/                | Systems Administrator UT-GSLIS
=----------------------------------+-------------------------------
All syllogisms contain three lines |        shanew@...
Therefore this is not a syllogism  |   http://www.gslis.utexas.edu/~shanew

In Reference to this thread.
I found source code on dammit.lt 
The code appears to point to PORT 2001 not 2002.    Open source search came
with the same info in the CERT advisory.    The web site dammit.lt claims to
have gotten the source fresh off the honey pot.
Can anyone confirm via source code or traffic? (Cringing at making a
signature based off such an easily changed variable)
Thanks,
Rob Floodeen

Seeing packets from numerous sources to addresses inside my 
network.  Several hundred per hour.  UDP 137.  Non used addresses.

isc.sans.org show charted data with a huge spike last Friday:

http://isc.incidents.org/port_details.html?port=137



8F 6A 00 00 00 01 00 00 00 00 00 00 20 43 4B 41
41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21
00 01


.j.......... CKA    
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAA..!


-  NETBIOS nameservice request  -  UDP   193.128.182.100:137
xxx.209.130.x:137  Outside_1    3:40 PM - 9/30  
-  NETBIOS nameservice request  -  UDP   193.128.182.100:137
xxx.209.130.x:137  Outside_1    3:40 PM - 9/30  
-  NETBIOS nameservice request  -  UDP   209.217.80.174:137
xxx.209.130.x:137  Outside_1    3:40 PM - 9/30  
-  NETBIOS nameservice request  -  UDP   208.51.79.71:137  xxx.209.130.x.137
Outside_1    3:39 PM - 9/30  
-  NETBIOS nameservice request  -  UDP   208.51.79.71:137  xxx.209.130.x:137
Outside_1    3:39 PM - 9/30  
-  NETBIOS nameservice request  -  UDP   208.51.79.71:137  xxx.209.130.x:137
Outside_1    3:39 PM - 9/30  
-  NETBIOS nameservice request  -  UDP   63.86.69.218:1164
xxx.209.130.x:137  Outside_1    3:38 PM - 9/30  
-  NETBIOS nameservice request  -  UDP   63.86.69.218:1164
xxx.209.130.x:137  Outside_1    3:38 PM - 9/30  
-  NETBIOS nameservice request  -  UDP   64.242.54.54:137  xxx.209.130.x:137
Outside_1    3:37 PM - 9/30  
-  NETBIOS nameservice request  -  UDP   64.242.54.54:137  xxx.209.130.x:137
Outside_1    3:37 PM - 9/30  
-  NETBIOS nameservice request  -  UDP   63.86.69.218:1164
xxx.209.130.x:137  Outside_1    3:37 PM - 9/30
 





What do you suppose is up?



Gregory Noller
Senior IT Security Technologist
Technology Risk Services
Koch Business Solutions, LP
Wichita, Kansas
(316) 828-7725

Not sure yet, as far as I'm aware, but have a look at the Incidents list =
archives at SecurityFocus  (and post your info, too).  This has been =
generating a lot of interest over there...

> -----Original Message-----
> From: Noller, Gregory [mailto:Noller2G@...]
> Sent: Monday, September 30, 2002 4:48 PM
> To: snort-sigs@...
> Subject: [Snort-sigs] Need some help here gang....
>=20
>=20
> Seeing packets from numerous sources to addresses inside my=20
> network.  Several hundred per hour.  UDP 137.  Non used addresses.
>=20
> isc.sans.org show charted data with a huge spike last Friday:
>=20
> http://isc.incidents.org/port_details.html?port=3D137
>=20
>=20
>=20
> 8F 6A 00 00 00 01 00 00 00 00 00 00 20 43 4B 41
> 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
> 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21
> 00 01
>=20
>=20
> .j.......... CKA   =20
> AAAAAAAAAAAAAAAA
> AAAAAAAAAAAAA..!
>=20
>=20
> -  NETBIOS nameservice request  -  UDP   193.128.182.100:137
> xxx.209.130.x:137  Outside_1    3:40 PM - 9/30 =20
> -  NETBIOS nameservice request  -  UDP   193.128.182.100:137
> xxx.209.130.x:137  Outside_1    3:40 PM - 9/30 =20
> -  NETBIOS nameservice request  -  UDP   209.217.80.174:137
> xxx.209.130.x:137  Outside_1    3:40 PM - 9/30 =20
> -  NETBIOS nameservice request  -  UDP   208.51.79.71:137 =20
> xxx.209.130.x.137
> Outside_1    3:39 PM - 9/30 =20
> -  NETBIOS nameservice request  -  UDP   208.51.79.71:137 =20
> xxx.209.130.x:137
> Outside_1    3:39 PM - 9/30 =20
> -  NETBIOS nameservice request  -  UDP   208.51.79.71:137 =20
> xxx.209.130.x:137
> Outside_1    3:39 PM - 9/30 =20
> -  NETBIOS nameservice request  -  UDP   63.86.69.218:1164
> xxx.209.130.x:137  Outside_1    3:38 PM - 9/30 =20
> -  NETBIOS nameservice request  -  UDP   63.86.69.218:1164
> xxx.209.130.x:137  Outside_1    3:38 PM - 9/30 =20
> -  NETBIOS nameservice request  -  UDP   64.242.54.54:137 =20
> xxx.209.130.x:137
> Outside_1    3:37 PM - 9/30 =20
> -  NETBIOS nameservice request  -  UDP   64.242.54.54:137 =20
> xxx.209.130.x:137
> Outside_1    3:37 PM - 9/30 =20
> -  NETBIOS nameservice request  -  UDP   63.86.69.218:1164
> xxx.209.130.x:137  Outside_1    3:37 PM - 9/30
> =20
>=20
>=20
>=20
>=20
>=20
> What do you suppose is up?
>=20
>=20
>=20
> Gregory Noller
> Senior IT Security Technologist
> Technology Risk Services
> Koch Business Solutions, LP
> Wichita, Kansas
> (316) 828-7725
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs@...
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>=20

For sid:306, the two references (reference:bugtraq,1610;
reference:cve,CAN-2000-0766;) should be removed.  The references are for a
vqServer DoS, however this sig just matches on a generic administration
attempt.

A reference could be added to sid:306 to:
http://www.vqsoft.com/vq/server/docs/other/control.html

Cheers,
--
^Drew

http://guh.nu

--Begin PGP Fingerprint--
3C6C F712 0A52 BD33 C518  5798 9014 CA99 2DA0 5E78
--End PGP Fingerprint--

In the sig info database, for sid:630 (synScan), the "False Negatives"
section should be changed to read:
"This signature will not detect recent versions of synScan, such as 1.6a,
because synScan now uses random IP IDs."

my source...
drew@...$ less README
synScan 1.6a [public]

- bugs fixed in named-probe
- set flags of synscan to syn only. winsize random,
  ipid random. identification by from port - to port still possible.
- added scanning for newsservers publicly accessible

psychoid
drew@...$

Cheers,
--
^Drew

http://guh.nu

--Begin PGP Fingerprint--
3C6C F712 0A52 BD33 C518  5798 9014 CA99 2DA0 5E78
--End PGP Fingerprint--

Attached is the pcap file for sid:478 (broadscan)

[root@... broadscan]# tcpdump -X -s 0 -r dump
08:07:34.348865 192.168.216.134 > 192.168.229.8: icmp: echo request
0x0000   4500 0020 1716 0000 ff01 65e6 c0a8 d886        E.........e.....
0x0010   c0a8 e508 0800 f7ff 0000 0000 c0a8 e508        ................
[root@... broadscan]#

--
^Drew

http://guh.nu

--Begin PGP Fingerprint--
3C6C F712 0A52 BD33 C518  5798 9014 CA99 2DA0 5E78
--End PGP Fingerprint--

From the responses it appears I wasn't clear enough.

What I want to do is:
If packet matches IIS Specific rule: Stop - dont alert, log, etc - go to =
next packet

It appears that pass rules are supposed to do that (as long as you use the =
-o flag to cause the pass rules to be evaluated before the alert & log =
rules).

Correct?? =20

Tim Bernhardson
Senior Technical Engineer
Certified Citrix Metaframe Administrator
Certified CyberGuard Administrator
Certified AIX 4.3 System Administrator
Sun-Maid Growers of California
7273 Murray Drive, Ste 18
Stockton, CA 95210

tbernhar@...

>>> "Moyer, Shawn" <SMoyer@...> 09/25/02 03:58PM >>>

Since you may not want to disable an entire set of rules (for example, IIS
rules may be relevant if you use ChiliSoft or mod_asp, and most of the
web-misc rules apply to a lot of stuff) what you probably need to do here =
is
look at the individual rule that fired and rewrite it in local.rules as a
pass rule, ideally just for the one host that triggered it. As an example,
if you had a site that was falsing on CGI-Calendar from web-cgi...

Your alert would be:

[**] [1:882:4] WEB-CGI calendar access [**]
[Classification: Attempted Information Leak] [Priority: 2]
09/25-11:16:30.706611 X.X.X.X:3225 -> 1.1.1.1.1:80
TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:1301
***AP*** Seq: 0xE1EA0848  Ack: 0xEE63BC5  Win: 0x41FA  TcpLen: 20

You would grep for SID in your rules directory:

[root@... snort]# grep sid:882 rules/*
rules/web-cgi.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORT=
S
(msg:"WEB-CGI calendar access";flow:to_server,established;
uricontent:"/calendar"; nocase; classtype:attempted-recon; sid:882;  =
rev:4;)

and then copy the rule into your local.rules, rewritten as a pass for the
specific host that was triggering the rule:

/etc/snort/local.rules:

pass tcp $EXTERNAL_NET any -> X.X.X.X $HTTP_PORTS
(flow:to_server,established; uricontent:"/calendar"; nocase;)

You can remove the SID, msg-type, etc. in the rule b/c these are only
informational when alerting. Alternatively, leave the SID in or add a
comment above the rule in local.rules referencing the SID you disabled =
just
for record-keeping.=20

If this is what you already did previously, there may be some duplicate or
very similar sigs in web-misc that are also in the iis rules.

Anyhoo, the SID is the best way to find what sig is firing. That's what =
it's
for.






--shawn


> -----Original Message-----
> From: Chris Baker [mailto:extremis@...
> Sent: Wednesday, September 25, 2002 12:10
> To: Tim Bernhardson
> Cc: snort-sigs@...
> Subject: Re: [Snort-sigs] Rules question
>=20
>=20
> I'm not sure what rule you see getting triggered, but if you are
> getting WEB-MISC alerts, then its likely due to the web-misc.rules.
>=20
> At least for me:
>=20
> -bash-2.05b# file /var/snort/rules/web-misc.rules
> /var/snort/rules/web-misc.rules: ASCII text
>=20
> -bash-2.05b# grep -i web-misc.rules /var/snort/etc/snort.conf
> include $RULE_PATH/web-misc.rules
>=20
>=20
> On Wed, Sep 25, 2002 at 09:12:39AM -0700, Tim Bernhardson wrote:
> > Delivered-To: extremis@...
> > X-Mailer: Novell GroupWise Internet Agent 5.5.6.1
> > From: "Tim Bernhardson" <TBERNHAR@...>
> > To: <snort-sigs@...>
> > Subject: [Snort-sigs] Rules question
> > Errors-To: snort-sigs-admin@...
> > X-BeenThere: snort-sigs@...
> > X-Mailman-Version: 2.0.9-sf.net
> > Precedence: bulk
> > List-Help:=20
> <mailto:snort-sigs-request@...>
> > List-Post: <mailto:snort-sigs@...>
> > List-Subscribe:=20
> <https://lists.sourceforge.net/lists/listinfo/snort-sigs>,
> > =09
> <mailto:snort-sigs-request@...>
> > List-Id: This is the place to talk about Snort=20
> rules/signatures <snort-sigs.lists.sourceforge.net>
> > List-Unsubscribe:=20
> <https://lists.sourceforge.net/lists/listinfo/snort-sigs>,
> > =09
> <mailto:snort-sigs-request@...>
> > List-Archive:=20
> <http://sourceforge.net/mailarchives/forum.php?forum=3Dsnort-sigs>
> > X-Original-Date: Wed, 25 Sep 2002 09:12:39 -0700
> > Date: Wed, 25 Sep 2002 09:12:39 -0700
> >=20
> > Am I doing this wrong or can't it be done?
> >=20
> > I have no IIS Servers so I don't want to be notified about=20
> IIS Specific attacks, however if I just don't include the=20
> web-iis.rules they show up as WEB-MISC alerts.  I looked=20
> through the docs and the pass rules looked like they would do=20
> it.  I made a copy of web-iis rules, changed alert to msiis=20
> and added the following lines to the file.
> >=20
> > ruletype msiis {
> >    type pass output
> >    output log_null
> > }
> >=20
> > and added the -o flag to the cmd line for snort.
> >=20
> > I am still getting the alerts as WEB-MISC..
> >=20
> > Thanks
> >=20
> > Tim Bernhardson
> > Senior Technical Engineer
> > Certified Citrix Metaframe Administrator
> > Certified CyberGuard Administrator
> > Certified AIX 4.3 System Administrator
> > Sun-Maid Growers of California
> > 7273 Murray Drive, Ste 18
> > Stockton, CA 95210
> >=20
> > tbernhar@...
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf=20
> > _______________________________________________
> > Snort-sigs mailing list
> > Snort-sigs@...
> > https://lists.sourceforge.net/lists/listinfo/snort-sigs=20
>=20