Network Flooding

[deadly7]

You need to initiate a connection first... and if you send a SYN packet with the spoof source address of Battle.net, it's going to send a RST back to Battle.net..

Not if theres nothing to be responded to. IIRC, a client doesn't send back SID_IRecievedYourBroadcastAndImLettingYouKnow. =p

TCP != UDP.

You can't send a packet to a computer and assume it'll get there. Because you can't send the packet in the first place without initiating a connection (via SYN).

The server has to acknowledge your syn (through SYN/ACK sent back to you).

So is that how SYN/ACK floods on servers work?  You send a massive amount of data to a website, and it responds back to each and every request/packet sent, thus killing the bandwidth?

[rabbit]

You need to initiate a connection first... and if you send a SYN packet with the spoof source address of Battle.net, it's going to send a RST back to Battle.net..

Not if theres nothing to be responded to. IIRC, a client doesn't send back SID_IRecievedYourBroadcastAndImLettingYouKnow. =p

TCP != UDP.

You can't send a packet to a computer and assume it'll get there. Because you can't send the packet in the first place without initiating a connection (via SYN).

The server has to acknowledge your syn (through SYN/ACK sent back to you).

So is that how SYN/ACK floods on servers work?  You send a massive amount of data to a website, and it responds back to each and every request/packet sent, thus killing the bandwidth?

What are you blabbing about?  Everyone knows it's good old magic what with the magicness and all.

[Quik]

You need to initiate a connection first... and if you send a SYN packet with the spoof source address of Battle.net, it's going to send a RST back to Battle.net..

Not if theres nothing to be responded to. IIRC, a client doesn't send back SID_IRecievedYourBroadcastAndImLettingYouKnow. =p

TCP != UDP.

You can't send a packet to a computer and assume it'll get there. Because you can't send the packet in the first place without initiating a connection (via SYN).

The server has to acknowledge your syn (through SYN/ACK sent back to you).

So is that how SYN/ACK floods on servers work? You send a massive amount of data to a website, and it responds back to each and every request/packet sent, thus killing the bandwidth?

Not quite, and off topic. If you want to ask the entire community and open the subject to conversation, please create a new thread. Otherwise, please contact someone personally about it for an explaination.

[Eric]

You need to initiate a connection first... and if you send a SYN packet with the spoof source address of Battle.net, it's going to send a RST back to Battle.net..

Not if theres nothing to be responded to. IIRC, a client doesn't send back SID_IRecievedYourBroadcastAndImLettingYouKnow. =p

TCP != UDP.

You can't send a packet to a computer and assume it'll get there. Because you can't send the packet in the first place without initiating a connection (via SYN).

The server has to acknowledge your syn (through SYN/ACK sent back to you).

So is that how SYN/ACK floods on servers work?  You send a massive amount of data to a website, and it responds back to each and every request/packet sent, thus killing the bandwidth?

Usually the goal is to max out the number of possible outstanding connections thus preventing any future connections from taking place or in older computers, causing a buffer overflow, however quite a bit of bandwidth does get consumed in the process.

[iago]

To elaborate a little more on what LoRD said:

SYN = Synchronize
ACK = Acknowledge

The initial TCP connection to a computer, affectionately known as the "three-way handshake", goes like this:
You send a SYN packet to a computer, which is like saying, "Are you there?"
The computer responds with SYN/ACK, which is like saying, "Yes, are you?"
Finally, you send it just ACK, which is like saying, "Yes, thanks"

(Think about that commercial for some wireless company, "Can you hear me now?" "Yes" "Good.".  It's basically the same thing)

Every time a SYN packet is received, the computer gets ready for a new connection.  It allocates some space, initializes some variables, and whatever else it has to do. 

If you send it lots of SYN's all at once, it's going to take a lot of processing time/space to look after them all, and often, they start to get dropped.  If you continually send it lots, when a legitimate connection is made, the legimate connection might be dropped (ignored) because it just doesn't have enough space to process it all. 

One nice thing about this attack is that you don't actually need to send it with the proper return address.  If you forge the return address, then the computer you're sending the SYN to will still build the connection, but it will reply with the SYN/ACK to the wrong place.  But who cares?

As LoRD said, the idea ISN'T to consume bandwidth, it's to consume resources by trying to build lots and lots of connections. 

[Joe]

*rubs hands together*

Sounds fun.