On Thu, Nov 5, 2009 at 9:20 AM, David Demland <
demland@cox.net> wrote:
> I am working on a lesson for my security class to show them how a SYN
> Flood works. I am using C# and I am having some problems with the RAW Socket
> working properly. Does anyone have any background in this area to help me
> out?
>
>
>
> Thank You,
>
>
>
> David Demland
>
> Hi David,
A SYN flood attack exploits an inherent weakness in the TCP/IP protocol.
Properly establishing a new TCP socket requires a three-step process. Here
it is at a high-level:
1.
The source of the connection (the originator, such as a web browser)
initiates the connection by sending a SYN packet.
2.
The destination (receiver of the SYN request) responds by sending back to
the source a packet that has the SYN and ACK flags set (a “SYN/ACK packet”).
3.
The source acknowledges receipt of the second packet (SYN/ACK) by sending
to the destination a third packet with only the ACK flag set (an “ACK
packet”).
Once this three-way handshake is complete, the TCP connection is considered
“open” and data can be sent to and fro on that socket. Between steps 2 and 3
of the handshake, the destination must keep a record of the connection that
is being established. At that point it is still incomplete and waiting for
the final ACK packet from the source. Most systems have only a limited
amount of memory for these tables. If too many connection attempts are left
in this incomplete state, the destination (web server, for instance) will
run out of space waiting for completions of what it has stored in an
incomplete state. At that stage requests for new connections from legitimate
entities cannot be serviced and will be lost. Most TCP/IP implementations by
default impose a relatively long timeout period (several minutes) before
incomplete connections are cleared out.
What was just described represents a SYN Flood. During the attack, a large
number of SYN packets alone are sent to the destination. These requests will
never have the corresponding ACK responses and the victim’s TCP connections
table rapidly fills with incomplete connections. This will not allow
legitimate traffic to be serviced; hence the denial is in effect. The
technique usually implements a rate of attacking SYN packets that far
exceeds normal traffic; hence the flood. So even when the target’s
connection table is cleared out, another attacking SYN packet, as opposed to
legitimate ones, will fill it.
Are you using a patched version of Micro$oft:
http://www.builderau.com.au/news/soa/Microsoft-tries-to-quell-TCP-IP-danger-/0,339028227,339186600,00.htm
If you are using Linux (check the kernel settings for SYN FLood protection):
http://stackoverflow.com/questions/1116225/refusing-connection-from-a-host
http://www.cyberciti.biz/faq/tag/syn-flood-attack/
Have you checked some of the online code examples of using raw sockets like:
http://www.koders.com/c/fidF7B8ACF1A2A71A79739F18F3E899C2AB650BCC6F.aspx
And What is the error please?
--
Skype: (623)239-3392
AT&T: (503)754-4452
www.obnosis.com
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)