Penetration and Spoofing

Started by
13 comments, last by nes8bit 23 years, 3 months ago
No no. This isn't for some stupid mIRC crap. Anyway, if I were to establish a connection to a server and the server was for peer to peer connections kind of like napster. Would it be possible to have clients send data directly to each other through the open port? This is where the spoofing comes in. Basically it will disguise the packet as a server packet, but the client will know it's from the other client. Let me show you a diagram. client--<-->-server-<-->---client        \               /  <- spoof here        &nbsp----->-------/ The server would normally handle the file transfers, but that would require a lot of bandwidth. Now, would this work...for computers protected by a firewall? Is this legal? --------------------------- "Be like china! Use linux!" - TANSTAAFL Edited by - nes8bit on January 26, 2001 4:53:34 AM
Advertisement
I''ve finally got my server running again at
http://therabbithole.redback.inficad.com

That''s one of my security concerns. If a client were to access another client directly and send bogus packets the client could be rendered temporarily unuasable.

I''ll try it out this weekend and let you know if know one responds first.

Ben
@KalvinB: Clients would only be able to do that if you give them the other clients'' IP addresses. You don''t necessarily have to do that (depending on what you want to achieve)

@nes8bit: What you''re talking about isn''t really spoofing. The way you do it is simply:
- create a socket on a given port; dup it (this would work differently depending on the OS/sockets implementation/protocol type you''re using)
- one of the sockets will connect to the server
- the other one will be a listening socket

The server simply relays IP/Port pairs to clients that wish to share files who then connect to that given IP/Port pair. That''s not really spoofing.
This might work behind firewalls depending on the firewall setup. Some firewalls might allow incoming connections on IP/Port-pairs that are associated with outgoing connections.. not sure on that.
There are no issues with legality at all - after all, the user wants the program to do what it does. However, it''s always good to add those annoying "I SHALL NOT BE MADE LIABLE FOR ANYTHING THAT HAPPENS TO YOU WHILE USING OR NOT USING THIS SOFTWARE" clauses in your license

An entirely different topic is the protection against IP spoofing by hackers. If you''re using TCP/IP you don''t have too much to worry about because of the SEQ number the protocol has (you''re never 100% safe, mind you). If you''re using UDP/IP you''re on a connectionless packet, i.e. you have to make sure the incoming packets are valid yourself.

cu,
Prefect

---
Sanity is the trademark of a weak mind.
Widelands - laid back, free software strategy
Um. I was not talking about having the client create another connection to the client. Basically one client will send a packet to the other client through the open port. Both clients will have ports designated for the server only, but I was thinking that I could send out a packet that was from one of the clients, to the client''s port that is connected to the server. Basically this would be like sliding a little "juice" into the punch. Let me try and make a better explanation.

Computer A connects to the Server. Computer B connects to the Server. Computer A requests to download a file from Computer B. the Server notifies Computer B and Computer B sends out packets with a certian ID attatched to the packet to Computer A. Computer A will know that it is from Computer B, but the IP says it''s from the Server to keep the firewalls happy and such.

---------------------------
"Be like china! Use linux!" - TANSTAAFL
So you''re saying you *want* to spoof?

Yes you can do it. Most socket interfaces let you use raw sockets. With raw sockets you''re typically bypassing the whole TCP/UDP/IP stack and talking directly to the hardware layer (ethernet or whatever). You can make up some packets that have whatever you want in them - including otherwise normal IP packets with spoofed source addresses. Unfortunately the interface to and various restrictions on using raw sockets is often very poorly documented and varies from system to system. At the very least you typically need to be an admin on the machine.

You could still get into trouble with firewalls if B''s firewall didn''t allow spoofed *outgoing* packets. A firewall admin might do this to prevent the possibility of an internal user do something underhanded.

Legal as in possible? Yeah. Legal as in you don''t want cops kicking your door down? Still yeah as long as you''re not trying to commit fraud.

-Mike
Isn''t there a way to NOT bypass the basic networking protocol such as TCP/IP or UDP? (I''m using TCP) I''ve seen ways on how to do it in *real* winsock headers, but I don''t want to waste time on trying it.

Also, I didn''t think of the firewall on Computer B being a pain. That could pose a problem.

---------------------------
"Be like china! Use linux!" - TANSTAAFL
The only reason you''d need to do something like this is if both of the clients are behind firewalls (dynamic NAT).

You may want to look into supporting Socks proxies, it would let you accomplish this - but requires the users to have a functional Socks proxy server... this is how mIRC does it (albeit with limited success - but some success).


There''s a good chance that the firewall would not even recongize the a packet as spoof, but it *will* recongize that it doesn''t belong in that subnet and will likely drop it.
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Does anyone have anything on Socks proxies?

Umm...I''m trying to anticipate the worst. Like firewall->firewall connections.

---------------------------
"Be like china! Use linux!" - TANSTAAFL
screw it.

---------------------------
"Be like china! Use linux!" - TANSTAAFL
Why would you want to spoof? Just send a commnad packet to the 2 pertient clients to connect to eachother and exchange data. If your using TCP_IP only, almost all firewalls handle this transparently. Its UDP which has problems with firewalls mostly, and in this case it doesnt seem UDP is relevant, as a reliable bulk data transfer protocol you want to use would be TCP_IP.

One could say your turning one of the clients into a download server. Servers are sometimes forbidden under the service contract which some cable companies make their users sign when they get the service. I dont know the fine print, you might want to look into that.

Good Luck

-ddn

This topic is closed to new replies.

Advertisement