I have some firewall logs (UFW/kern/syslog entries). Is there a way to import this data to Wireshark for some analysis/pictorial representation? asked 09 Aug '14, 17:27  ColinJDenman |
2 Answers:
Short answer is that Wireshark analyses packets, not logs. However, if you set up your Linux system as a syslog client and capture the UDP stream containing the syslog entries as packets, in concept that would contain them in a packet capture file that could be loaded into Wireshark. What exactly are you looking to graph or get pictorial representations for? It's unlikely Wirrshark can do much more with the log files than awk/sed/grep or vi can for most practical purposes. answered 10 Aug '14, 03:54  Quadratic edited 10 Aug '14, 03:55 |
I think I know where the confusion, regarding the import of log files into Wireshark, might have come from... You said:
You might have thought that BSD pf logs are real text log files, but they are in fact pcap files, created by the pflog feature of OpenBSD The BSD pf log capture files can be opened with Wireshark, as they are actually pcap files. Wireshark is not able to do what you are requesting, as it's a network analysis/troubleshooting tool, not a log analysis tool. If you desperately need that feature, here are your options:
However, importing text based (firewall)logs, won't get you very far, as they contain by far not enough information to make Wireshark useful in any way. On Windows, the following tool could be a possible solution for you: Wallwatcher On Linux, one of the following iptables analysis tools, might be useful.
Regards answered 10 Aug '14, 09:28  Kurt Knochner ♦ |
Thanks, I'd figured wireshark was the best tool for the job, and the data in the logs is sufficiently related to get useful info from.
I've recently switched ISP and want to see the traffic flow over time. The log is 1.8GB, a capture file would be even bigger.
I thought it might be possible to generate connection graphs of various kinds to understand the traffic coming in (like intrusion stuff).
I though it might be possible since one of the import formats is BSD pf logfiles (presumably not raw packet dumps), so I figured there would be something available for linux standard firewall logging.
Wireshark seems an obvious choice for this kind of analysis.
Why do you think that? Wireshark is a network analysis/troubleshooting tool , not a log analysis tool !??!
No need for hysteria. The source format is unusual but not radically different from capture, just much less detailed. Why wouldn't one want wireshark to do more than it does. Is the supported BSD pf input radically different from a normal logfile? In the end its all network traffic data. A capture file is just a compact logfile presumably, is it so much different to parse.
No hysteria at all, at least not on my side.
I don't think so.
Can you please describe why you believe that a capture file is similar to a BSD pf log file?
erm, let me think about that..... Nope!
That's actually a very good idea. Please implement that feature and submit the patches for the benefit of all Wireshark users.
You can use TFShark as a starting point:
What exactly do these log files contain? Counts of bytes and a directional context? If so, a one-liner AWK script would probably be enough to do what you want. Another option is to use tools designed to graph network usage, like NetFlow analyzers.
Wireshark can meet the basic requirement of monitoring and graphing network usage over time, though as you're talking about potentially huge amounts of data that becomes less and less practical. A simpler tshark-based statistics script might serve your purpose.
One example I did for a network was to set up dumpcap to do hourly packet captures, then run tshark -Z against those hourly captures to generate packet/byte counts of all sorts of different traffic types (limited only by Wireshark's supported display filter matching), which I piped to an excel file before deleting the packet capture file I'd gathered the stats from. In that case they wanted all kinds of different metrics out of the packet capture file but a lump sum of bytes is easily done by this method also. By this method you never have more than one time interval worth of packet data (to save on disk space) you're using dumpcap except for the statistics query (to save significantly on memory), and the only piece that hits the CPU to any real degree is the one stats grab on the hour (or you could offset it if the CPU is busy on the hour for other hourly things).