Raw mode is basically there to allow you to bypass some of the way that your computer handles TCP/IP. Rather than going through the normal layers of encapsulation/decapsulation that the TCP/IP stack on the kernel does, you just pass the packet to the application that needs it. No TCP/IP processing -- so it's not a processed packet, it's a raw packet. The application that's using the packet is now responsible for stripping off the headers, analyzing the packet, all the stuff that the TCP/IP stack in the kernel normally does for you.
A raw socket is a socket that takes packets, bypasses the normal TCP/IP processing, and sends them to the application that wants them.
Unless you're a programmer, a kernel hacker, or really really into security, you will most likely not need to deal much with these. But it's good to know what they are, in case you find yourself in one of the above scenarios.
> I'm still a bit confuzzed by something though. If raw mode packets are > not passing through the normal tcp/ip encapsulation bizzo, then > how/what/who is encapsulating the packet with the headers that include > (amongst all the other info) destination address, and the checksum > footers?The application that takes the data from the raw socket has to do it. It puts a lot more responsibility on that program to create correctly formed headers, etc. It's not that those headers don't get created -- if they didn't, you're right, the packet wouldn't be able to go anywhere. It's that they get made by the program taking data from the socket, rather than the TCP/IP stack in the kernel.
Most programs find it easier to let the kernel do their packet mangling for them. But a lot of security programs can use raw sockets and write their own packets. The TCP/IP stack in the kernel is written so that it makes good packets, and sends out good packets appropriate to the connection. But sometimes (stress testing, nmapping) you want to make bad packets, to see if your remote system can handle that without erroring horribly. For things like this, you want to bypass the kernel's TCP/IP stack.
> I am reasonably familiar with the normal 7 layer osi model, and am > curious how something bypasses this (esp the network layer).It doesn't bypass IP. It's just a matter of which program writes the packet headers. Normally it's the kernel. With raw sockets, it can be something else. RavensPacketMakerDaemon or whatever the programmer chooses to write.
> That makes much more sense too now about the winxp raw sockets issue....Exactly. For those of you that hadn't seen it in the news a few months ago, there was a big to-do when WinXP was released. For the first time in a Microsoft OS, you had the capability to use raw sockets, and that means you have the ability to make any kind of packet you want, even if it's a bad one that the normal TCP/IP stack would never produce. Unix has had this capability for ages.
There were some security folk that were convinced that the number of spoofed packet and bad packet attacks would increase astronomically now that Windows users could do it too. (The idea, I think, was that there are lots of script kiddies out there who don't speak Unix, and so couldn't make bad packets to attack people with. With the power to do this now built into Windows, it would be easy for a Win programmer to make a GUI packet-crafter front end, and thus give script kiddies a powerful new tool.) In particular, Steve Gibson raised the roof about it.
That's his edited reply. [grin] He backpedaled a lot from his original "raw sockets are evil, Microsoft is destroying the Internet" position. It's almost funny.
I haven't heard of any great increase in spoofed or bad packet attacks since, so it doesn't appear to have been a great problem. So far. [grin]
As with many security tools, the problem is that the knowledge that can be used to protect and defend is pretty much the same knowledge that would make one a formidable attacker. Tools like nmap or Dan Farmer's SATAN ( http://www.cerias.purdue.edu/coast/satan.html) and its spinoff SAINT ( http://www.saintcorporation.com/saint/) generally spark a huge argument about the ethics of such security tools.
Copyright (c) 2002 by Raven Alder. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).