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
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
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/).