mysterious ...
mysterious ...
i was watching round some server's , and found this module in one server , couldnt figure it out which module it could be , any idea any one ? or where could i get it ?
[21:43] -irc.something.com- *** ipcheck (anti ip spoofing) [3RD]
i.e - Yes they r using unreal3.2.3 .
[21:43] -irc.something.com- *** ipcheck (anti ip spoofing) [3RD]
i.e - Yes they r using unreal3.2.3 .
-=GouroB=-
https://www.shunno.info
Your complete web Solution
Irc.BanglaCafe.com
LargesT Chat server in BanglaDesH
https://www.shunno.info
Your complete web Solution
Irc.BanglaCafe.com
LargesT Chat server in BanglaDesH
-
- Head of Support
- Posts: 2085
- Joined: Tue Jun 15, 2004 8:50 pm
- Location: Chino Hills, CA, US
- Contact:
Unreal already has something that checks for spoofed IP's. It is called NOSPOOF, and is enabled on windows by default. If you want this kind of check in your IRCd, enable NOSPOOF in ./Config.
The way you check for spoofed IP's, is you send a PING to the client before it fully connects. The way Unreal knows if the IP is spoofed or not, is because a spoofed IP cannot send data to the IRCd. (I think I got that right... If not, close enough)
The way you check for spoofed IP's, is you send a PING to the client before it fully connects. The way Unreal knows if the IP is spoofed or not, is because a spoofed IP cannot send data to the IRCd. (I think I got that right... If not, close enough)
Don't have much to add to what Stealth said, but...
Since Unreal does indeed this (or can do it), it doesn't make sense (nor is it easy, in fact it is hard) to make it a module, therefore it might well be that the module does something different than the name suggests or something different than we are thinking :p.
Never heard of the module either btw / I didn't code it ;p.
Since Unreal does indeed this (or can do it), it doesn't make sense (nor is it easy, in fact it is hard) to make it a module, therefore it might well be that the module does something different than the name suggests or something different than we are thinking :p.
Never heard of the module either btw / I didn't code it ;p.
-
- Posts: 44
- Joined: Mon Jan 24, 2005 6:10 pm
-
- Head of Support
- Posts: 2085
- Joined: Tue Jun 15, 2004 8:50 pm
- Location: Chino Hills, CA, US
- Contact:
The PING sent is not a WAN ping, but an IRC PING:
Thanks aquanight for the debug info because I was lazy.
The red is the PING sent by the server. Spoofed IP's cannot send this back, so they just ping timeout.Debugged server stuff... wrote:<- :irc.blah NOTICE AUTH :*** Looking up your hostname...
<- :irc.blah NOTICE AUTH :*** Checking ident...
<- :irc.blah NOTICE AUTH :*** Received identd response
<- :irc.blah NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
<- :irc.blah NOTICE aquanight :*** If you are having problems connecting due to ping timeouts, please type /quote pong 9C02BFA or /raw pong 9C02BFA now.
<- PING :9C02BFA
Thanks aquanight for the debug info because I was lazy.
-
- Posts: 44
- Joined: Mon Jan 24, 2005 6:10 pm
Correction: it's not that they can't send it back - it's that they don't know WHAT to send back. In a spoofed IP attack, the attacker can't receive anything from the target, so he must rely on blindly sending the TCP connect packets (which is broken with things like syncookies), and sending the required IRC messages. In theory, an attacker could connect and start guessing the correct PONG token, but he has ~90 seconds (I think) before the server drops the connection, and because of IRC's "5 commands per 10 seconds" rule, that means he only gets ~45 tries. And the pingcookie is a 32-bit integer. That's > 4 billion possible pingcookies.Stealth wrote:The red is the PING sent by the server. Spoofed IP's cannot send this back, so they just ping timeout.
(So, with NOSPOOF an attacker has a 0.000001047737896442413330078125% chance to establish a connection. Without NOSPOOF, he has a 100% chance to establish a connection. (Assuming you don't have syncookies or similar.) I'd certainly say that's worth it :) .)
Actually syncookies got not much to do with this, they are only used in case of a SYNflood (and are an effective means to deal with that).
I'm just saying that, so nobody thinks like "woah I got no syncookies, I'm not safe" (or the opposite: "I've got syncookies, so I am safe").
It's all about the ISN (Initial Sequence Number), for some unknown reason Microsoft has trouble making it properly random -- or more likely: they simply didn't care. Over the internet (so when I'm restricted to a 64kb/s upload) I can spoof a nt/9x connection within 1 second, and 2k/xp within 15 minutes (15mins == max, usually sooner).
Most common *NIX'es have had ISN problems, but fortunately they have been solved years ago. It seems m$ only fixed this issue in w2k3.
Lot of uncommon OS's (such as proprietary routers with their own OS, or non-mainstream OS's) still continue to have ISN problems today.
I'm just saying that, so nobody thinks like "woah I got no syncookies, I'm not safe" (or the opposite: "I've got syncookies, so I am safe").
It's all about the ISN (Initial Sequence Number), for some unknown reason Microsoft has trouble making it properly random -- or more likely: they simply didn't care. Over the internet (so when I'm restricted to a 64kb/s upload) I can spoof a nt/9x connection within 1 second, and 2k/xp within 15 minutes (15mins == max, usually sooner).
Most common *NIX'es have had ISN problems, but fortunately they have been solved years ago. It seems m$ only fixed this issue in w2k3.
Lot of uncommon OS's (such as proprietary routers with their own OS, or non-mainstream OS's) still continue to have ISN problems today.
I thought the algorithm itself was not always enabled but that it 'kicks in' when needed. That would be because the algorithm has various limitations that can cause it to drop legit connections (uncommon MSS/window size, fun stuff). I could be mistaken though, so feel free to read the kernel source ;).
While googling around a bit I got reminded by this nice freebsd security advisory from 2003.. It's always fun when a certain feature to "improve" security (in this case: protection against a synflood attack) results in quite the opposite (less security, full blind spoofing capabilities) ;).
m$ is not the only one that is good at that :P.
While googling around a bit I got reminded by this nice freebsd security advisory from 2003.. It's always fun when a certain feature to "improve" security (in this case: protection against a synflood attack) results in quite the opposite (less security, full blind spoofing capabilities) ;).
m$ is not the only one that is good at that :P.
I dunno... somehow that just doesn't make sense - wouldn't that in theory allow a few spoofed connections before syncookies kicks in?Syzop wrote:I thought the algorithm itself was not always enabled but that it 'kicks in' when needed.
As for actual practice, I actually tried looking at my linux sources (fun!), not really much I could determine there, but looking at the config help stuff, it seems it has to be "turned on" manually (echo 1 >/proc/sys/net/ipv4/tcp_syncookies) at least on linux 2.6 - fun stuff! (Though, I don't have syncookies enabled at all, since the box is unconnectable I figure it "isn't a high priority" :) .)