nmap has a decoy option that can be used to give different ip addresses as source ip.
I was wondering how this works, as what i know packets are routed based on their source and destination ip address so when we send a packet with a different ip as source how does the answer gets back to us ?
Is this option works on a single broadcast domain or can it be used across the internet too?
Any link to a document or website about how this works will be great, thanks
I was also looking for the answer to this question. I thought of leaving what I found with a quick search.
how does the answer gets back to us ?
We are not interested in getting all the SYN,ACK replies back to us. We only need that one reply that comes back to the attacker's IP to figure out that the port is open. The primary purpose of the decoy is to confuse the IDS on the target site. If there are 10 different clients sending TCP SYN to the server, it wouldn't be easy to find who is the attacker, and who are the innocent clients.
Yes, the responses will be going back to the decoy addresses. That is why the following article says to make sure the decoy addresses are also alive because if they are not, the pattern of handshake will be different for the attacker and the dead decoy addresses, which the victim may be able to figure out and pinpoint the attacker's IP.
https://nmap.org/book/man-bypass-firewalls-ids.html
Is this option works on a single broadcast domain or can it be used
across the internet too?
I don't see any reason why it should be from the same subnet. It can be any IP address(es)
Related
The path an IP packet takes up the network "tree" is pretty clear to me (or so I think):
Am I in the right network?
No: Forward to the gateway address.
Yes: Go to the final destination address.
Am I there yet?
No: Repeat step one.
Yes: Done!
This only really accounts for going up the network. I'm not sure how to reconcile this with getting back down, say across the internet through all the gateways in between two personal computers. I know about NAT, so a gateway can receive a packet intended for it, and forward it to a device on its network, but that's surely not the whole story - for example, what if is no NAT (perhaps with IPv6)?
It would seem routers would need tables to guide packets to the right branches, (alternative destination instead of another gateway), and that top level internet routers would need huge tables to reliably route packets.
Well for the most part that is the case, you have huge routing tables that help route a packet from source to destination.
I'm not really sure what you meant by "going down the tree", but in the end of the day your private router at home get's a unique IP address from your ISP.
Your router probably doesn't have a specific route for a packet destined to facebook servers, but it also has a default gateway.
This means you'll keep getting through default gateways until your packet reaches a router that doe's know the specific router for a destination IP of a packet.
When the packet (let's say from facebook servers) get's back, the destination would be the unique IPv4 address (or IPv6, but we'll focus on 4) of your router.
Again it would go through all the default gateways, until reaching some router that knows what to do with the destination IP.
To help with routing, there are few predefined rules/ranges of addresses for each country/organization, and that helps route packets to/from them over the internet.
Btw, between the same organization. a lot of times they use tunneling - which i recommend reading on since it might help you get an even better understanding on the topic.
I'm trying to develop an applicaton for p2p communication between two android devices. In order to punch a hole through my NAT(s), I'd need to know my external ip address and port.
To that end, I've developed a java server on GAE to report my "remote" ip address and port. The problem is that on GAE I can get my ip address, but not my port. Without it, I'm unable to successfully punch the hole.
So, my question is what's the best, free method to find out my external IP address and port?
That's a question that has no answer with TCP.
Here's the problem: your "port" is not a fixed value. You don't have "an" external port. You typically get one dynamically assigned for each outbound connection.
As answers you should see from the test sites posted in another answer clearly indicate, it's a moving target (though it may stay stationary for a short time due to the browser using HTTP/1.1 keepalives and actually reusing the same connection, not just the same port)... but if you hit the site repeatedly, you'll see it either drift around randomly, or increment. Trying it from two different web browsers on the same machine, you'd never see the same port number -- the port corresponds to the specific source connection, not the machine sourcing the connection.
Sometimes, you may find that it's the same port number as the port your machine's stack opened for the outbound connection, but even when it is, it doesn't matter, because no traffic should be able to return to your machine on that port unless it is from the IP address and port of the machine to which you made the outbound connection. Any decent network address translating device would never accept traffic from another source IP address and/or port, other than the one you addressed in the outbound connection.
There is no standard, simple, predictable, reliable, or consistent way to punch a hole in TCP NAT and then exploit that hole for a peer-to-per connection. To the extent that such things are possible in a given NAT implementation, that is an implementation that is shoddy, broken, defective, and insecure.
See also: https://www.rfc-editor.org/rfc/rfc5128
Sounds like your app could use a STUN server to get its external address.
What I need is quite the same asked here, I don't understand the answer too well, because of my knowledge, so maybe someone could help me.
What I'd like to do is using the connected user's IP address (Client IP) to make the server-side HttpWebRequest, so I would grab the user's IP and make the call with it.
What I'd like to obtain is that every connected user makes HttpWebRequests with their IP.
Is it possible?
If it is, how should I edit that code to do this?
Thanks.
This is impossible. My answer to the other question was about selecting which IP Address (read: network adapter) to use for a request. However, you cannot invent IP Addresses out of thin air, nor use IP Addresses that are not yours (in a physical, attached-to-this-computer sense).
Now, technically, using Raw Sockets, you can spoof another IP Address in your packets. However, the problem with that is that the return traffic will go to the IP Address you specify, not the one you actually have!
So, my advice is to not pursue this line of thought any further, and find another way to do whatever it is that you are trying to do.
You may only make outbound connections from your server using an IP that is assigned to the server. If you tried to use a client's IP, it would fail.
Even if it did not fail, it would be a form of spoofing and would fail pretty qucikly anyway- the handshake that occurs using tcpip would case the remote connection to send an acknowledge packet back to the source ip (in your case, the client ip) which would result in an error.
If you are using UDP, it actually is possible to do this, but that is a different subject.
Is it safe to restrict access to a site by IP?
I know there is something called "IP spoofing" - does this mean that (under some conditions) IP restriction is not accurate?
If a client forges its source IP address, it will be very difficult to establish a TCP connection, because as #cdhowie noted in a comment below, the client would need to ACK the server's SYN + ACK back, which it will never receive.
Spoofed IP addresses are mostly dangerous for denial of service attacks, as the attacker would not care about receiving responses to the attack packets, and they would be much more difficult to filter since each spoofed packet appears to come from a different address.
Not really. First, you would need to restrict all proxies, too, to be effective. More importantly, you may block legitimate users like this. It can be a quick-fix for some chronic issues, but in general it's not as effective as it seems.
IP Spoofing is mostly possible on LAN. In my opinion it is not possible to restrict access to site per IP. I would rather consider applying some certificates/auth methods.
Here is an example. Read some theory here
I've noticed recently that I don't have to forward ports for mmorpg's that I play.
I'm thinking about working on a game that people can play online and had a question.
Why is this the case given its a two way socket connection that is constantly sending data back and forth? Doesn't their server need to get through my firewall in order to connect to me?
TCP crash lesson: TCP is a two-way protocol. The challenge is that at least one host needs to initiate. Since within an MMORPG, your own computer is never acting as a server, nobody has to connect to it. All the information about game state is passed through the company's public facing servers that have public facing IP addresses (and hey, maybe they actually use port forwarding there, just to confuse my explanation... but you never have to see their pretty network internals, proxies, and other wizardry.).
Anyway, when you connect to Stackoverflow, you're making one outbound connection that requests data from the server, and then over that same connection you're receiving it back. Same exact scenario, only with a webserver instead of a game.
UPnP allows you to tackle many routers. There's also NAT Punch-Through if you have access to a third party that isn't behind a router.
Either way, port forwarding is only necessary if you wish to act as a server (or the sender in a P2P relationship). A client does not need to forward ports.
You don't need to forward ports to access the web either, despite data coming in as well.
When you make an outgoing TCP connection, your NAT router puts the connection in a table, so that when data comes in, it knows what machine in your LAN to send the packet to.
Everyone mentions TCP, but NAT works for UDP as well: The first outgoing UDP packet associates that source port with the internal IP address, and your NAT device will forward incoming traffic to that port to the correct host on the internal network.
In other words, if your computer requests the connection (outbound) first, the router opens up the port automatically, on the assumption that you're going to want data back. But if you want remote users to connect to your computer without your computer requesting it, the router would normally drop the packets since it wouldn't know where to send them (they were unsolicited). So instead, you need to tell the router to deliver any unsolicited packets at port N to your computer.
Sorry to add another answer so late, and I know one was already accepted, but I personally found the other answers to be more confusing than this simple explanation.