הבנתי שאי אפשר להיות מוגן 100% אבל יש פתרונות למיזעור הנזק
שמעתי שיש דבר כזה SYN COOKIE אני אשמח אם מישהו יתן לי הסבר איך זה עובד
?
ואם הווינדוס לא מוגן... האם זה יכול להיות כזה פשוט לנתק מישהו?
להציף אותו ב SYN ATTACK עם SOURCE מזוייף ?
ראשי > אבטחת מידע > הגנה מפני SYN ATTACK
הבנתי שאי אפשר להיות מוגן 100% אבל יש פתרונות למיזעור הנזק
שמעתי שיש דבר כזה SYN COOKIE אני אשמח אם מישהו יתן לי הסבר איך זה עובד
?
ואם הווינדוס לא מוגן... האם זה יכול להיות כזה פשוט לנתק מישהו?
להציף אותו ב SYN ATTACK עם SOURCE מזוייף ?
"The three way handshake" ->
Since certain things, by the RFC, require certain responses/actions we can "play" with them. The RFC requires that if you receive a SYN packet to an open port you must open a Transmission Control Block, (the thing that tracks the "conversation"). So if I send you a SYN, you have to open a TCB, if I send you 2 SYN’s you have to open 2 TCB’s.... 100 SYN’s = 100 TCB’s - If you don’t do it then you limit your ability to receive/manage connections from the ’world".
So, Let me "mess with" the SYN packet.... Please....
I have a few choices.... I can:-
1. Keep sending you SYN packets to your open port(s), (SYN flag set), your OS has to set aside a TCB for each connection.... Well... If I send you enough of them with or without sending the required ACK your system will be "flooded" with connections that require memory to maintain the information.... Eventually, I will slow down or drop your system by filling the system with bogus SYN requests that require resources to maintain. It’s called a SYN Flood and is a form of Denial of Service attack, (D0S). If I use a lot of machines to do this it’s a form of Distributed Denial of Service attack , (DDoS).
2. Or I can send you a single SYN let you respond and send an RST. It’s called a half open or stealth connection. I would use it to determine your OS. Different OS’s implement the TCP protocol slightly differently. They may respond correctly but they may set other parameters in the packet in a certain way that differs from other OS’s. If they do then the subsequent response may tell me about your OS yet show no completed connection... So your logs might not show a connection... they may show nothing.... But that would be a bad..... and most modern logging systems aside from the service logging itself will log SYN packets thus showing this scan.
3. I can "spoof" my IP address.... If I send you a SYN you will reply to the source address with a SYN/ACK on an open port. So I tell you Bill is trying to contact you, But I’m Joe.... You respond to Bill because that’s who you think called you.... So you respond to Bill with a SYN/ACK... Ooops..... Poor Bill is getting these unrequested responses.... He must send a RST, (reset, because the connection wasn’t for him in the first place)... Can we exploit that.... I think so... If we employ enough machines to keep sending him "odd" connections he has to respond... That’s a Relfected Distributed Denial of Service attack, (RDDoS).
4. I can spoof my IP to a machine I control and send you a SYN. Again, you will respond with a SYN/ACK to the machine I control. I can sniff the packets coming inbound from your IP and determine what ports you have open and make an OS guess too. Some people refer to this as a blind scan. I can take it further and not even have control of the machine. If I _know_ the machine is idle then I can send a SYN with the IP spoofed to the idle machine. The target will send a SYN/ACK to the idle machine if the port is open or a RST if it is closed. If the port is firewalled nothing should be sent. I can then send a SYN to a port I know to be open on the idle machine. By looking at the sequence number in the TCP packet I can see if it incremented between my last attempt and this one. If it did then the target machine sent a SYN/ACK. How do I know? Because the RFC states that an unsolicited SYN/ACK should be responded to with an RST but an RST should not be replied to. So if the sequence number has incremented a SYN/ACK must have been sent. If the port is closed or firewalled then either an RST or nothing was sent thus the sequence number wouldn’t need to be incremented.
Thats a few ways we can "abuse" the SYN flag... We can go to the other end of the conversation and cause some problems too.
credit - TigerSharkf @AO.
Edit:
This is TigerSharks txt of @AO I published it here, I
haven’t edit nothing from it, it’s his, ihni why I wrote "&myself", probably a typo.
sorry, won’t happend again.
phax
[ההודעה נערכה על-ידי phax ב-25/12/2004 21:22:37]
אי אפשר להיות מוגן מאה אחוז, אבל אתה יכול פשוט להגדיר את הפיירוול שלך להתעלם מאותה הכתובת, וככה המערכת שלך לא תנסה להחזיר את הSYN/ACK, אבל עדיין- אם יש מספיק שרתים והם מהירים, אתה עדיין תקרוס.
בכדי להגן על המערכת מפני זה צריך להדגיר אותה להתעלם מאותה הכתובת ע"י פיירוול, וככה היא לא תחזיר להם Syn/Ack - וככה החיבורים לא יתקדמו וזה לא ישפיע עליה.
ואם הוינדוס לא מוגן? בעזרת מחשב יחיד אני מאמין שזה לא יעזור לך, אבל בעזרת הרבה מאוד מקורות- היא אכן תקרוס.
Phax, מצטער, אבל אני מכיר את הטקסט המקורי, וכתב אותו לTiger Shark...
,מאיפה זה בא:
"credit - TigerShark&myself"
(אם אני טועה- תקן אותי).
?
[ההודעה נערכה על-ידי cp77fk4r ב-25/12/2004 18:34:38]
אני שאלתי על דרכים להתגונן ..שמעתי על SYN COOKIE אבל לא ממש הבנתי איך זה עובד ..על זה הייתי שמח לקבל הסבר..CP אני לא חושב שיעזור שהפייוואל יתעלם מ IP מסויים כי אם התוקף כל פעם ישנה את הסורס של הפאקט הפיירוואל לא ממש יהיה אפקטיבי..אולי אפשר להגביל את ההתחברויות בזמן מסויים אבל זה יאט את המהירות אני משער...
להגביל את מספר ההתחברויות באותו הזמן יעזור, אבל גם יגביל אותך...
אם תגביל את מספר ההתחברויות שאפשר לפתוח ב3 שניות למשל- זה יוכל להיות יותר אפקטיבי.
welp, denial of service... *sigh*...
actually preventing DoS attacks at the host... is pretty much impossible, at least I don’t know of any solution.
however, you can mitigate:
1. decrease connection timeouts
2. increase listen queues
3. Use syn cache buckets
4. Use syn cookies
syn cookies... assuming you’re familiar with tcp. I’ll try to simplify:
1. Client sends a SYN
2. Server responds ACK,SYN - now server puts a "cookie", a specific hashed value as the ISN (some OS’s implement it different), and waits for that hash value to be returned in the next ACK from the client,
if it won’t get back, the connection is not legit
you can simply google for "syn cookies" and see how its implemented... or check out the linux/BSD kernel documentation/source :)
these are the most common techniques to specifically deal with SYN attacks - host level.
but! you can also use a very nice feature of cisco IOS, called intercept (it kills the CPU/memory though):
When the client initiates the 3-way handshake, the router establishes the connection on behalf of the client, if the connection is legit, it will establish the connection on behalf of the server and then transparently merge both connections.
but, no.2 !
we are in modern times... there are now FIN attakcs :) and all kinds of new mutations, therefore, when dealing with high bandwidth DoS/DDoS attacks, none of this will help you. the only solution is at the ISP level (assuming the ISP has a shit load of bandwidth to handle this), this is a very interesting field called anti-ddos: creative solutions, expensive devices.
I would love to explain how they work... but this response is getting too way long :)
cheers!