A vulnerability in TCP, the transmission control protocol, recently received some exposure in the media. Paul Watson released a white paper titled Slipping In The window: TCP Reset Attacks at the 2004 CanSecWest conference, providing a much better understanding of the real-world risks of TCP reset attacks.
To better understand the reality of this threat, KernelTrap spoke with Theo de Raadt [interview], the creator of OpenBSD, an operating system which among other goals proactively focuses on security. In this article, we aim to provide some background into the workings of TCP, and then to build upon this foundation to understand how resets attacks work.
This is the first article in a two part series. The second article will look into how TCP stacks can be hardened to defend against such attacks. Toward this goal, we spoke with members of the OpenBSD team to learn what they have done so far, and what further plans they have to minimize the impact of reset attacks.
Transmission Control Protocol overview
The first section of this article aims at providing some basic information about TCP. We intentionally gloss over much detail, focusing primarily on that which is relevant to understanding TCP reset attacks. If you already have a good understanding of TCP, you may want to skip directly to the section on how reset attacks work. Please realize that as we only focus on the aspects of TCP necessary to understand reset attacks, if you don't already have a good understanding of TCP, don't expect to be an expert after reading this article.
TCP is an abbreviation for the Transmission Control Protocol, defined in RFC 793 which was released in September of 1981. TCP is a connection oriented protocol that can reliably get information from one host to another across a network. By reliable, we mean that TCP guarantees all data will arrive uncorrupted at the remote host, automatically detecting dropped or corrupted packets and resending them as needed.
Every TCP packet includes a header, which is defined by the RFC as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Programs utilize TCP by passing it buffers of data. TCP breaks this data into packages known as segments, and then uses IP to further package these segments into datagrams. Finally, the datagrams are embedded into a network packet which can be routed across a network.
When the packet arrives at its destination, the IP stack on the remote host extracts the datagram from the packet, then the segment from the datagram. The segment is then passed up to the TCP stack, where it can be validated. Ultimately the TCP stack can reassemble all the segments into the complete buffer which is then passed to the application. TCP provides two way communication, so this same process occurs in both directions.
Sequence numbers:
With data having been broken into segments which are then routed as separate packets over a network, it is quite possible for packets to arrive at their destination out of order. A field in the TCP header provides for a 32-bit sequence number, a value that starts at an arbitrary integer then increments sequentially with each transmitted packet. Using these sequence numbers, the receiving TCP stack is able to properly reorder the received segments.
Windows:
TCP also provides a mechanism for hosts to tell each other how much data they want to receive at a time. This is known as a 'window', defined by a 16-bit field in the TCP header. Once defined, a host will generally only receive data that is "within" its specified window, dropping anything else. Being within the window means that the sequence number of the packet is a number that is within the range of data that one end of the connection told the other end it was willing to receive at any one point in time. If a receive queue gets full, the host can declare a window of size 0, telling the other endpoint not to send anything and giving the backed up host a chance to catch up.
Control bits:
There are six 'control bits' defined in TCP, one or more of which is defined in each packet. The control bits are 'SYN', 'ACK', 'PSH', 'URG', 'RST', and 'FIN'. TCP uses these bits to define the purpose and contents of a packet. For the purposes of this article, we are primarily only interested with the SYN, ACK and RST flags, though we will briefly define them all.
The SYN bit is used in establishing a TCP connection to synchronize the sequence numbers between both endpoints. The ACK bit is used to acknowledge the remote host's sequence numbers, declaring that the information in the acknowledgment field is valid. The PSH flag is set on the sending side, and tells the TCP stack to flush all buffers and send any outstanding data up to and including the data that had the PSH flag set. When the receiving TCP sees the PSH flag, it too must flush its buffers and pass the information up to the application. The URG bit indicates that the urgent pointer field has a valid pointer to data that should be treated urgently and be transmitted before non-urgent data. The RST bit tells the receiving TCP stack to immediately abort the connection. And the FIN bit is used to indicate that the client will send no more data (but will continue to listen for data).
For example, a TCP connection is usually initiated with a three-way handshake. That is, host A will send a packet to host B, setting only the SYN control bit, and putting a randomly generated number into the sequence number field of the packet's TCP header. This randomly generated sequence number is the ISN, or initial sequence number.
Host B receives the packet with only the SYN bit sent, and therefor knows that host A is trying to establish a connection, currently trying to synchronize sequence numbers. Host B therefor replies by sending a packet back to host A, setting both the SYN and ACK bits. Host B generates his own random sequence number and puts it into the sequence number field of the packet's TCP header. He also puts Host A's ISN +1 into the acknowledgment field, indicating the next sequence number expected from Host A.
Host A receives this packet with both the SYN and the ACK bits set. It verifies that the number in the acknowledgment field is correct, then generates a third packet, this time with only the ACK control bit set. In the acknowledgment field of this third packet goes the sequence number +1 from the previous packet, acknowledging to Host B that the SYN ACK packet was received and indicating which sequence number is next expected. This done, the three way handshake is complete and a TCP connection is now established between host A and host B. At this point, data can be transmitted in both directions between the hosts.
The three way handshake we've described is the most common mechanism for opening a TCP connection. However, the RFC does not require that communication begin this way, and therefor it is perfectly legal to add in other control bits during the initiation of communication. OpenBSD creator Theo de Raadt notes that many of the problems with TCP have originated from the fact that the RFC really divides the protocol into two separate parts, the first being connection establishment and breakdown, and the second being data flow. Theo explains:
"This has resulted in weird stuff like SYN|ACK|FIN exchanges being possible... some people will say it is wrong, but it is explicitly left open in the RFCs.. nothing says you can't attempt to move data in your first packet."
Ports:
In addition to allowing hosts to carry on bidirectional communication within one connection, TCP also allows hosts to maintain more than one TCP connection at a time. This is done using ports. A port is a unique integer from 1 through 65,535. All TCP connections originate on a "source port" within the above range, and terminate on a "destination port" within the same range.
For most common TCP connections, the destination port is a well known established value. For example, a web browser usually connects to destination port 80, a mail client sending email connect to destination port 25, and an ssh client connects to destination port 22. The reason these clients connect to specific ports is that their respective servers are known to be listening on those ports. The complete list of officially assigned port numbers is maintained by IANA.
The source of TCP connections, however, can usually originate from any port, though certain lower port numbers are reserved and unavailable for use as a source port. (In particular, ports 1-1024 are reserved for well known and privileged processes.) There can only be one outgoing TCP connection from each port at a time, allowing the TCP server to differentiate between multiple TCP connections from the same host.
When a TCP connection is made, the combination of the source port and IP address and the destination port and IP address results in a unique fingerprint that can be used to differentiate between all active TCP connections.
With this minimal understanding of how TCP works, it is now possible to understanding what reset attacks are and how they work.
TCP reset attacks
The primary idea behind a TCP reset attack is to falsely terminate an established TCP connection. Lets imagine an established TCP connection from host A to host B. Now, a third host, C, spoofs a packet that matches the source port and IP address of host A, the destination port and IP address of host B, and the current sequence number of the active TCP connection between host A and host B. Host C sets the RST bit on the spoofed packet, so when received by host B, host B immediately terminates the connection. This results in a denial of service, until the connection can be reestablished. However, the severity of such an attack is different from application to application.
Applications and protocols that require lengthy sustained connections are most vulnerable. Perhaps the most affected is Cisco's BGP, or Border Gateway Protocol, the latest version of which is defined in RFC 1771. BGP is so vulnerable as it relies on a persistent TCP session being maintained between peers. If the connection gets terminated, it then takes time to rebuild routing tables and remote hosts may perform "route flapping". A route flap is any routing change that results in a BGP table being changed. A router that is constantly loosing its connection and causing route flapping on other BGP routers will eventually suffer route dampening, or suppression. As BGP is used on large border routers, this could have a significant impact on a large number of users.
As described earlier in this article, TCP utilizes sequence numbers to determine whether or not a packet with valid endpoints (IP addresses and ports) applies to the current active session. This both allows TCP to both properly reassemble even out of order packets into the original data buffer, as well as to ignore potentially spoofed packets.
Slipping in the window:
In Paul Watson's recently released technical white paper, Slipping in the Window: TCP Reset Attacks, (currently only available in doc format) he explains that TCP connections are more susceptible to this type of attack than was previously thought. Specifically, in previous calculations it was assumed that a brute force attack would have to try every sequence number from 1 up to the maximum of 4,294,967,295. In Paul's paper, however, he points out that the number of required attempts is significantly less than this, due to TCP windows.
For example, if the TCP stack on host A has defined a 16K window, the stack must accept any packet that has a sequence number that falls within this range, as the packets may be arriving out of order. Hence, someone that is performing a TCP reset attack doesn't have to send a RST packet with every possible sequence number, instead only having to send a RST packet with a sequence number from each possible window. In other words, still assuming a 16K window size an attacker would have to send 4,294,967,295 / 16,384, or 262,143 packets to exhaust all possible windows.
262,143 may sound like a large number, though when considering a RST attack it is possible that an attacker will be able to generate tens of thousands of packets per second, depending on their bandwidth. What more, an attack could be distributed among many hosts, thus being an aggregation of all their bandwidths. However, assuming the attacker has a single DSL at their disposal, according to Paul's paper they will be able to generate about 250 packets per second. Thus, a single DSL would be able to exhaust all possible windows in just over 17 minutes. However, with a T1 at 4,370 packets a second, the attacker would be able to exhaust all possible windows within only 60 seconds.
Our example assumed a 16K window size, however the TCP RFC provides a 16 bit field for the window, allowing it to be as large as 64K. If the full window size is utilized, an attacker would only have to send 4,294,967,295 divided by 65,535, or 65,537 packets. With this window size, it would take a DSL about 4 minutes, and a T1 only about 15 seconds. And remember that these times assume that you would have to try every single window before finding a match, when by the law of averages you could expect it to take closer to half that time.
In Paul's paper, he times the results of actual reset attacks. At DSL speeds against a host using 64K windows, Paul was able with brute force to on average generate a reset in within 3 minutes, however some of the attacks took only a few seconds to be successful. At T1 speeds, Paul was on average able to blindly tear down a session in less than 8 seconds. With a connection faster than a T1, the time to brute force a matching RST attack can quickly become insignificant.
At this point one may wonder why anyone would specify a large window, as it obviously decreases the security of the TCP stack. The reason is, larger window sizes generally provide higher performance. For this reason, RFC-1323 was defined in 1992 titled, 'TCP Extensions for High Performance'. Among other features, this RFC defines "window scaling", a widely supported TCP extension that effectively increases the available window size from 16 bits to 30 bits. Thus, against an application or protocol using window scaling open to the maximum range, an attacker would only have to send 4,294,967,295 divided by 1,073,741,824, or 4 packets. That's right, it would only take 4 spoofed packets to generate a matching RST packet against an application that fully utilized window scaling. Again, an example that uses window scaling is Cisco's BGP, which frequently utilizes window scaling to improve performance.
Source ports:
All of the above examples assume that the attacker already knows the destination port and IP address as well the the source port and IP address. The destination port and IP address are easy, as they are generally published. The source IP address is also generally easy, as this is simply the client that is being spoofed. The only piece that can frequently be difficult to find is the source port.
For example, if an operating system randomly assigns source ports from a pool that ranges from 1025 through 49,152 (such as OpenBSD), this increases the difficulty of performing a reset attack 48,127 times as the attacker would have to try their sequence attack with every possible port number. In our first example with 16k windows, we determined that with known endpoints it would require 262,143 packets to guarantee a successful reset attack. However, if using random ports as we've described, it would now require 262,143 times 48,127, or 12,616,156,161 packets. An attack of that size would all but certainly be detected and dealt with before a brute force reset would occur.
Realizing the security added by using randomized source ports, you would expect that most operating systems employ this defensive strategy. Unfortunately, according to Paul's paper, most operating systems allocate source ports sequentially, including Windows and Linux. A notable exception is OpenBSD, which began randomizing source port allocation in 1996.
SYN attacks:
A reset attack can be performed indirectly without setting the RST bit. Instead, the attacker can set the SYN bit, otherwise identically performing the brute force attack as described earlier. On most TCP stack implementations, a duplicate SYN will cause a RST to be sent in reply with the provided sequence number. If the SYN is within the window of the active matching session, in addition to sending a RST in reply, it will cause the local end of the connection to be immediately torn down. This action is by design, intended to handle system reboots during a TCP connection.
In response to the threats of reset attacks, the IETF is now recommending that when TCP stacks receive an in-window SYN packet, they should instead reply with an ACK. If the SYN was truly from the remote client attempting to re-establish communication after a reboot, then it will not expect the ACK packet and will reply with a valid (in-window) RST, causing the now stale connection to be torn down. If the SYN was instead spoofed by an attacker, the ACK will be ignored. However, OpenBSD creator Theo de Raadt points out that this may be even more problematic, as if the attacker keeps spoofing valid SYN packets the continuous flood of generated ACK packets could become a serious problem. Theo notes, "nowhere is the IETF telling anyone that this is dangerous", further explaining:
"Every SYN I spoof onto one of your sessions, you will send an ACK over your peer link. If I have 1GB to spoof to you, but your link to your peer is a T1, I can hurt your T1. We call these types of things 'reflectors'. They are bad."
For these reasons, Theo explained that SYN based reset attacks are actually more serious than RST based reset attacks. Not only can using the SYN bit tear down a connection, but based on the latest IETF recommendations it can also result in the generation of more packets, potentially flooding a connection. He added:
"Think of it this way: Some systems have SYN behaviors that can interact badly with RST behaviors on other systems."
Blind data injection:
A third related attack is called 'blind data injection', and again relies an brute force to find a matching sequence number. Essentially, instead of simply sending empty RST or SYN packets, the attacker could send data packets. The attack would commence as we've already described, except now instead of tearing down a connection, the attacker may instead corrupt the connection, invalidating the data that was being exchanged.
Conclusion:
At this point, you should have a decent understanding of what a reset attack is, and how it works. Our goal with this article was to better understand if the threat is real, and indeed it seems to be. Asking Theo for his views on the reality of reset attacks, he replied, "lots of people are saying this is not a problem, but I am sure we will see a worm using it one day." Worms can effectively perform distributed attacks, greatly increasing the speed at which a reset attack could be conducted.
It is not possible to fully protect against a brute force TCP reset attack, but there are many things that can be done to harden TCP stacks. The TCP RFC is not a narrow definition, leaving many design desicions up to each operating system's implementation. It is perhaps because of this fact that many popular operating systems are quite susceptible to reset attacks, though there are published methods for hardening against them. Theo predicts, "fact is, critical server systems with these poor TCP behaviours will stay around for quite some time."
Choices made in the implementation of a TCP stack can significantly affect an attacker's ability to efficiently perform reset and other types of attacks. In the second part of this series, we will explore methods of protecting against reset attacks, using OpenBSD as an example. Hopefully other operating systems will follow their lead, futher hardening themselves against such attacks.
What about grSecurity?
While linux stock may not have all the added security of stock openbsd kernel, how does the grsecurity patchset stand in all this? Looks to me it clones some of the same security features such as the mentioned randomized TCP source ports. Just suprised it wasn't mentioned, thats all.
Sean R.,
graywind -AT- badadmin -DOT- net
Yes, grsecurity should provid
Yes, grsecurity should provide enough to push Linux up closer to OpenBSD's level, with its capability to provide randomized source ports and a stronger algorithm for ISN selection.
To quote part of the GRSecuri
To quote part of the GRSecurity page: "OpenBSD Provides the randomization functions for random TCP ISNs, IP IDs, and PIDs, that have been ported to grsecurity." If GRSecurity took OpenBSD's code for some of these randomization elements, why not just talk about OpenBSD as the source of the functions, and not people who have borrowed them?
Not to discount GRSecurity as some of the ACL's (and the related stack protection implementations in PaX with which it is often presented) offer by it are really quite innovative in their own right. That said, this article and problem is more in line with TCP stack implementations than OS hardening as a whole, in which case mentioning GRSecurity isn't as pertinent I would think.
Re: To quote part of the GRSecuri
Mentioning grsecurity is pertinent, so people know they don't necessarily have to switch OS to get randomized TCP ports etc.
What I have been wondering ever since "discovering" grsecurity is why the patches in it (or at least those of them that have no runtime impact) are not in the mainline kernel.
i think the OP brought up grs
i think the OP brought up grsec not for its general hardening features but specifically the TCP/IP stack related ones (which come from OpenBSD, no credit is lost). given the article's general bias towards OpenBSD i think it's not bad that the rest of the world knows such features have been available on other systems as well for years.
this article and problem is more in line with TCP stack implemen
Then why metion OpenBSD at all?????????????
NANOG has had long discussions on this
The North America Network Operators Group (NANOG) has had dicusssions about this since the day it came out.
The short story is that RST attacks against routers are not that easy. A lot of routers simply can't handle 4k+ pkts/second a T1 could generate, so if you have a T1 at your disposal, you can probably just bring down the entire router rather than playing games with a RST attack.
Read the NANOG mailing list for more background.
Pete
I've never understood
Why people use such 'small hardware' for such important tasks.
I've always felt, a router/firewall should be able to handle all traffic passed to it over the connection it's sitting on, otherwise why bother ?
(yes I know connections have grown quiet a lot bandwidth-wise, but so have the other hardware)
Well, that's my opinion. :-)
it's fast path vs slow path
Most routers have no problems *forwarding* traffic at line rates. Which is what people are usually concerned with. This typically goes over the routers "fast" path, which is almost all hardware based.
TCP connection processing to/from the router however, is handled over the "slow path", which is done by the CPU/OS/software. Given the size of pipes going into these boxes, I doubt the CPU exits that could run a modern OS and still handle even a faction of the traffic their hardware based fast-path can. And router venders are going to size their internal CPU/RAM based on typical usage, not on handling all the interfaces at full rate. Adding a bigger CPU would just add to the cost.
First of all i'm not so exper
First of all i'm not so experienced in Networking , i would just like to throw my 2 cents :)
Even if is not , actually, applicable for all type of connections, what about an IPSEC cyphered connection to avoid this kind of problems?
Surely this is not a solution for server that have to serve public access, but could save you if your public-ip server is for restricted access only.... maybe :)
bye!
IPsec
Yes, IPsec would probably solve this problem. It would encrypt the TCP level traffic, and so any attempt to spoof things would fail.
But it brings up the problem that many of these routers either don't support IPsec, or don't have the CPU power to do so. And it'd require both sides of the connection to support it. And turning on IPsec on those pairs of routers that do support it would be a logistical nightmare. Then factor in that many of these pairs of routers are owned by different ISP/NSP's, who's NOCs are all in different time zones, etc, etc, etc.
Certainly long term, it's probably a good solution, but it doesn't help much in the here and now.
Pete
Blindly resetting vs sniffing and resetting
If I understand this correctly, this method allows an attacker to blindly reset a TCP connection between two hosts.
However, if I can sniff the traffic of a TCP session, then I should be able to reset it without having to guess at all, right? This would work well on a LAN.
So, a worm writer could, after infecting hosts, sniff traffic on a LAN and reset TCP connections, and basically DOS the LAN. Of course, the worm would probably have to play tricks on switches to be able to sniff traffic, but that's not hard, from what I understand.
yes
If you can sniff the TCP traffic, then you can see the ports used on both sides and the sequence numbers. So resetting the connection would only take one packet.
And sniffing traffic on a switched network is not very hard - go google for dsniff, which contains an arpspoof tool.
One problem with this is that you'd need to do a lot of other work to make this work, and once you're on a lan, there are a lot of other things you could be doing.
Pete
tcpkill
dsniff also comes with tcpkill, a utility which actively kills TCP connections.
CA eTrust IDS uses this mechanism ?
A couple of years ago - we implemented eTrust IDS at the organisation I was working at then.
It uses this mechanism to terminate intrusions and infact - advertised it as a feature !
Venu
Cable modems are lans
Cable modems are lans.
Yes, every Docsys modem I've seen filters out packets that aren't addressed to you (a la routers), but the ARP's are broadcast. And, the two cable companies I've seen may use DHCP, but you get the same IP address each time.
So, once I've seen an IP in an ARP, I can play with the traffic of someone I don't like.
Haven't played with them enough to tell if the modem uses it's own IP/Mac address or not. But if they just pass MY mac address, then I could change the mac adress my adaptor uses to match the mac address I saw my target use when they asked for the upstream router's ARP.
If I do that, then I'm pretending to have the same mac as my target, so everything sent through their cable modem to them will also go through my cable modem to me.
Suddenly, even though I can't actually do anything with their computers/their physical lan, I can peek on every packet, and with this I can play with/inject traffice into/close down arbitrary connections on their system.
Michael Gersten
michael-kerneltrap-fromslashdot at stb04.nccom.nospam.com
remove the "obvious" antispam.
Straight Forwarrd Solution
Why not create a kernel patch of some sort that counts the number of RST / SYN packets within a particular frame of time, from a particular, source, with particular port... and even more simply perhaps, a series of, unexpected or even duplicate ISNs (spoofed and actual) from a particular source with different transmissions could be detected and with just enough delay possibly limit such attacks. (I could see how latency issues might prevent this particular one from working). Or even a patch, that on the receiving end would realize wheter the ISNs from a source are sequential or random after the first few packets, and at that point be able to determine further whether it is an attack or not based on likely schemes that such an attack might fall under. Correct me if I'm wrong, because though I'm interested, the above introduction to TCP is all I am basing this on, but aren't RST and SYN enabled packets only expected to occur once in a while? Not 28,000+ times with sequentially incrementing ISN from the same host? Please excuse my ignorance on the subject if this is not the case.
The nice part of this is that it doesn't have to become standard practice for immediate routers to work like the previous post about IPsec; it only need be implemented by those who have a concern and thereby limit such attacks to those from outside a network, especially with implementation of random source port selections.
Obviously I'm sure someone else with half a brain and even less knowledge of TCP would have alredy thought of such a solution, but I'm curious what, if anything you might have to add or comment.
SYN attack defence - is that problem curable?
If the IETF-proposed response to a SYN attack is to send an ACK (instead of the normal RST), and if this introduces the possibility of a Denial of Service against the outgoing data pipe or the remote end itself (by effectively making the local end a reflector), would it not be possible to throttle (or queue?) these special outgoing ACKs.
The downside of possibly not responding (during such an attack) to a genuine connection teardown by the remote end should not be too severe, since the connection would then time out... or be rejected when the remote end rejected continued traffic on the now defunct connection? Am I missing something? Is there a significant risk of connection "hijacking"?
Paul
Question --
One step that was taken for granted in this otherwise excellent description was that of getting your spoofed packet to the intended target host.
Is this easier than I think? Any attack that requires that the IP protocol be spoofed shouldn't be that easy to pull off against or by arbitrary hosts. My ISP isn't going to route packets with a source IP outside of it's subnet -- forget ACL firewall/L3 switches/filters that might /should be in place.
Or am I missing something?
--
Matt
few ISPs do source IP filtering
Few ISPs filter outgoing IP packets by source IP. So it's trivial to send spoofed packets. NANOG has had frequent and persistent discussions on this as well. There's no economic reason to do it.
Encryption anyone
What about encrypting the whole packet, except for the destination IP and port.. Assuming they have already authenticated to each other, then the encryption begins. The chance of getting pass the encryption would just not be feasable. I mean we are using encryption for wireless, and it doesn't take much processing, and best of all it means sniffers will have alot harder job, and there's nothing stopping you from encrypting the data before the packet is encrypted.
Even something as simple as encrypting the source IP and port would do the job.
You're describing IPSec
IPSec handles everything you're on about. It's too much for many routers though.
hello
hi all.
first i'm no expert on anything computer related. I do try to understand whats going on in my machine tho.
Anyway, suppose one were the subject of one of these attacks. How would it look? like if you were online and deided to look at who's attached to your ports. and saw several unknows ppl attached to various ports running an unidentifiable process in a seemingly suspended fin-ack state? like stuck waiting for the final ack but it never comes and they stay connected. would that be consistant with this type of attack?
not using 'sequence number +1', randomize
what would be the effects of occassionally randomizing the seq num being used. after every 100 packets, send one that gets the two hosts to work with new seq nums but not re-doing the 3 way handshake. so, with SN at 50, randomization/re-syncing will occur at 150. so even if the window is at 64K, SN=200 would be recognized as invalid by both hosts, irrespective of when it arrives.
ofcourse, if neither hosts' packets can be monitored (i.e. not lan) then this becomes a lot more effective.
-ve: this does have the opposite effect (reduces benefits) of scaling
absque3 @ yah...uk
Thank You
I'd like to thank Jeremy and Theo for an informative article concisely and clearly explained.
Pardon my ignorance - perhaps, along with the sequence number if there was a bit which had 2 states, 1 or 0 and worked in parallel with the sequence number, alternating randomly between states 1 or 0 by some predefined criteria within the stack, might tighten security?
A bit with two states? What a
A bit with two states? What an idea!
I'd say in general having a bit flip between 1 and 0 somewhere does not
increase security. Hey, if that would be the case, increasing security would be a no-brainer.
I think you mean you want to increase the number of bits in a sequence number. That would help, especially if you start with a good random initial sequence number.
It could be done, but not without breaking existing implemtations, I think. So that makes it unattractive.
TCP "Sniping" on 802.11
A friend of mine wrote a nice program a while back that was really fun to play with at coffee shops and the like. It's called p2pdie.c and p2pdie+.c has a nice gui that shows all active tcp connections and lets you snipe them with a pointer. I doubt there are many hosts that aren't vulnerable yet.
Using TCP Reset to OPEN a connection?
It appears to me that in some instances the attacker is not trying to CLOSE a connection but rather trying to use a TCP Reset to GAIN a connection. Note enclosed logs...
First example:
TCP Reset---spt=44405 dpt=38455
TCP Stealth--spt=15712 dpt=44405
Notice spt of first= dpt of second.
Second Example:
Notice dissimilar IP's used...and odd port scheme (notice port 38455?)
Third example...more of the same...slightly different IP from first Ex.
Apr 19 00:53:36 Sievette kernel: tcp reset IN=ppp0 OUT= MAC= SRC=74.52.1.58 DST=65.6.53.48 LEN=48 TOS=0x00 PREC=0x00 TTL=105 ID=32612 DF PROTO=TCP SPT=44405 DPT=38455 WINDOW=63176 RES=0x00 ACK SYN URGP=0 OPT (0204058401010402)
Apr 19 00:53:36 Sievette kernel: tcp stealth IN=ppp0 OUT= MAC= SRC=74.52.1.58 DST=65.6.53.48 LEN=48 TOS=0x00 PREC=0x00 TTL=85 ID=32612 DF PROTO=TCP SPT=15712 DPT=44405 WINDOW=63176 RES=0x00 SYN URGP=0 OPT (0204058401010402)
Apr 19 02:34:33 Sievette kernel: tcp reset IN=ppp0 OUT= MAC= SRC=63.223.77.241 DST=65.6.53.48 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=6354 PROTO=TCP SPT=80 DPT=38455 WINDOW=64240 RES=0x00 ACK SYN URGP=0 OPT (0204058401010402)
Apr 19 02:37:14 Sievette kernel: new not syn IN=ppp0 OUT= MAC= SRC=61.177.250.93 DST=65.6.53.48 LEN=40 TOS=0x00 PREC=0x00 TTL=111 ID=22835 PROTO=TCP SPT=7000 DPT=38455 WINDOW=0 RES=0x00 ACK RST URGP=0
Apr 19 05:21:56 Sievette kernel: tcp reset IN=ppp0 OUT= MAC= SRC=74.52.1.59 DST=65.6.53.48 LEN=48 TOS=0x00 PREC=0x00 TTL=53 ID=39585 DF PROTO=TCP SPT=44405 DPT=10520 WINDOW=64918 RES=0x00 ACK SYN URGP=0 OPT (0204058401010402)
Apr 19 05:21:56 Sievette kernel: tcp stealth IN=ppp0 OUT= MAC= SRC=74.52.1.59 DST=65.6.53.48 LEN=48 TOS=0x00 PREC=0x00 TTL=33 ID=39585 DF PROTO=TCP SPT=54572 DPT=44405 WINDOW=64918 RES=0x00 SYN URGP=0 OPT (0204058401010402)
Apr 19 05:21:56 Sievette kernel: new not syn IN=ppp0 OUT= MAC= SRC=74.52.1.59 DST=65.6.53.48 LEN=40 TOS=0x00 PREC=0x00 TTL=41 ID=0 DF PROTO=TCP SPT=54572 DPT=44405 WINDOW=5 RES=0x00 ACK RST URGP=0
Great!
Great explanation about TCP reset conection.
i'll use it and then i promise a new post with my conclutions!
Thanks in advice
Letras