 Sorry for the delay as I was just mentioning to some people up here. I feel very strange because I just came from a midterm, like proctoring midterm, so I didn't just teach for like 15 minutes, so I feel kind of rusty right now. Usually you get like a nice warmed up professor who's like ready to go, because I've been doing this for 50 minutes. Great, so before we get back into TCP, anybody have questions? Yes? What was the secret test of 5-2? What was the secret test to part 3? Which one? There's two. 7-2, yes. Okay, so I'm going to stop the recording so if I reduce this assignment. So the second, so the first secret test was testing URL encoding. So are you properly URL decoding the URL, not to execute the command, right? But anything in the URL can be URL encoded, right? Including the EXEC, right? And it means the same thing because it's just encoding. So you have to decode that before you test it. Does that make sense? Yeah. Well, sure. Second one was just doing a pipe. So I was doing this exact same thing as one of the other tests, but it was calling, I think, LS something, I think, slash ETC, and then piping that through some other program like TR to translate spaces to underscores, and then comparing that with that same command being executed. So if you weren't handling pipes correctly, you would fail that. Any other questions? Was it fun? Good, thank you. Yeah, I don't have the graphs, but like the number of submissions, at least like two hours before, shot up to like 36 in the queue, and that held kind of steady, so that's why it took so long for the results. I have ideas of how to speed up the submission system, but I obviously wasn't going to implement that right two hours before the deadline, so I did not do that, but I think in the future I'll try to. It's a trade-off because I had ways to make it faster, but then that caused it to be more unreliable, which is not good for you guys anyways, because you want to know that it actually passes, it's going to pass the exact same way every time, so. What ended up being the average? I have no idea, I kind of looked it on. A number. I looked through them, they looked, of the submissions, they looked pretty good. There weren't a ton of incredibly low scores, so that's good. Yeah, in the back. Would you give me a project so I can start thinking of it? You want another one? You're just a glutton for fun. The projects? That'll be, we'll do it about halfway through the course. I think we're still about two or three weeks to go before we hit half a point. Something after the break. Yeah, that's probably a good idea. Yeah, I'm thinking after break we'll start to talk about projects, but at this point it's a little premature because it's like a third of the stuff I want to cover, right? There will be five assignments, or? Whatever the syllabus says? Whatever the syllabus says? Yeah. No, that's my answer. Whatever the syllabus says. This is three or four. It's just the 50% on the assignment. I don't know. It's just somewhere in there how many assignments? I think it's like three or four. Any other questions? Project questions? Any other questions? Who said that? No one. No, the homework will be released once it's released. I want to give you a little bit of a break. Probably Friday, maybe Wednesday. Sorry, probably Monday, maybe Wednesday. We'll see. Do you want to, like, give a break? Yeah, that's fine. Wednesday would be good? I will see. Any other questions? So maybe the TA should not give out dates of assignments when they're not due yet. All right. Cool. All right. So let's clarify and go back to where we were, right? So we're talking about TCP and we're talking about how does TCP work? How does it specify all the segments? We had some confusion and I say, we, I really just mean me. And probably also you as well because of that. So the idea was looking at, we looked at this when data is being exchanged, right? So here in this packet, the client is sending the server 25 bytes of data, right? And the sequence number is 6575. So I re-looked at the spec to clarify my mind. So yes, the way we eventually got to it is correct. So the sequence number says, okay, at byte 6575, that's the first byte of this packet, right? And the next 24 bytes all go in there. So that when it acts, the act is always the next thing that it's expecting, right? So it's gonna be, and it's the problem of the, like I was trying to come up with a good way to explain it. I just had to draw it out and look at like, okay, if I sent four bytes and the first byte is at 6575 and the next byte is at 6576, the third byte is at 6577 and the fourth byte is at 6578, which means that I'm expecting 6579, which would be this sequence number plus the four bytes that I sent. So that's how we got there. So that's all good. Any questions on that? So this is why the act is essentially the sequence number plus the size. So we looked at data being exchanged and we looked at it at the packet level, right? So we saw that the connection here is pushing data and we have our acts back and forth. Somebody's gonna have to remind me do we go through these? Do we stop here? We didn't. Cool. So we can see that we have packets being sent and we can see here TCP dump is actually doing some nice stuff for us. It's showing us that, hey, up here, this 12 is the size of the TCP packet. So it's showing, hey, this is the sequence number that's being sent and it's from this to this, right? So it's doing that to the end there and so we can see the acknowledgement is correct here in the acknowledgement of that packet. If you're gonna do this in TCP dump, you want to do the, there's a flag to do absolute offsets so you can see the actual value that it's being output. Otherwise, it will actually take the initial sequence number as essentially zero and show you offsets from that. So we know how to connect. So how do we connect using TCP? How does it work? Send. Send that. Act. Yeah, three-way handshake. That's something you should, like, catch you on your arm. Or maybe not on your arm, maybe like on a part that's not so conspicuous. Or just memorize that's not a good way. Because it's something that's really important, right? This is the protocol that underlines all of our crazy internet traffic, right? Okay, so we know that and then we know how we can actually get data across, right? And we use these sequence numbers so that we know when we get multiple data and we know that we actually received the data and we get confirmation that that data got there. So now we actually have this reliable mechanism. But basically, now we need some way to shut up, right? And be like, okay, let's stop. Let's stop talking. Like, how do we do that? So this is the shutdown procedure. So basically, either partner A or B can terminate it in string by sending a packet with a thin flag sent. So what is... Why does it mean one of the partners? Shouldn't it be like the client or the server who decides? It doesn't matter. It doesn't matter? What do you mean it doesn't matter? Because the server can just say, oh, I don't want to send anything else or the client can just say, no. Right, so TCD is a full duplex, right? So both sides can communicate or send data either way. So this is a way for one side to say, hey, I'm done sending data to you. Right? And so the other partner B answers with an act at thin. And this means now A will not send any more data to B. It will only acknowledge the data that B sends, right? So you have this one-way, only one-way data stream open. And then finally when B decides it's done, it can decide to shut down the string by doing the same thing. It's sending a thin packet, receiving an acknowledgement, and then they're done. They know they're done talking. Cool. So this looks... So if the client wants to terminate the connection to the server, it's going to send the packet here with an act and the thin flag set. So that's how you know it's a terminating packet and the thin one there. Now comes the very interesting thing where the server acknowledges this. So how does it... So this is something that I had to also revisit so we didn't have a repeat of Wednesday. And looking at what's... So what's the data of this thin packet that the client sends? How much data is there in this example? Zero. Yeah, there's nothing in there, right? So the sequence number is 6983. So acknowledgement numbers, what are we normally acknowledging? The next expected byte, right? So we haven't sent any data here, right? But when we reply back, when the server replies back, it acts acknowledgement number that's one greater than the sequence number that the server sent us. So why does it do this? Because... Because... Yes, but why? Look at it. Tell me that's what it does. But why does it do that? It's a counter for the packages to go, like how the networks are coming. But it seems counter-intuitive, right? Because the sequence number... Acknowledging a greater sequence... Acknowledging a higher byte than what you actually got because we didn't actually receive any bytes for 6983. Might be counting the counter for the headers, too. Nope. We have a separate count for headers somewhere else in here, which we're not showing. It's already... It's already 6983... So think about it this way. How does the client know that the server got the thin packet? If I just send it back a packet with... Yeah, exactly. So it knows that the other side received that thin packet. If it gets back an acknowledgement with that additional... The increment of the acknowledgement number. So it's not that we actually sent... Because it seems very strange because we didn't send any bytes, so we shouldn't be incrementing the acknowledgement number, but specifically in this case with the thin. And normally I would probably not go into this much detail, but I've made a big deal about it, so I'm not going to continue to do that. Even in this scene, we return with one plus string. Only with data, though. Only with data. Like, look at this packet, right? So this is acknowledging 6777, right, the other way, and then we're sending a sequence of 6777, right? So that doesn't change because no data has been exchanged, right? The sequence and acknowledgement number should only change if we actually are sending data, right? But that's what tripped me up just because I was looking at this. So then finally, so we can actually... So now the thin came from the client, right? So that means the client's not going to send the server any more data, but the server can always send the client data, right? So it's going to send... Or that's not any data. It sent data here, right? So the server can send 30 bytes here. So the server... Let's see. I should probably stop doing this, Matt. Yeah, I'm going to stop. Okay. So then it can send a thin packet, right? So it sends data, then it sends a thin packet. And now once the client has acknowledged that, it can acknowledge, let's see, up to 698808, which means that it received the thin packet and all the data that was sent, right? So now both sides know we've properly closed our connection. Both sides know that we've closed our connection and we can go about our business. Questions on this? Yeah. Why does the first packet from the server send 30 bytes of data? Just because it's an example. It doesn't have to. It's a specific example. Yeah. So just to clarify, when you send the thin, you're signifying that you're closing your... You were done talking. You're never going to send any more data? Yeah. Whoever sent it is no longer going to send any data. So what happens if we send data on a closed connection? Should it... Is it just going to drop it? What does that kind of mean? At a high level? Someone is just trying to... It doesn't have to be. It could be. It kind of just means we both sides have some kind of... Something bad has happened and we have desynchronized view, right? I thought you closed the connection and you still think that this connection is open. Yeah. Well, you could tell if it was in the window. But if I tried to send additional data, like past... Yeah, exactly. Past this fin sequence number, basically. Yeah. Wouldn't both the client and server need to send each other thin packets? They don't have to, no. You can close one side of the connection and leave the other side open. So you only get that in one direction. So this is where the reset packet comes in. Right? So if I were to get that, I would say... The server would say, uh, client, which means something's really messed up. So it would send a reset packet to say, hey, we should reset this connection because something's going on. So it sends a reset and then it goes back to the original state waiting for a connection. Is there a hand in the back? Can I send a data with a fin flag? Can you send a data with a fin flag? I have to look. Thank you. Yes, you can, because I saw it when I was playing around with this. Yeah, it means that this is, you know, the fin is the sequence like this is the last data I'm going to send, so after this there's no more. Cool. Okay, so we can look at this and see our original connection right from dot 20 and dot 10, right? So 22 sends a fin and then dot 10 acknowledges that, so it acknowledges the sequence number here plus one. And we can see here that it's sending zero data. And then the other side dot 10 sends a fin packet and then we can see the other side acknowledges it and now we're done, right? So this terminates basically our four tuple, right? Our source IP destination port destination IP, right? So now we can make a new connection and that's a brand new connection that's not related to this one. So we want a port scan. We've talked about UDP port scans, right? We want to try to find out what services they're getting on a host, right? What ports are they listening to? So we also want to do this in TCP. So how would we, what's the easy way to do this? Send a sin packet, send a sin packet. Yeah, send a sin packet, get us an act packet, send an act packet. Act packet, right? And so we saw that there's services that are statically associated with port numbers, right? This is a convention, a standard. It doesn't have to be this way. But it oftentimes is. So yeah, in this stupidest, simplest form of TCP port scanning you try to connect to all 65,000 ports on the machine, right? If you get a valid connection then you're good, right? So we know if we did that three step handshake with the sin, sin, act, act then we know the connection is good. So is this good? Yeah, two questions. I guess the one is how many sockets can a port handle if a colleague know it's dependent? It has nothing to do with the port on the server side because it's the four-tubble, right? So you have the same destination IP, the same port number, but as long as the source IP and the source port are different you can have any combination of those. As many as the operating system will allow basically. Second question? Okay, so this is, I mean does it work? This is the first question will it work? I mean if we can do a three-way handshake it means that something's listening there, there's something there that we can send data to on that port, right? So it definitely works. What are some downsides? Is it perfect? Packets we're going to send? Three times 65,000 Is it lower than UDP? Yeah, so UDP right? We just sent packets and we would see the we would get ICMP port and unavailable messages back for those ports that there was not services running on. But we weren't necessarily guaranteed to get a response back if it was there. Another advantage, so we'll look at this a little bit more, so you don't need to be root, right? So any program can make a TCP connection to any port and any IP on another system, right? So doing this, you don't have to be root, you don't have to fiddle with any packets, you just ask the operating system, hey, connect to this IP and this port using TCP. And then if it says connection successful, then you go, yes, awesome, I've port scanned this machine. The disadvantage as we saw, right? It's very noisy, right? You're sending all three-way handshakes all the time. So it's noisy on your end and on their end. Yes? Good question. We'll think about that as we refine this some more. Yeah, so unlike UVP, we can play a lot of different games here. And we'll see, we can actually get it very advanced, which is very cool. Is it because you tell the client what is the next expected packet number? We'll see. We'll see. Yeah. Basically, yes, that would be if we could do it with less packets, then that's definitely going to be better. But let's look at what this looks like. So you can use Nmap to do this. I guess you don't have to be a brute, I should change that. So you can Nmap and it will just try to and you can see here that this version of Nmap actually only does the top 15,000 ports that are used by TCP. There's a fly, I have no idea what it is to change it to do all ports from one to 65,000. And then so it shows you. Okay, on port 7, TCP, there's the echo service open and it shows you the names of those services. And once again, the important thing to remember is all the information that this is giving you is I was able to connect to this IP on this port, successfully make a connection. And I know that that port number is associated with this service name. It does not guarantee that that service is actually living there. It's entirely possible to change port 22 and change it to a completely random port. And then it will show up in the services as HTTP if it's port 80 or whatever it happens to be. So it's just important to keep this in mind that just because Nmap says that these things are there doesn't necessarily mean that they're actually running. Yeah, so our refinement of this technique is, okay, instead of doing the whole handshake, let's just send a SYN tagging. And if we get a SYN act back then we know that, hey, this is a port. Something is listening there, right? Because the server is trying to connect to us. It's not giving us a denied message. So we never have to send the finished the finished act. And so this is called, for this reason, half open scanning because you're only halfway making it's not actually halfway. It's like two steps of a three-step process. Yeah, so you send a SYN packet. If the server answers with the SYN act packet then the port's open. But if it sends a reset packet or you get no response back then it means that that port is closed. And then the attacker can send a reset packet instead of the final act so that that way the operating system on the other end just terminates the connection. So this is actually an important point to note at the bottom here. This obviously depends on the operating system and the versions and everything like that, but this could be something that's handled by deep networking IP layer code that says, hey but I get a SYN packet I send a SYN act and then if I get a reset I just stop. I kill that connection. But it's not actually logged anywhere that somebody tried to connect to this port unless you have additional logging features. So we can look at what this looks like. Now for this you do need to be root to do this because you need to actually create packets and only do half of the connection. Linux doesn't allow you that level of packet granularity by default to any application. But using like libnet or scabby you can easily do this, which is how Inman does it. So I would say, okay these are the ports that I found was open and we can look and see that okay it's sending from .69 to .38 It sends a packet to port 78 and there should be like dots above here because there's a lot of stuff that's happening. It sends a send packet to maybe it doubles it for some reason? I actually don't know. I think maybe it could copy past that error. Port 82, port 80, port 79. So we get a reset packet back from port 78. So we know 78 is not open. 81 is not open, 82 is not open and we get a send back from port 80. So we know if that's up and then we send a reset back to port 80 so that way it terminates the connection doesn't keep anything open and we just continue going about our business. Does it acknowledge our reset? No, that's a reset from 79. Are these in order 78 if you want it to again? Any questions on this? So this is our attempt to essentially use the knowledge of the T-SK stack and how it works in order to scan because what's the bit or I guess 65,000 bits of information we're trying to get? So this result tells us one bit of information what's that bit of information? Port 80 is open on that IP. That's that one bit of information. When we're doing these scans we want to find out for all ports. So 65,000. So I'm just thinking of it like it's one bit of information, is it open or closed? And one way is try to connect. But by using our knowledge of the T-SK stack, which is something you guys identified right away it's like yeah, why do this whole three-way handshake? We can actually get that bit of knowledge earlier in that handshake between sending the SIN and then if I get a SIN act back now I have that bit of information. I don't have to complete the connection. So that's what kind of all these techniques are about is how can I extract that one bit of information that this port is open or closed based on my knowledge of networking and that kind of stuff. Isn't it locked somewhere? It depends on the system. I can't get into the particulars. You can kind of see that clearly you want to log all fully established connections. But for every reason maybe you don't log every single error case in every single reset packet. So that's kind of what this technique takes advantage of. I still think even with this sending the reset, I think it uses less packets for port, right? For open port. Yeah. Why do we need... Because the operating system the abstractions that it gives us to operate with IP and port only allows us to say connect to this IP and this port. I think the higher ports are allowing the lower ports. That's for listening. Not for connecting though. For connecting everything? Yeah, you can connect to whatever port on any other machine. But, so the operating system abstracts all these details from you, right? So you only get a response back when you've done the SINAC hack. Right? And then you get a good that packet is good, now we can use this to communicate. But it doesn't give you any of this. So it's really to say only send the first two packets but when you get the third one back send a reset packet. So that's why you have to manually craft these packets. The TCP implementation doesn't give you that type of abstraction. Okay, so there's other cool ways to do this and we're going to go through them. So one way is fin scanning. So what does this sound like it means? It doesn't fold TCP connection and it goes to the left. So actually, so SIN scanning right, use the SIN packet to do SIN, SINAC, ACK for full connect scanning. This is, we're going to try sending a fin packet to that port. So why might this be interesting? How could this give us that bit of information? What? An acknowledgement. This is actually to establish a connection. So now we're kind of diving the level. So if you think about it at a high level the connect scanning that actually takes advantage of the protocol level. The protocol says if you get a SIN and you're listening on that port, you need to send back a SIN ACK and then you send back an ACK. Both those two the half open and the fully SIN scan, they take advantage of the protocol. But now to be able to sneak here we can try to take advantage of different implementations. What do they do in error cases? Does their response when I do something that's not in the spec does it allow me to get that bit of information that it's listening or not listening? So here in a lot of TCP IP stacks if the port is closed when they get a fin packet a reset packet is sent back that says hey, we've reset but if the port is open the fin packet is ignored so now we have a way to distinguish between these two cases we can extract our one bit of information just by sending fin packets. Of course this doesn't work in all cases so on some versions of Windows a reset packet is sent either way so it doesn't actually work for all TCP stacks. But if you know you're targeting a Linux machine you can use these techniques and there's this is kind of like a general concept of it's actually applied a lot in security so basically can I fingerprint or can I get some information extract some information based on variations in an implementation does the implementation change its external behavior based on the condition that I'm interested in this case port listening and what happens when I send a fin packet what happens if I just like what if I set all the bits in the flags what if I set the fin packet, the push packet and the urgent packet why is it called a Christmas tree or Xmas packet everything is all lit up like a Christmas tree all ones so what does it do I believe this back has no say of exactly what should happen in this case so that means implementations are free to do it differently and if they respond differently depending on the the status of the port now then we have a way to detect what if we set no flags all flags is zero how does the implementation respond so we can look at this you can do this Nmap supports all these kinds of things it has tons of options you can look at this so you can say okay scan for using fin scanning so in this case it's going to send a fin packet to port 79 82, 81, 80, 78 and it gets it gets back a reset from 79 82, 81, 78 and it gets back so we know from the timeout here we didn't get a reset from port 80 so we've inferred that port 80 is open just like relying on any kind of timeout based technique it could be that that packet just got lost just like with UVP so we should probably do some other steps then to verify that this was the case any questions on this so it's kind of a general idea this concept applies in a lot of different places in security so for instance areas you wouldn't even expect like fingerprinting browsers so often times advertisers want to try to fingerprint your browser to link your profile and your browsing habits with other different users in different sites so to do this they'll use features of your browser like what fonts are installed and what functions are available like what exact version of your browser are you using what fonts are installed what extensions are installed and those few bits of information are enough to uniquely identify you so this is kind of the same idea just in a different context can I say that fingerprint scanning is not accurate because it comes in and it works that is busy and it drops a lot so most of my packages are full yeah so the other ways were more reliable like especially connect scanning I know 3-way handshake but whereas in this if the package gets dropped or something happens to the network so maybe you take an additional step afterwards to verify but you're sending an awful lot less traffic so it's good as an advert yeah yeah well it depends on the time out you don't want to overload the network so I can't do a hybrid approach where you don't get a response back in a certain period then you send a send you can do a hybrid approach you can use this list to build and do some reconnaissance of what services are listening on that machine that information on its own isn't that interesting the attacker will try to leverage that information by trying to connect to those services to do something so yeah eventually you're going to want to verify so if we think about this from the defender's perspective what's kind of the downside of the attacker for all three of these or all of these port scanning techniques slow they're not actually that slow it depends but yeah you need root access for some but that doesn't have anything to do with a defender it's not leveraged in what sense yes that's true so we're not, we probably can't use this for any time in denial of service attack because in denial of service we need some kind of leverage what was what were some of the things we could use ICMP packets for like smurf smurf attack why could we do those things because what? we didn't need a response why don't we need a response what did that allow us to do spoof the source IP address right can we do that with these techniques can we spoof the IP address for SIN scanning or connect scanning no why not so can we spoof, let's think about this one so it's a three step process can I spoof the the source IP of the SIN packet yes, just an IP packet I can spoof that but when the server replies we reply to yes, the other person that we we replied to or we spoofed but in order to successfully complete that connection we need to send an acknowledgement of whatever that sequence number that went to another machine that we don't control right so we'll actually get into how we can do that but for connect we need to send a packet and we need that packet to come back to us so in all three of these cases for connect scanning and SIN scanning and FIN scanning we need the responses back to us so we can't spoof where this comes from well is that good as an attacker we can't hide ourselves with a Smurf attack we can actually hide that it was us doing it which makes it I'll say two things way cooler and also more dangerous and more impactful so there's actually other ways that are stealthier to do this port scanning that don't actually come from you but that are can be less reliable so we trade off kind of reliability for stealthiness this is what's called idle scanning so it's a little bit complicated but it's really interesting so the idea is we're gonna this might be on the related but NF has a spoof option to do you know what that does so I'm ahead of no yeah I don't know I mean so okay when I say that you can't spoof right if you spoof a host on your local network that doesn't exist and you can use like powerful poisoning to pretend that it came from a different IP address on your local subnet because you'll still get those packets coming back so you can change that you can spoof the 9 address too but doing like something really interesting like pretending to be a computer and a computer network for most attacks okay so the idea is we're gonna use a victim host to basically relay our scan so we're gonna try to use this host to extract that one minute information from a different from our actual victim host so we use this host essentially as a relay so the basic idea is the word idle comes from here is we want a machine that's not generating a lot of traffic we want a machine that's essentially idle that's doing basically nothing our relay then what we're gonna do is we're gonna send our victim that we want to scan we're gonna send them a sim packet spoofed from the source IP of our relay and what we'll see is that by so it seems that packets are coming from the victim right or from the victim relay and the target it seems like the packets are coming from the relay and so the target will then reply to the victim, apply to our relay so if the port is open right we expect the target that we're trying to scan to send back a sim and if that happens then the victim said hey I never sent you a sim packet we should reset this connection because you're going crazy there's no I never sent you a sim packet but if the target replies with a reset so if the port is closed right and our target sends a reset packet then our relay doesn't send out any packets at all so we can actually leverage the fact that in most TCP IP implementations the ID datagram the IP datagram right has an ID field what was that field used for? why do we want to identify packets at the IP level? fragmentation yeah we fragment packets and know that they come from the same original packet so what I can do as an attacker I first send a packet to the relay see what ID number it is then I send this packet spoofed as if it's coming from the relay this behavior here will conditionally change the ID of the IP datagram and then I send another packet to the relay and it will respond back with a different ID depending on if this was successful or not so the idea is if I know that this datagram has increased then I know that the port on the target machine is actually open otherwise if it's not increased then I know that port is closed so I'm essentially inferring the state of the port on a third machine being open or not depending on if the ID field of an IP packet changes on my relay machine and I can do that because this machine is idle and it's not servicing requests because I'm essentially trying to see if it does this one if it increases based on one packet being sent back so questions on this at a high level and then we'll kind of step through this so hopefully it'll make a little more sense is this not really cool? it's really cool you're like tricking another machine into scanning a third machine okay so first step we have to do is the attacker needs to determine what's the initial IP ID that sequence number should be ID right so we have our relay we have the victim and we have the attacker so the attacker is going to send a packet to the relay says hey this is from the attacker we can't spoof our address because we need the response back so hey this is an attack this obviously would be you wouldn't say I'm attacker you'd say from IP address me to IP address you of the relay ID doesn't matter to some port a SINAC or something and then it sends us a reset packet back and this has an IP datagram ID of 1234 which makes it very easy to remember so now I know so now what I'm going to do is I'm going to the attacker is then going to spoof a SIN packet as it came from the relay to the victim okay so the victim is going to get this for port 80 because I want to see if port 80 is open and then when the victim gets this what's it going to do if port 80 is open SINAC to who the victim right not to us not to the attacker we don't get that right so it responds back and says hey thank you for your connection attempt here's the second step of the two-way handshake and then what does the relay see right the relay didn't see this top packet at all right it has no idea about this so it's just getting a SINAC packet from a random machine right so it's like what are you doing crazy stop talking to me it sends a reset but look at what happened to the ID number here got incremented to 1235 from 1234 which we originally had when we talked to the machine so now I do the same thing now I've done this so now I want to determine the relays final IP ID so I'd send another packet like a SINAC or whatever and it would send me a reset and so I see it's 1236 right so it incremented 2 from when I originally sent that packet right so then what about the case where I send a spoof connection this is a closed port port 80 is closed is the victim going to send a SINAC no he can't it's either going to send nothing right which we saw could be the case on some systems or it's going to send a reset packet say right this is not good and then the relay when it gets a reset packet for something it has no idea if you think about it right if I say hey our connection is messed up and you get that and you're like I'm not expecting a reset here's a reset your packets messed up we would just keep sending back resets forever right so this is why the relay shouldn't reply to a reset right it should just either ignore it or not do any behavior here so now what's the next IP packet that relay is going to send what's it's IP going to be 1235 right because we got 1234 first this didn't generate any packet from relay the next packet is going to be 1235 so now we can make that connection and see that the packet back is 1235 so now we've used this that difference of that ID field try to get that one bit of information of is port 80 open on a completely different machine and victim only ever sees IP traffic from the relay right he doesn't even know we exist it doesn't know our IP address it doesn't know nothing about us and if really it's a machine that's idle and it's not being used at all then I doubt they're doing any logging of who's sending packets to them questions on this does this have to be really centralized I mean yes and no so if you want to precisely determine based on one of this yes but the nice thing is you could do like a you do this multiple times right statistical analysis and say okay is it likely that this port is open or not right and the more time you do it the more time you'll be able to tell how long would the FTP need to wait until sending another packet to relay yes it's tough I don't know right I mean there's no one good answer right because you also have to yeah you have to send spoof that packet it could be that victim is a policy where he doesn't send any packets back to relay's IP address right you could have to try different relays that's why you're trading off your reliability versus stealthiness because you have to rely on this completely third party machine that you have no control over so packets could get lost accidentally right in the network you would never know about it all that kind of stuff it could be that victim never and you don't know if it's did this IP number not increase because victim ever got your original packet or did the response from victim to relay get dropped any number of things could have possibly happened so but you know you can you do it enough times and you can kind of you're reasonably I mean not assured but you have some idea how do we first determine whether a system could be used as a relay system or not how can we do that how can we do that what was it sniffing let's say they're all on completely different networks and they're all stretching so so yeah right so we're already relying on the fact that the IP datagram is essentially doesn't have to be monotonically increasing but is increasing based on the traffic right so we could send these packets and try to send these packets to relay and see how that number is changing right if that number is changing not very much at all then we can say yes it's probably idle if we know the server like it's located in the US and it's used for ASUs random companies payroll or something right we can say okay it's probably highly unlikely that this is going to happen at like Sunday at 3am right so we could do that then yeah one more question like we are looking at the ID number over here but this won't be much this technique would be much reliable because the relay can be talking to many other people so might be ID number can change to a high extent yeah so that's why we have the idle so that's one of the keys of this technique is you choose a relay that is idle and it's not making a lot of connection okay I really want to get done with this okay we have alright we'll definitely be able to finish all this on Monday I'm probably going to cut some stuff but we'll finish networking on Monday