1 00:00:00,000 --> 00:00:08,379 2 00:00:08,379 --> 00:00:12,460 Ok, for our next module, we will be getting into flow graphs. 3 00:00:12,459 --> 00:00:16,201 And if you were part of our Q&A session 4 00:00:16,201 --> 00:00:26,513 momentarily, we did a practical, practical application of using a flow graph. 5 00:00:26,513 --> 00:00:32,818 But we will redo one again now and go into more detail about the flow graph. 6 00:00:32,818 --> 00:00:39,782 What the flow graph does is it allows you to look at all conversations in a view 7 00:00:39,782 --> 00:00:43,955 where specifically, if you needed to see communication 8 00:00:43,960 --> 00:00:46,529 from an IP address to an IP address 9 00:00:46,524 --> 00:00:50,349 it will show you packet by packet exactly 10 00:00:50,360 --> 00:00:53,466 what's taking place at every step of the communication. 11 00:00:53,472 --> 00:00:59,319 And if you refined to a TCP flow, it will actually show you 12 00:00:59,313 --> 00:01:03,907 specifically where in the handshake the, each packet is 13 00:01:03,921 --> 00:01:05,921 and that gives you a great picture. 14 00:01:05,934 --> 00:01:11,822 So, let's use an example. Let's say you are going to a website 15 00:01:11,822 --> 00:01:15,873 and that website was performing poorly. 16 00:01:15,873 --> 00:01:20,519 You did not understand why and you're starting to look through your packets, 17 00:01:20,519 --> 00:01:24,255 your data, and you're, and you're, you're starting to come to a loss. 18 00:01:24,255 --> 00:01:28,083 So, one of the things you do is you pull a flow graph on this data. 19 00:01:28,083 --> 00:01:32,229 And you're able to extract the entire conversation 20 00:01:32,229 --> 00:01:34,186 from source to destination 21 00:01:34,186 --> 00:01:39,547 and each packet, what happened in time sequence. 22 00:01:39,547 --> 00:01:47,762 So, what that will show you as an example is if you go through your, your TCP handshake, 23 00:01:47,778 --> 00:01:54,257 and you see a flood of reset packets or you see it consistently 24 00:01:54,259 --> 00:01:58,198 send out duplicate acknowledgements or re-transmitting data. 25 00:01:58,198 --> 00:02:02,688 It's likely that there is some kind of issue taking place 26 00:02:02,720 --> 00:02:04,720 from source to destination. 27 00:02:04,752 --> 00:02:10,179 And what's nice about the flow graph is it gives you that in a picture form. 28 00:02:10,179 --> 00:02:17,620 So that instead of sifting through the data even, even if you use the TCP stream graph, 29 00:02:17,617 --> 00:02:20,340 without siftiing through all that data, 30 00:02:20,331 --> 00:02:24,719 you can very quickly ascertain what could be the problem or what point 31 00:02:24,719 --> 00:02:29,711 this was creating a problem or problematic behavior 32 00:02:29,704 --> 00:02:35,263 or perfomance issue. So, what does it mean? 33 00:02:35,263 --> 00:02:38,460 It doesn't necessarily mean you know where the problem is coming from? 34 00:02:38,460 --> 00:02:41,324 You just know that it's from the source to the destination. 35 00:02:41,324 --> 00:02:44,853 So that's one of the important things to understand about the flow graph. 36 00:02:44,853 --> 00:02:48,138 Just because you see from the source to the destination 37 00:02:48,137 --> 00:02:50,886 doesn't mean you see all t he components in between. 38 00:02:50,919 --> 00:02:54,092 And anything there could be also causing an issue. 39 00:02:54,092 --> 00:03:01,235 A synchronous routing can be a common one where it's impeding the traffic flow. 40 00:03:01,235 --> 00:03:05,796 There could be buffering problems on the target device. 41 00:03:05,796 --> 00:03:13,704 There could be a, a path of reasons why you may be getting this data back but 42 00:03:13,704 --> 00:03:16,893 what this graph will do, the flow graph 43 00:03:16,893 --> 00:03:22,217 will allow you to really see the conversation for what it is - 44 00:03:22,223 --> 00:03:28,446 what it is as you caught it and will start giving you clues as to what could be causing 45 00:03:28,440 --> 00:03:33,039 the issue downstream or at each endpoint. 46 00:03:33,039 --> 00:03:34,940 So why we use the flow graph? 47 00:03:34,940 --> 00:03:39,518 We use it to analyze the capture of filtered data 48 00:03:39,526 --> 00:03:45,317 to extract the flow from a source to destination and view the entire conversation. 49 00:03:45,317 --> 00:03:50,657 We do this so that we can see what may be broken in the conversation 50 00:03:50,656 --> 00:04:01,143 or causing this residual affect of duplicate or I should say re-transmitted data, 51 00:04:01,143 --> 00:04:05,598 duplicate acts, anything out of the ordinary. 52 00:04:05,589 --> 00:04:12,079 Dropped connections can also be found as well as other issues 53 00:04:12,079 --> 00:04:17,507 such as latency or bandwidth issues. 54 00:04:17,507 --> 00:04:26,111 So as we were looking at in our Q&A section, you can pull a flow graph 55 00:04:26,111 --> 00:04:34,260 very easily from Wireshark by going to the statistics menu. 56 00:04:34,260 --> 00:04:39,917 And when you go to the statistics menu, you can select flow graph. 57 00:04:39,917 --> 00:04:42,631 And you're going to have a couple of options here. 58 00:04:42,639 --> 00:04:46,705 You can choose all packets, or you can choose 59 00:04:46,710 --> 00:04:49,540 the displayed packets that you already filtered out 60 00:04:49,544 --> 00:04:55,130 as an example. You may choose to only want to see 61 00:04:55,130 --> 00:04:59,693 specifically what you already filtered or you can choose all. 62 00:04:59,702 --> 00:05:02,323 And you can look at general flow which is all of them 63 00:05:02,331 --> 00:05:06,501 or you can specifically look at TCP flow. 64 00:05:06,501 --> 00:05:10,361 And you can choose the note address type. 65 00:05:10,361 --> 00:05:14,050 For this example, we're going to look at the TCP flow. 66 00:05:14,050 --> 00:05:22,917 And then the TCP flow, as we mentioned 67 00:05:22,917 --> 00:05:26,280 you have source and destination IP's. 68 00:05:26,280 --> 00:05:31,554 So you can very quickly and easily see what is speaking to what. 69 00:05:31,560 --> 00:05:35,988 You'll see a lot of things here that don't really or necessarily amount to anything. 70 00:05:35,988 --> 00:05:39,895 There are other IP's on your network but when we're looking specifically 71 00:05:39,895 --> 00:05:46,004 for these communications, they may not be relevant to this capture or this graph. 72 00:05:46,013 --> 00:05:51,539 And interestingly, as we mentioned before you can go for, down the graph 73 00:05:51,539 --> 00:05:58,008 in time sequence format to look at between each packet what was taking place. 74 00:05:58,008 --> 00:06:04,776 So from 192.168.1.13 to a target IP 75 00:06:04,776 --> 00:06:09,687 we can see specifically 3 SYN's and then a reset. 76 00:06:09,687 --> 00:06:14,675 So it's very important to understand as you're going through these captures 77 00:06:14,675 --> 00:06:18,849 that you're very familiar with the TCP handshake 78 00:06:18,849 --> 00:06:22,771 which we'll get to in a moment in another slide. 79 00:06:22,771 --> 00:06:27,072 But this is what we're looking for and this is what's going to help us to see 80 00:06:27,072 --> 00:06:34,788 issues on, on a network. 81 00:06:34,788 --> 00:06:40,390 So as we saw here, it's a little bit bigger for your view 82 00:06:40,390 --> 00:06:46,400 you can choose all packets or ones that you're just displaying at this time. 83 00:06:46,400 --> 00:06:52,710 Or where we targeted a TCP from. 84 00:06:52,710 --> 00:07:01,746 So essentially this, the flow graph itself is used to analyze traffic flow in general. 85 00:07:01,746 --> 00:07:05,737 You can do TCP flow extraction which we just showed you. 86 00:07:05,737 --> 00:07:09,935 This will allow you to see specifically the TCP handshake. 87 00:07:09,935 --> 00:07:15,539 The TCP handshake is used to establish a connection. 88 00:07:15,539 --> 00:07:21,263 This is how TCP operates. We covered this in one of the first 2 modules of the course. 89 00:07:21,257 --> 00:07:27,881 Basically, a SYN, a SYN/ACK, an ACK is your basic handshake. 90 00:07:27,881 --> 00:07:31,725 But there's other bits that you will see. 91 00:07:31,725 --> 00:07:35,931 You will see a FIN or a reset. 92 00:07:35,931 --> 00:07:39,638 Basically, normally if you want to just finish 93 00:07:39,637 --> 00:07:43,169 or close out the connection, that would be normal. 94 00:07:43,191 --> 00:07:46,593 But if you saw a flood of resets, that may not be normal. 95 00:07:46,593 --> 00:07:49,825 That probably be a cause of an issue. 96 00:07:49,825 --> 00:07:53,546 And as we mentioned before, when you use the flow graph 97 00:07:53,546 --> 00:07:57,463 you will be able to see those in succession 98 00:07:57,463 --> 00:08:00,239 based on the conversation that you're analyzing. 99 00:08:00,239 --> 00:08:03,091 So that's how we try to put it all together here. 100 00:08:03,091 --> 00:08:08,148 You're granulizing what you see based on source to destination. 101 00:08:08,148 --> 00:08:14,316 You filter it down to the TCP flow if that's what you're looking for. 102 00:08:14,316 --> 00:08:17,101 And then you look in time sequence to see 103 00:08:17,101 --> 00:08:21,536 exactly each leg of the communication, what is taking place. 104 00:08:21,528 --> 00:08:25,893 Is there a normal handshake, is there duplicate ACK's taking place? 105 00:08:25,885 --> 00:08:30,482 Is it a constant re-transmission, it is a flood of resets? 106 00:08:30,482 --> 00:08:37,354 And this may be something that's attributable to a network issue. 107 00:08:37,354 --> 00:08:41,389 A host issue, the host can have a problem with I/O. 108 00:08:41,397 --> 00:08:44,354 read/writes the disc, anything, it could be anything causing that 109 00:08:44,371 --> 00:08:52,067 communication to stagnate or contend or have some kind of latency 110 00:08:52,075 --> 00:08:58,531 which will allow it to continue because it's TCP and it will try to continuously resend 111 00:08:58,540 --> 00:09:04,080 so that it can get the data there. However, you will be able to see that 112 00:09:04,080 --> 00:09:08,997 it causes latency or performance issue when you do that and you will be able to use 113 00:09:09,003 --> 00:09:14,203 the flow graph to isolate and find those issues. 114 00:09:14,203 --> 00:09:18,105 So reviewing the questions in the forum, I got 115 00:09:18,103 --> 00:09:21,744 2 excellent questions which I will review now. 116 00:09:21,759 --> 00:09:29,586 The first question is people are hearing that Wireshark is more stable 117 00:09:29,586 --> 00:09:34,786 on Linux or more reliable than the Windows version. 118 00:09:34,786 --> 00:09:42,331 So, this is what I've found. I've found that I've used both 119 00:09:42,338 --> 00:09:45,823 and to me both have been incredibly stable. 120 00:09:45,867 --> 00:09:49,802 There's differences obviously in the core architecture 121 00:09:49,798 --> 00:09:53,775 because one is installed on Linux and that way inter-operates with it 122 00:09:53,797 --> 00:09:55,591 and the other one is installed on Windows. 123 00:09:55,582 --> 00:10:02,803 I have found that in using both of these, they are both stable for me. 124 00:10:02,803 --> 00:10:07,880 However, I keep my machines completely free 125 00:10:07,894 --> 00:10:12,243 of anything else that I'm using, when I'm using them for analysis. 126 00:10:12,248 --> 00:10:16,272 So I would assume that if you're using a typical Windows machine 127 00:10:16,264 --> 00:10:21,000 and it's got a lot of bloatware on it and it's got a lot of stuff that you're using 128 00:10:21,000 --> 00:10:26,271 other applications, it may clutter up the machine. 129 00:10:26,271 --> 00:10:33,841 It's also an open source program, it's the GUI's made by the GIMP. 130 00:10:33,841 --> 00:10:37,195 It could potentially be more stable on Linux 131 00:10:37,195 --> 00:10:40,704 I find Linux system just to be more stable overall 132 00:10:40,704 --> 00:10:46,932 because they are built on the bedrock of Unix but Windows has come a long way. 133 00:10:46,932 --> 00:10:51,136 Since maybe the days of, when some of us 134 00:10:51,130 --> 00:10:55,807 may have started using it when it was Windows 2.0, 3.0 or 3x, 135 00:10:55,795 --> 00:11:00,554 Windows 4 groups where it's extremely unreliable all the way up in 136 00:11:00,569 --> 00:11:07,638 through some NT versions. But I feel that both are very reliable. 137 00:11:07,633 --> 00:11:16,091 The key take away here is that you keep your machines free and clear of other stuff, 138 00:11:16,101 --> 00:11:19,933 especially if you're going to be using them for protocol network 139 00:11:19,933 --> 00:11:26,055 and any other type of analysis work. 140 00:11:26,055 --> 00:11:31,334 And we have another question here. This is a great question. 141 00:11:31,334 --> 00:11:35,778 Is it possible to merge traffic flows in case of NAT? 142 00:11:35,778 --> 00:11:38,802 So let's dissect that into 2 separate questions. 143 00:11:38,802 --> 00:11:42,846 Yes, the last topic we'll cover is merging. 144 00:11:42,846 --> 00:11:46,885 We will learn how to merge files into different systems. 145 00:11:46,885 --> 00:11:49,823 Sometimes when you merge them, it'll just append it at the bottom, 146 00:11:49,827 --> 00:11:53,365 there's certain things that you'll have to do to alter the merge. 147 00:11:53,360 --> 00:11:59,172 But yes, there's a lot of reasons why you would want to merge them to analyze them. 148 00:11:59,172 --> 00:12:02,357 And then the second half of the question is 149 00:12:02,365 --> 00:12:07,898 because of traffic flows in case of NAT, or network address translation. 150 00:12:07,913 --> 00:12:13,028 There's 2 different networks separated by a firewall 151 00:12:13,020 --> 00:12:15,948 and there's net configured and 152 00:12:15,943 --> 00:12:20,298 trying to figure out some basic information on the flow. 153 00:12:20,298 --> 00:12:22,367 And you want to get that out of your capture. 154 00:12:22,374 --> 00:12:27,744 So, typically what you would want to do is you'd want to do 2 captures. 155 00:12:27,744 --> 00:12:34,080 You'd want to do one before and one after so that you have 2 captures. 156 00:12:34,080 --> 00:12:36,498 And one of the things that you're going to have to do is figure out 157 00:12:36,498 --> 00:12:39,623 from the NAT table what the translation is because 158 00:12:39,623 --> 00:12:44,171 you can merge it all together and it's still not going to tell you - 159 00:12:44,171 --> 00:12:48,540 it's not going to be able to, to translate anything for you 160 00:12:48,540 --> 00:12:53,587 so if you're not sure what the IP addressing is or what it's translated to 161 00:12:53,587 --> 00:12:57,175 you're going to have to figure that out from the NAT table 162 00:12:57,188 --> 00:12:59,674 or, or x-late table what ever you're using. 163 00:12:59,674 --> 00:13:05,645