LOGS: GIAC GCIA Version 3.5 Practical Detect DarinMarais
"lola marais" <[email protected]>
| Newsgroups | gmane.comp.security.intrusions |
|---|---|
| Message-ID | <[email protected]> |
this a detect for 3.5. please could you take a look and post any questions
2. Detect Invalid HTTP Version String
1. Source of Trace:
The binary log file was downloaded from the GIAC practical logs. The binary
contains some bad check sums. This is because the real IP addresses have
been changed. This fact has been pointed out by many of my peers that have
gone before me.
http://isc.sans.org/logs/Raw/2002.9.10
All of the files that have been captured from at the above location appear
to contain only the packet that has triggered the alert. This means that
when the raw data is replayed to the snort process, a TCP signature that
would normally require a TCP established connection (TCP 3-whs) in order for
the detection to trigger an alert would not be detected for the replay of
that data. In order to overcome the problem, I have disabled the Stateful
detection process in the snort.conf file to relax the requirements for a
signature to trigger.
The following text has been taken directly from the snort.conf file at the
workstation in order to show the lines that are removed.
# stream4: stateful inspection/stream reassembly for Snort
#----------------------------------------------------------------------
# Use in concert with the -z [all|est] command line switch to defeat
stick/snot
# against TCP rules. Also performs full TCP stream reassembly, stateful
# inspection of TCP streams, etc. Can statefully detect various portscan
# types, fingerprinting, ECN, etc.
# preprocessor stream4: disable_evasion_alerts
# preprocessor stream4_reassemble
The # placed before the command will cause the snort process to skip that
line when the configuration file is called from the snort process.
The following text shows the snort command and the options that where used
in order to generate the alerts.
# snort -c ./rules/snort.conf -l ./detect2/log1/ -r
./GIAC_PRAC/GiacLogs/2002.9.10 -k none -dyev > ./detect2/log1/verbose -q -A
fast -h32.245.0.0/16
USAGE: snort [-options]
Options:
-A Set alert mode: fast, full, console, or none(alert file
alerts only)
"unsock" enables UNIX socket logging (experimental).
-c <rules> Use Rules File <rules>
-d Dump the Application Layer
-e Display the second layer header info
-h <hn> Home network = <hn>
-k <mode> Checksum mode (all,noip,notcp,noudp,noicmp,none)
-l <ld> Log to directory <ld>
-q Quiet. Don't show banner and status report
-r <tf> Read and process tcpdump file <tf>
-v Be verbose
-y Include year in timestamp in the alert and log files
After this command was executed, an alert file was created in the specified
log directory. The file was visually scanned for the detects that where
created and then snortsnarf.pl perl script was run to produce an HTTP file
for easier examination of those alerts.
This alert file contained the following three interesting alert entries.
# grep "Invalid HTTP Version String" ./detect2/log1/alert
10/10/02-06:19:08.026507 [**] [1:2570:6] WEB-MISC Invalid HTTP Version
String [**] [Classification: Detection of a non-standard protocol or event]
[Priority: 2] {TCP} 172.132.195.251:1813 -> 32.245.166.119:80
10/10/02-20:08:36.796507 [**] [1:2570:6] WEB-MISC Invalid HTTP Version
String [**] [Classification: Detection of a non-standard protocol or event]
[Priority: 2] {TCP} 4.63.173.119:4524 -> 32.245.166.119:80
10/10/02-23:42:12.086507 [**] [1:2570:6] WEB-MISC Invalid HTTP Version
String [**] [Classification: Detection of a non-standard protocol or event]
[Priority: 2] {TCP} 208.63.245.166:2989 -> 32.245.166.119:80
10/11/02-01:48:10.976507 [**] [1:2570:6] WEB-MISC Invalid HTTP Version
String [**] [Classification: Detection of a non-standard protocol or event]
[Priority: 2] {TCP} 4.65.196.108:3914 -> 32.245.166.119:80
The following information was deduced from the http output and the text
alert file.
Sources triggering this attack signature
208.63.245.166
4.65.196.108
4.63.173.119
172.132.195.251
Destinations receiving this attack signature
32.245.166.119
In order to discover the network, I have used a series of tcpdump commands.
Most of the tcpdump commands that I have used have been adapted from the
GIAC Certified Intrusion Analyst (GCIA) paper by Peter H. Storm [37].
I would like to thank Mr. Storm for giving me the insight for these
commands. Mr. Storm uses a series of tcpdump commands to discover the
network. I have used similar commands to discover the network that I have
been challenged with.
All of the packets displayed at the console have the following structure.
tcpdump -nner /GIAC_PRAC/GiacLogs/2002.9.10 -c 1
02:00:03.876507 0:3:e3:d9:26:c0 0:0:c:4:b2:33 0800 60: 255.255.255.255.31337
> 32.245.186.142.515: R 0:3(3) ack 0 win 0
This means that the awk variables for the TCP packet are as follows;
Time
Source MAC address
Destination MAC address
Ethernet frame type
packet length
Source IP address and port
Destination IP address and port
flags
Relative Sequence number (nbytes)
Etc.
I have used the command below to discover all of the hardware addresses in
the networks. The command lets us know that there are only two devices on
the local segment. Both of these devices happen to be manufactured by Cisco
systems. I used the tool provided by the IEEE in order to determine the
manufacture of the NIC. [38]
# tcpdump -nner 2002.9.10 | awk '{print $2}' |sort -u
0:0:c:4:b2:33
0:3:e3:d9:26:c0
# tcpdump -nner 2002.9.10 | awk '{print $3}' |sort -u
0:0:c:4:b2:33
0:3:e3:d9:26:c0
00-00-0C (hex) CISCO SYSTEMS, INC. 170 WEST TASMAN DRIVE SAN JOSE CA 95134
00000C (base 16) CISCO SYSTEMS, INC.
00-03-E3 (hex) Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA 95134
0003E3 (base 16) Cisco Systems, Inc.
I used the following command to determine the IP addresses that have
originated from the NIC address 0:0:c:4:b2:33
# tcpdump -nner 2002.9.10 "ether src 0:0:c:4:b2:33" | awk '{print $6}' |awk
-F \. '{print $1"."$2"."$3"."$4}' |sort -u
32.245.166.119
32.245.166.236
I used the following command to determine the source IP addresses of the
packets originating from the NIC 0:3:e3:d9:26:c0. The output of the command
has been truncated in order to conserve space.
# tcpdump -nner 2002.9.10 "ether src 0:3:e3:d9:26:c0" | awk '{print $6}'
|awk -F \. '{print $1"."$2"."$3"."$4}' |sort -u
12.111.47.194
12.145.180.2
130.49.189.232
snip ...
80.5.120.28
80.5.153.244
80.6.250.44
80.67.66.40
I used the following command to determine the destination IP addresses of
the packets originating from the NIC 0:3:e3:d9:26:c0
# tcpdump -nner 2002.9.10 ether src 0:3:e3:d9:26:c0 | awk '{print $8}' |awk
-F \. '{print $1"."$2"."$3"."$4}' |sort -u
32.245.113.30
32.245.113.38
snip ...
32.245.88.213
32.245.99.128
# tcpdump -nner 2002.9.10 ether src 0:3:e3:d9:26:c0 | awk '{print $8}' |awk
-F \. '{print $1"."$2"."$3"."$4}' |sort -u |wc -l
82
I used the following command to determine the destination IP addresses of
the packets originating from the NIC 0:0:c:4:b2:33
# tcpdump -nner 2002.9.10 ether src 0:0:c:4:b2:33 | awk '{print $8}' |awk -F
\. '{print $1"."$2"."$3"."$4}' |sort -u
12.213.27.68
12.219.102.151
12.219.135.64
snip ...
80.35.219.162
81.65.129.9
81.96.106.54
# tcpdump -nner 2002.9.10 ether src 0:0:c:4:b2:33 | awk '{print $8}' |awk -F
\. '{print $1"."$2"."$3"."$4}' |sort -u |wc -l
423
>From the output of these commands we are able to draw the network diagram.
The network according to the data looks as follows.
2. Detect was generated by:
The signature that alerted us and has generated the event in the alert file
was following snort signature.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC
Invalid HTTP Version String"; flow:to_server,established; content:"HTTP/";
isdataat:6,relative; content:!"|0A|"; within:5; reference:bugtraq,9809;
reference:nessus,11593; classtype:non-standard-protocol; sid:2570; rev:6;)
The above signature will look for:
TCP protocol coming from any external IP address. This is a variable and can
be defined in the snort.conf file. My snort configuration file specifies
any. This source IP address can come from any TCP source port.
The following has been extracted from the snort.conf file.
# Set up the external network addresses as well. A good start may be "any"
var EXTERNAL_NET any
That is connected and established (has completed a TCP 3-whs) to any IP
address that is defined as an HTTP server on any defined HTTP port. The
following two parameters are variables that can be changed in the snort.conf
file during the configuration of snort in order to make the detection
process more accurate.
1.$HTTP_SERVERS
2.$HTTP_PORTS
The signature will look for the content HTTP/ in the payload of the packet
and then verify that there are at least 6 bytes after the end of the content
string. It will verify that there is not a newline character within 5 bytes
of the end of the content HTTP/.
The follow description was taken directly from the snort user guide [39] at
the web site in order to help explain the parameter isdataat.
"3.5.9 isdataat
Verify that the payload has data at a specified location, optionally looking
for data relative to the end of the previous content match.
3.5.9.1 Format
isdataat:<int>[,relative];
3.5.9.2 Example
alert tcp any any -> any 111 (content:"PASS"; isdataat:50,relative;
content:!"|0a|"; distance:0;)
This rule looks for the string PASS exists in the packet, and then verifies
there is at least 50 bytes after the end of the string PASS, and then
verifies that there is not a newline character within 50 bytes of the end of
the PASS string."
3.Probability the source address was spoofed:
Since the signature requires a TCP established connection, there is very
little chance that the source address is spoofed. Although when I search the
file for other packets that belong to this connection I was unable to find
any, there must have been a completed connection. IMHO, the snort process
has only captured the trigger packet.
4.Description of attack:
It has been said that upon detecting the signature WEB-MISC Invalid HTTP
Version String the attacker could be attempting to exploit a vulnerability
that exists in a web server running Seattle Lab Software SLMail Pro 2.0 to
2.0.9.
This vulnerability was outlined in the discussion section of these URL
http://www.securityfocus.com/bid/9809/discussion/
http://xforce.iss.net/xforce/xfdb/15399
http://secunia.com/advisories/11048/
The discussion explains that there are two vulnerabilities that exist in
SLMail application. These vulnerabilities where released on 2004-03-05 and
exist in all versions prior to version 2.0.9
A buffer overflow could cause a remote attacker to execute code on the
victims hosts. This is achieved by sending a crafted HTTP string with an
overly long HTTP sub-version.
http://www.faqs.org/rfcs/rfc2616.html
3.1 HTTP Version
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versioning policy is intended to allow
the sender to indicate the format of a message and its capacity for
understanding further HTTP communication.
The second buffer overflow exists in three of the ISAPI Extensions files
included with the web mail component. These files will allow a buffer
overflow to occur and consequently the execution of code that would be run
with the same user privileges of the web server process.
1.user.dll
2.loadpageadmin.dll
3.loadpageuser.dll
However judging by the string that has been received; I am more incline to
believe that the attacker was trying to exploit the vulnerability that
exists in some versions of formmail perl script.
In order to determine if the signature has trigger for the correct reasons,
tcpdump was used to view the hexadecimal values in the payload of the
packet. It is also interesting to point out at this time that the remote
device has a TimeToLive (TTL) of 115. Passive fingerprinting techniques [40]
tell us that it is very possible that the remote device is a windows
operating system
# tcpdump -nnvttttXr ./GIAC_PRAC/GiacLogs/2002.9.10 port 1813
10/10/2002 04:19:08.026507 172.132.195.251.1813 > 32.245.166.119.80: P [bad
tcp cksum e41!] 3263194808:3263195121(313) ack 3337717011 win 5840 (DF) (ttl
115, id 23608, len 353, bad cksum 5d5a!)
0x0000 4500 0161 5c38 4000 7306 5d5a ac84 c3fb E..a\[email protected].]Z....
0x0010 20f5 a677 0715 0050 c280 66b8 c6f1 8513 ...w...P..f.....
0x0020 5018 16d0 aa29 0000 4745 5420 2f63 6769 P....)..GET./cgi
0x0030 2d62 696e 2f46 6f72 6d4d 6169 6c2e 706c -bin/FormMail.pl
0x0040 3f65 6d61 696c 3d53 6b61 6e6e 6564 4061 ?email=Skanned@a
0x0050 6f6c 2e63 6f6d 2673 7562 6a65 6374 3d77 ol.com&subject=w
0x0060 7777 2e58 5858 5858 5858 582f 6367 692d ww.XXXXXXXX/cgi-
0x0070 6269 6e2f 466f 726d 4d61 696c 2e70 6c26 bin/FormMail.pl&
0x0080 7265 6369 7069 656e 743d 7365 6e64 3234 recipient=send24
0x0090 3532 4061 6f6c 2e63 6f6d 266d 7367 3d6d [email protected]&msg=m
0x00a0 6953 6c65 6454 4d20 2532 4563 6f6d 266d iSledTM.%2Ecom&m
0x00b0 7367 3d6d 6953 6c65 6454 4d20 4854 5450 sg=miSledTM.HTTP
0x00c0 2f31 2e31 436f 6e74 656e 742d 5479 7065 /1.1Content-Type
0x00d0 3a20 6170 706c 6963 6174 696f 6e2f 782d :.application/x-
0x00e0 7777 772d 666f 726d 2d75 726c 656e 636f www-form-urlenco
0x00f0 6465 640d 0a55 7365 722d 4167 656e 743a ded..User-Agent:
0x0100 2047 6f7a 696c 6c61 2f34 2e30 2028 636f .Gozilla/4.0.(co
0x0110 6d70 6174 6962 6c65 3b20 4d53 4945 2035 mpatible;.MSIE.5
0x0120 2e35 3b20 7769 6e64 6f77 7320 3230 3030 .5;.windows.2000
0x0130 290d 0a48 6f73 743a 2077 7777 2e58 5858 )..Host:.www.XXX
0x0140 5858 5858 580d 0a43 6f6e 6e65 6374 696f XXXXX..Connectio
0x0150 6e3a 204b 6565 702d 416c 6976 650d 0a0d n:.Keep-Alive...
0x0160 0a .
In order to view the ASCII string in an easier reading format, the command
tcpflow was used to extract the string. The text below shows the packet that
is currently analysed as well as two other alerts that have occurred in the
same raw different source IP addresses.
# tcpflow -cr ./GIAC_PRAC/GiacLogs/2002.9.10 port 1813
172.132.195.251.01813-032.245.166.119.00080: GET
/cgi-bin/[email protected]&subject=www.XXXXXXXX/cgi-bin/FormMail.pl&[email protected]&msg=miSledTM
%2Ecom&msg=miSledTM HTTP/1.1Content-Type: application/x-www-form-urlencoded
User-Agent: Gozilla/4.0 (compatible; MSIE 5.5; windows 2000)
Host: www.XXXXXXXX
Connection: Keep-Alive
# tcpflow -cr ./GIAC_PRAC/GiacLogs/2002.9.10 port 4524
004.063.173.119.04524-032.245.166.119.00080: GET
/cgi-bin/[email protected]&subject=www.XXXXXXXX/cgi-bin/formmail.pl&[email protected]&msg=w00t
0aol%2Ecom&msg=w00t HTTP/1.1Content-Type: application/x-www-form-urlencoded
User-Agent: Gozilla/4.0 (compatible; MSIE 5.5; windows 2000)
Host: www.XXXXXXXX
Connection: Keep-Alive
# tcpflow -cr ./GIAC_PRAC/GiacLogs/2002.9.10 port 2989
208.063.245.166.02989-032.245.166.119.00080: GET
/cgi-bin/[email protected]&subject=www.XXXXXXXX/cgi-bin/FormMail.pl&[email protected]&msg=miSledTM
%2Ecom&msg=miSledTM HTTP/1.1Content-Type: application/x-www-form-urlencoded
User-Agent: Gozilla/4.0 (compatible; MSIE 5.5; windows 2000)
Host: www.XXXXXXXX
Connection: Keep-Alive
The source IP address that was captured in this detect actually triggered
two different signature events. The packet in the raw data file that was
captured on 10/10/2002 at 04:19:08 from the IP address 172.132.195.251
according to the binary file has also triggered an event for WEB-CGI
formmail access
This signature documented in the text directly below has been written to
capture events when an external address is trying to get access to the
formmail script file. The file is normally is located in one of the
subdirectories of a UNIX web server.
The consequences of gain access to the formmail perl script prior to version
1.6 are that it would allow the attacker to execute commands at the web
server with the privileges of the web server process. That signature had the
following structure.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI
formmail access"; flow:to_server,established; uricontent:"/formmail";
nocase; reference:arachnids,226; reference:bugtraq,1187;
reference:bugtraq,2079; reference:cve,1999-0172; reference:cve,2000-0411;
reference:nessus,10076; reference:nessus,10782;
classtype:web-application-activity; sid:884; rev:14;)
A description of this signature could be found at the following URL
location.
http://www.snort.org/snort-db/sid.html?id=884
5.Attack mechanism:
The SLMail attack would normally try to overflow the buffer on the web port
of a SLMail server and consequently the attacker would be able to execute
which ever program that he or she felt like. The character string that
however appear beyond the HTTP/ content string look as if they are part of a
banner to inform the web server.
The RFC was consulted in order to determine what the attacker was trying to
achieve by including the browser banner beyond the http sub-field.
The RFC used was http://www.faqs.org/rfcs/rfc2616.html
The following information was extracted from the RFC.
2.2 Basic Rules
The following rules are used throughout this specification to
describe basic parsing constructs. The US-ASCII coded character set
is defined by ANSI X3.4-1986 [21].
Snip ..
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
Snip ..
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for
tolerant applications). The end-of-line marker within an entity-body
is defined by its associated media type, as described in section 3.7.
CRLF = CR LF
The arguments that appear after the content HTTP/1.1 are not valid in the
HTTP request-line since there is no preceding hexadecimal 0a = decimal 10
which is the equivalent of a LF. That makes this HTTP get string invalid. It
could be that the attacker was trying to craft a packet to hide the banner
of the real browser by hard coding the parameters at the end of the HTTP get
string.
This is strange and is not very common but does not appear to be malicious
from the SLMail vulnerability point of view.
The payload content indicates that it is defiantly an attempt to scan for
vulnerable formmail scripts and this should be cause for concern. The file
capture was searched using tcpdump for a response to this packet with no
joy. This is stimulus packet but the web server does not seam to have
offered any response to the request.
Matt Wright explains the Formmail attack
"The Formmail package has become a favorite tool of spammers.
Formmail allows a website to email form submissions to an email account. If
left unpatched a malicious user can send spam simply by including the list
of target email addresses in an HTTP request to Formmail. This behavior
makes tracking down the origin of the spam difficult because the only place
the spammers IP address is saved is in the Web logs of the affected site.
FormMail is a widely-used web-based e-mail gateway, which allows form-based
input to be emailed to a specified user.
When the form is submitted, the commands will be executed on the host, with
the privileges of the web server process. This might be leveraged by the
attacker to gain local access to the host. [41]"
6.Correlations:
The following links where found for the SLMail attack by searching the
Internet. The links below dont show any time where the vulnerability has
been used in an exploit against a SLMail server.
http://www.securityfocus.com/bid/9809
http://cgi.nessus.org/plugins/dump.php3?id=11593
http://marc.theaimsgroup.com/?l=bugtraq&m=105232506011335&w=2
There are many correlations for the formmail.pl. This attack is used by lots
of spammers. Formmail correlations can be found at URL:
http://cgi.nessus.org/cve.php3?cve=CAN-2000-0411
The remote IP address in this attack was examined against the Dshield
reports. It should be noted that this attack did occur in 2002 according to
the time in the tcpdump packet but the IP address was not list as previously
reported.
IP Address: 172.132.195.251
HostName: AC84C3FB.ipt.aol.com
DShield Profile: Country: US
Contact E-mail: [email protected]
AS Number: 1668
Total Records against IP: not processed
Number of targets: select update below
Date Range: to
request contact update
Update Summary
Whois:
OrgName: America Online
OrgID: AOL
Address: 22000 AOL Way
City: Dulles
StateProv: VA
PostalCode: 20166
Country: US
http://www.dshield.org/ipinfo.php?SANSDSHIELD=72cdedcfaad2851ed63a3925db648883&ip=172.132.195.251&Submit=Submit
The formmail.pl attack is extremely well analysed in Detect #2: Web-CGI
formmail access of the GCIA practical paper submitted by Barbara Morgan.
This complete document can be found at the following URL location on the
Internet.
http://www.giac.org/practical/GCIA/Barbara_Morgan_GCIA.doc
7. Evidence of active targeting:
This attack is received from two other source IP addresses on the same day.
The web server on this network has been targeted. The attack did not appear
in the capture file for any other destination. It can only be assumed that
the web server has been targeted. It seams impossible that if the attack
where a scan for vulnerably systems on this network that only one
destination IP address has been scanned.
8. Severity:
Severity = (criticality + lethality) - (system countermeasures + network
countermeasures)
Critically: Nothing is really known about the local web server but since the
server is located on the internet it can only be assumed that it is used for
some form of business and even if it is not, one should guard against
attacks on this public server. I am going to assume the worst and say that
it is a business web server.
Lethality: If the server where running a vulnerable version of SLMail the
attack would have been unsuccessful. If the web server is using a vulnerable
version of the popular the gateway script formmail.pl to translate
information from the web pages for sending via the email server, the attack
would have mailed the spammer with information regarding the web server
location. The web server could then be used in an attack later on. The email
severs could be used as a spam gateway if vulnerably script is detected by
the spammer.
System countermeasures: Nothing can be determined regarding the patch
program for this web server. The TTL in the response packets tell us that it
is very possible that the operating system is UNIX.
Network countermeasures: The network firewall would have permitted this
attack to pass to the web server. There was no response from the web server
for this session but there have been responses for others sessions. The
packets below show those responses to other IP addresses external to the
network.
# tcpdump -nnvqr ./GIAC_PRAC/GiacLogs/2002.9.10 "src host 32.245.166.119 and
port 80"
02:12:07.466507 32.245.166.119.80 > 212.62.35.225.1168: tcp 536 (DF) (ttl
63, id 672, len 576, bad cksum 6274!)
09:39:24.466507 32.245.166.119.80 > 213.202.69.145.32776: tcp 581 (DF) (ttl
63, id 19980, len 621, bad cksum f39e!)
09:39:28.756507 32.245.166.119.80 > 213.202.69.145.32776: tcp 554 (DF) (ttl
63, id 19999, len 594, bad cksum f3a6!)
10:00:15.336507 32.245.166.119.80 > 213.202.69.145.32855: tcp 581 (DF) (ttl
63, id 30869, len 621, bad cksum c915!)
10:57:56.596507 32.245.166.119.80 > 195.29.132.172.32777: tcp 563 (DF) (ttl
63, id 13339, len 603, bad cksum e133!)
10:58:04.336507 32.245.166.119.80 > 195.29.132.172.32777: tcp 551 (DF) (ttl
63, id 13340, len 591, bad cksum e13e!)
There is an NIDS to detect this attack, so the network staff will be
informed of the possibility of an attack on the mail server if the alerts
are properly analysed and the NIDS is properly tuned.
(4 + 4) - (1 + 3) = 4
In conclusion of this attack and from all of the evidence that has been
collected it could be said that on the 10/10/2002 at 04:19:08 the device
located at IP address 172.132.195.251 and others tried to exploit
vulnerability in the perl script called formmail.pl on the web server
service running at 32.245.166.119. Whilst attempting this exploit
vulnerability in this script, it has triggered the event Invalid HTTP
Version String in parallel.
9. Defensive recommendation:
Check the device running at IP address 32.245.166.119 is not running SLMail.
If it is that apply the recommended Security Patch, which is currently
version 2.0.14 and can be found at
http://www.slmail.com/Products/SLMailPro/Utilities.asp
More especially, check if the device at this location is is running a
vulnerable version of formmail.pl. If it is then the device should be
patched immediately by upgrading the script.
10. Multiple choice test questions:
When writing snort signatures for content matching, the parameter "isdataat"
is used to indicate to the snort process to
a) Hide all email addresses used in the in the signature description.
b) Look for defined conditions, x bytes beyond the previous content string
match
c) Look for defined conditions, x bytes before the previous content string
match
answer = b
_________________________________________________________________
Go beyond Hotmail with MSN Hotmail Plus! http://join.msn.com/?pgmarket=en-xe
_______________________________________________
Intrusions mailing list
[email protected]
http://www.dshield.org/mailman/listinfo/intrusions