tag:blogger.com,1999:blog-4088979.post8058607654974765302..comments2023-10-16T06:06:25.012-04:00Comments on TaoSecurity Blog: Time Issues in Libpcap TracesRichard Bejtlichhttp://www.blogger.com/profile/13512184196416665417noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-4088979.post-13604917967476202452010-08-03T08:51:38.907-04:002010-08-03T08:51:38.907-04:00I tend to agree with Argent and Anonymous x 2 - Wi...I tend to agree with Argent and Anonymous x 2 - Wireshark showed 15:10:21 because that's the time that the clock on the wall showed when that packet came in.<br /><br />If you want consistent times, switch to UTC. Woe bedtide the analyst who is attempting to make sense of a packet log annotated in local time that covers the hour when the clocks are actually put back - when the same wallclock time happens twice an hour apart...cafnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-15556720519851243762010-08-01T13:15:56.771-04:002010-08-01T13:15:56.771-04:00@Gerald Combs - you do understand that in this cas...@Gerald Combs - you do understand that in this case TShark properly reported the actual "time" of the event in EST when TCPDump failed to do that?? TCPDump did not take EST/EDT changes into account and reported the wrong "time". Richard says that Tcpdump honored the local time zone, but that was actually the wrong thing to do. He said that all tools in the Wireshark suite had the same results - the correct results. So why include this Tcpdump functionality/code into Wireshark?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-30012555469870191692010-07-29T12:48:48.526-04:002010-07-29T12:48:48.526-04:00First of all I want to say that by no means am I a...First of all I want to say that by no means am I an expert in this topic, and I am still learning the capabilities of these tools and how they can be applied in various ways during an analysis.<br /><br />However, I agree with Richard in that there needs to be a standard way of displaying time across these tools. I attended his class this week and it was a little distracting to have to keep in mind how the time format was displayed by each tool, and consequently, have to accommodate for the differences. Not only is it distracting to have to accommodate for the differences, but you also have to know that the problem exists in the first place. Adding a manual, human component like this into the equation can lead to conversion errors which, in turn, could cause the analyst to miss potentially critical information during the analysis.<br /><br />Aside from the obvious consistency issue, IMO, I think that having the tools set to report the time in GMT by default is a good start and would allow for a standard correlation across time zones. In addition to this, I think that the incorporation of a switch that would allow the analyst to specify a particular time zone offset would be advantageous. This would give more flexibility in how we are able to visualize the data. For example, if you had an analysis that included multiple pcap files from multiple time zones, by default they would all show in GMT. However, the analyst would have the option to convert them to the time zone corresponding to the site where the initial event happened, or look at each pcap in the time zone from where it originated. Everyone has their own way of making sense of this type of data, but personally, having the ability to view the timelines it in different ways would be advantageous.Richard Rowlandsonnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-4390304058198851152010-07-28T16:25:04.824-04:002010-07-28T16:25:04.824-04:00All I'm asking for here is a little transparen...All I'm asking for here is a little transparency. My students were very frustrated to see on result in a Wireshark-related tool and another in Tcpdump.Richard Bejtlichhttps://www.blogger.com/profile/13512184196416665417noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-70329230168646316572010-07-28T13:23:05.140-04:002010-07-28T13:23:05.140-04:00Thinking about the Clifford Stoll review recently,...Thinking about the Clifford Stoll review recently, and watching the doc on youtube, Stoll was perplexed why the activity was right around lunchtime (12 noon). Why would the hacker choose the busiest time, when people might observe the user? Then he realized the hacker was from Germany and it made sense, because it was evening in Germany.<br /><br />I'd agree with the comments above, I'd want the raw date, perhaps that's not a bug, it's a feature. Although it does make me think, because this is a daylight savings issue, that this is an unpatched system possibly, and it's not adjusting? Just a thought - there was a Java patch for dst some years back..Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-15992834568859036962010-07-28T13:20:39.824-04:002010-07-28T13:20:39.824-04:00If I understand the tcpdump sources correctly, the...If I understand the tcpdump sources correctly, the "-tttt" flag shifts the time zone offset according to the <i>current</i> time. That is, if you run "tcpdump -n -tttt -r icmp.sample.pcap" on November 6 and November 7 this year you'll get different results. We can certainly add this functionality to Wireshark but I have a feeling it wouldn't be received very well.Gerald Combshttp://www.wireshark.org/noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-14206356098068081252010-07-28T12:09:10.510-04:002010-07-28T12:09:10.510-04:00Like anon, I agree with Argent. If you are doing t...Like anon, I agree with Argent. If you are doing time correlation across multiple logs, correlating with physical events, I would prefer the actual time of the event rather than one adjusted for current time of the current OSAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-9052696395287232032010-07-28T11:15:28.418-04:002010-07-28T11:15:28.418-04:00I agree with Argent. The timestamp of your sample...I agree with Argent. The timestamp of your sample ICMP packet was created during standard time, not daylight saving time. Tshark is doing the right thing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-61865343681067430292010-07-28T09:29:57.672-04:002010-07-28T09:29:57.672-04:00I'm wondering if the EST/EDT bit is based on t...I'm wondering if the EST/EDT bit is based on the date of the timestamp, rather than using the date which is currently in effect. e.g. if you have a packet capture from 18 July and you look at it in December, I'm guessing you'll see the opposite behaviour.<br /><br />Working in GMT avoids any interesting time-zone related problems, (for example, in a capture crossing a DST boundary, time can move backwards or leap forwards) but loses some of the context.<br /><br />For example, in this case, the packet arrived at 3:10PM in the eastern time zone. Using local time zone, it may be easier to correspond with some other events (e.g. going out for afternoon coffee or the like). For certain types of attacks, these sorts of correlations can be quite interesting.<br /><br />Anyway, I'd argue that tshark, date, etc are doing the correct timezone parsing, as EDT does not exist anywhere in the world during the winter months.Argenthttps://www.blogger.com/profile/07908845315588176801noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-9190180661259114242010-07-28T01:43:07.558-04:002010-07-28T01:43:07.558-04:00Work entirely in GMT. Come up with tools to conve...Work entirely in GMT. Come up with tools to convert logs to GMT. Move all the timeline entries to GMT.<br /><br />As an added benefit when (sadly more like if) affected companies and/or groups interoperate they can quickly share timelines and immediately compare them rather than have knowledge of local daylight savings time rules, etc.Anonymoushttps://www.blogger.com/profile/13319245813038702157noreply@blogger.com