[Snort-users] Logging to tcpdump file and d/b

Phil Wood cpw at ...440...
Mon Mar 5 19:28:19 EST 2001


On Tue, Mar 06, 2001 at 10:32:07AM +1300, Steve Hutchins wrote:
> I am running ntp on both the sensor and the acid box, although
> I appreciate how the times can differ fractionally.

I verified I have, at least, a similar problem.  Now, the question is if
there is a mis-match between the acid code creating the sql data 
structures and the data structures on the sql server side.

I just wiped the sql server database off the face of the earth,
re-initialized with the templates found in acid v0.9.6b6 and started
a very recent snort (from cvs).

I'm seeing data.  So far the sql display matches tcpdump of the binary file.

If I see anymore 255 ttls which cannot be, I'll let you know.

PS: 

14:48:36.694508 aa.bb.cc.23 > 134.167.10.43.1485: tcp 19 AP 266685164:266685183(19) ack 253582978 win 32120 <nop,nop,timestamp 191141015 19410197> (DF)
                         aaaa 0300 0000 0800 4500 0047 43fb 4000
                         3e06 e925 aabb cc18 86a7 0a2b 0017 05cd
                         0fe5 4aec 0f1d 5e82 8018 7d78 fe44 0000
                         0101 080a 0b64 9497 0128 2d15 4c6f 6769
                         6e20 696e 636f 7272 6563 740d 0a0d 0a

has a tcp header with an offset of 8.  This packet matches the time,
source ip and port, destination ip and port, and message of the sql (before
I upgraded).  However, the offset in sql is 5 and the ttl is 255.  Where
in the binary file, TTL is 62.  There is no way that this packet could
have a ttl of 255.  Also, an awful lot of fields in the sql tcp were 0.

> 
> The main reason I was looking into the alert, was because I 
> have noticed acid showing quite a few TCP packets with a TTL of 255,
> sequence and ack of zero (from external addresses), which btw, there
> are no packets with a TTL of 255 shown by either snort or tcpdump.
> 
> I have an example of an alert from last night that is reported
> by acid of having a ttl of 255. The alerts are in the acid d/b
> and in the syslog, but not in the binary.
> I have listed the details below:
> 
> ACID
> ============================================================================
> =====
> 
> (Meta)
> ID = 1-1706	TIME=2001-03-05 22:23:38
> Signature=IDS243/http-cgi-pipe
> SENSOR=ids1	INTERFACE=fxp1	FILTER=none
> ALERT GROUP=none
> 
> (IP)
> SOURCE ADDR=202.156.2.243 DEST ADDR=nnn.nnn.nnn.nnn VER=4 Hdr LEN=5 TOS=0
> LENGTH=315 ID=0 FLAGS=0 OFFSET=0 TTL=255 CHKSUM=53012
> FQDN SOURCE NAME=202.156.2.243 DEST NAME=its.a.secret
> OPTIONS=none
> 
> (TCP)
> SOURCE PORT=23958 DEST PORT=80 R1= R0= URG= ACK=X PSH=X RST= SYN= FIN=
> SEQ#=0 ACK=0 OFFSET=5 RES=0 WINDOW=0 URP=0 CHKSUM=44158
> OPTIONS=none
> 
> (PAYLOAD)
> r._,!..J.0.i~......z..Server: 204.152.186.139..Connection:
> Close..Content-Type: application/octet-stream..Content-Length:
> 168........&..oR.B.nB|.?.e.q.4...d<...a^./g...g......e.T-.>.K...jqx,.
> .t.....}O..+.M....".&.A7.%_.`m~....C....7E.....Oq.....6..fU[H.t......>.g....
> ....\..
> 
> SYSLOG (you will notice that there are others in the syslog not in the snort
> dump)
> ============================================================================
> =
> Mar  5 21:42:12 ids1 snort: IDS118/Traceroute ICMP: 216.168.227.250 ->
> its.a.secret
> Mar  5 21:49:52 ids1 snort: IDS118/Traceroute ICMP: 193.0.14.253 ->
> its.a.secret
> Mar  5 22:15:28 ids1 snort: IDS118/Traceroute ICMP: 204.152.184.98 ->
> its.a.secret
> ==>> Mar  5 22:23:38 ids1 snort: IDS243/http-cgi-pipe: 202.156.2.243:23958
> -> its.a.secret:80
> Mar  5 22:23:39 ids1 snort: IDS227/http-cgi-scriptalias: 202.156.2.243:23959
> -> its.a.secret:80
> Mar  5 22:24:17 ids1 snort: IDS227/http-cgi-scriptalias: 202.156.2.243:26278
> -> its.a.secret:80
> Mar  5 22:24:18 ids1 snort: IDS243/http-cgi-pipe: 202.156.2.243:26290 ->
> its.a.secret:80
> Mar  5 22:25:10 ids1 snort: IDS227/http-cgi-scriptalias: 202.156.2.243:29774
> -> its.a.secret:80
> Mar  5 22:25:13 ids1 snort: IDS243/http-cgi-pipe: 202.156.2.243:29952 ->
> 202.6.84.18:80
> Mar  5 22:26:12 ids1 snort: IDS227/http-cgi-scriptalias: 202.156.2.243:33837
> -> 202.6.84.18:80
> Mar  5 22:26:15 ids1 snort: IDS243/http-cgi-pipe: 202.156.2.243:34003 ->
> 202.6.84.18:80
> Mar  5 22:27:40 ids1 snort: IDS171/ping zeros: 192.170.82.3 -> 202.6.84.22
> 
> OUTPUT FROM SNORT OF BINARY FILE (snort -r /var/log/snort-1.7/tcpdump.log
> -Cdev)
> ============================================================================
> ==
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> 
> 03/05-21:42:11.759870 0:2:B9:EE:2C:81 -> 0:D0:B7:56:B:34 type:0x800 len:0x42
> 216.168.227.250 -> 202.6.84.22 ICMP TTL:1 TOS:0x0 ID:26256 IpLen:20
> DgmLen:52
> Type:8  Code:0  ID:60751   Seq:27  ECHO
> ....y.(.....lP.:w5....T.^@
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> 
> 03/05-21:49:52.271108 0:2:B9:EE:2C:81 -> 0:D0:B7:56:B:34 type:0x800 len:0x42
> 193.0.14.253 -> 202.6.84.22 ICMP TTL:1 TOS:0x0 ID:8706 IpLen:20 DgmLen:52
> Type:8  Code:0  ID:63043   Seq:15  ECHO
> .....eEq....9R.:&.....T.^@
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> 
> 03/05-22:15:28.240159 0:2:B9:EE:2C:81 -> 0:D0:B7:56:B:34 type:0x800 len:0x42
> 204.152.184.98 -> 202.6.84.22 ICMP TTL:1 TOS:0x0 ID:44243 IpLen:20 DgmLen:52
> Type:8  Code:0  ID:44960   Seq:16  ECHO
> ......q at ...1485...:6.....T.^@
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> 
> 03/05-22:27:40.488861 0:2:B9:EE:2C:81 -> 0:D0:B7:56:B:34 type:0x800
> len:0x5EA
> 192.170.82.3 -> 202.6.84.22 ICMP TTL:240 TOS:0x0 ID:4097 IpLen:20
> DgmLen:1500 DF
> Type:8  Code:0  ID:39612   Seq:57072  ECHO
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ................................................................
> ^@
> 
> 
> OUTPUT FROM TCPDUMP OF SNORT BINARY 
> ===========================================================================
> I can provide the tcpdump output, but as it's a good size, I haven't
> This also doesn't show the relevant packets.
> 
> Regards
> Steve
> 
> 
> -----Original Message-----
> From: roman at ...438... [mailto:roman at ...438...]
> Sent: Monday, 5 March 2001 11:13 
> To: Steve Hutchins
> Cc: snort-users at lists.sourceforge.net
> Subject: Re: [Snort-users] Logging to tcpdump file and d/b
> 
> 
> (I have not confirmed at the source level, but I suspect the following
> may be happening)
> 
> TCPDump correctly stores the timestamp of a packet.  However, 
> the timestamp generated by the DB-plug-in is actually not
> the absolute time that the packet was read off the wire.  Rather 
> this timestamp reflects when Snort detected/received it.  When 
> Snort is used to read the packets directly off the wire, these two 
> times are potentially off by only several milliseconds.  However,
> when packets are replayed, the latency between the packets being
> on the wire and being read by Snort can be significantly longer.
> Thus, as slaves to the underlying database, analysis tools may 
> be providing skewed results on alert arrival time.
> 
> cheers,
> Roman
> 
> > I have a 1.7 sensor logging to tcpdump, syslog and mysql/acid
> > (I know it's not efficient - it's in test)
> > 
> > In checking through some alerts I replayed the binary file back 
> > through snort and tcpdump,
> > (grepping for the source address seen in acid) it didn't show
> > anything for that address. (I also used vi on the output and
> > paged through looking by date/time)
> > 
> > So, I see the alert in syslog and acid with same date/time but
> > not in the binary file.
> > The binary file has plenty of entries for the last several days.
> > 
> > Any ideas?
> > 
> > Steve
> > 
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users at lists.sourceforge.net
> > Go to this URL to change user options or unsubscribe:
> > http://lists.sourceforge.net/lists/listinfo/snort-users
> > 
> 
> 
> 
> ---------------------------------------------
> This message was sent using Voicenet WebMail.
>       http://www.voicenet.com/webmail/
> 
> 
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users

-- 
Phil Wood, cpw at ...440...





More information about the Snort-users mailing list