On Jan 6, 6:44*pm, John John - MVP wrote:
karthikbalaguru wrote:
On Jan 6, 1:46 am, "Peter Foldes" wrote:
"John John - MVP" wrote in . ..
karthikbalaguru wrote:
On Jan 5, 8:37 pm, John John - MVP wrote:
karthikbalaguru wrote:
On Jan 5, 4:54 pm, Andrew McLaren wrote:
karthikbalaguru wrote:
I am eager to know the reasons for the raw socket
support in the Winsock interface during the initial
Windows XP release ?
http://msdn.microsoft.com/en-us/libr...48(VS.85).aspx
Thx for the link !
As per the link, the ability to send traffic over raw sockets
has been restricted in several ways in new Windows
releases after 'Windows XP with SP2' .
The reasons for the below changes w.r.t Raw Sockets
are not clearly mentioned in that link . Any ideas ?
1) TCP data cannot be sent over raw sockets.
But why ?
2) A call to the bind function with a raw socket is not allowed.
But why ? Any ideas ?
But, the below reason w.r.t raw socket & UDP datagram
support is clear -
3) UDP datagrams with an invalid source address cannot be sent
over raw sockets. The IP source address for any outgoing UDP
datagram must exist on a network interface or the datagram is
dropped. This change was made to limit the ability of malicious
code to create distributed denial-of-service attacks and limits the
ability to send spoofed packets (TCP/IP packets with a forged
source IP address).
It's all to do with security.
Okay. Agreed !!
But, why is this change not present in the
versions earlier to 'Windows XP with SP2' ?
It was changed by way of a security update after SP1 (but before SP2), but there
was a workaround that still allowed users to circumvent the security fix and still
allow traffic over raw sockets. *With SP2 it was decided to plug this workaround
too.
Why was this even present in the 'gold' or original RTM Windows XP version? *I
don't know, probably because it was thought that there was a legitimate use and
need for this, but maybe after Windows XP was released Microsoft might have had a
change of mind and decided that this feature should not be enabled on "client" or
"consumer" versions of their operating systems. *Before SP2 came about
embarrassing security flaws were being exposed on a regular basis and Microsoft
made an all out effort to plug a lot of holes in Windows XP, the word then was
that almost all other projects were on hold or slowed down while Microsoft
concentrated on security and worked on SP2 for Windows XP, even Vista's release
was pushed back while Microsoft worked at securing their flagship product.
For all it's worth Unix and Linux permit traffic over raw sockets and the Windows
server versions also allow this, although I'm unsure if Server 2008 still allows
it. *I think that it's probably just that with all kinds of bumbling users on XP a
decision was made to "protect the users from themselves" so they plugged up raw
sockets as a preemptive strike against possible exploits. *But that is just what I
think at this time... I don't know the exact reasons behind these decisions.
John John
W2K8 R2 does allow it but not W2K8 stand alone *except for the Enterprise version
Would cygwin also not support the Raw
sockets as Winsock has been is used by
it ?
Ask the folks in the cygwin help groups, they may know of a workaround.
Okay, I checked with cygwin help groups.
http://www.cygwin.com/ml/cygwin/2010-01/msg00183.html
But, i need raw socket for an application
that i am trying to execute from cygwin in
'Windows XP with SP2' & Vista . How can
this be achieved ?
Use a driver that doesn't use the Windows TCP/IP stack, maybe try WinPcap..
This seems to the right approach !
WinPcap for raw sockets in windows seems
to be the only only way out as of now !
In Iinux, it seems that there is restriction at
user-level (root/normal user) to use the raw
sockets. So, it was not a problem.
That is also sort of how NT4/Windows 2000 and Windows XP Pro did it, it
was/is only allowed with administrative privileges. *But for SP2 and
later it was plugged for all users on XP.
I wonder how linux is secure without plugging
off while windows had to plug off to be secure !
Thx,
Karthik Balaguru