Sign in to follow this  
blaze02

Port Scanning

Recommended Posts

I go to school at Digipen. They only allow outside access through ports 8000-8005. So I can tell my program to only use those ports... but what if I did not know which ports I could use? Would it be feasible to implement a port scanner to determine the available ports? Crunching some quick numbers: ~65000 possible ports x 32 byte message (UDP header + 4 bytes) = about 2 Megs How fast could I send those 65000 msgs? Is there any overhead besides the obvious upload bandwidth? I.e. can I send 65000 msgs in the same amount of time I could upload a 2Mb file? Does this sound anywhere close to a good idea?? :) Haha, thanks for any suggestions.

Share this post


Link to post
Share on other sites
No, it's not close to a good idea. What it might do is bring your network administrator down on your head. And it won't be particularly quick anyway as you're supposed to be waiting for a response from the target system. Just let the ports be configurable.

Share this post


Link to post
Share on other sites
Are those client or server ports?

It's best not to do naughty things, particularly not without the user's permission.

Sending out a lot of requests may cause denial of service problems behind NAT devices, as you may exhaust the available number of NAT rules (or there may be a limit per host, so you only deny yourself service).

You should not be using well-known ports on the client side anyway, it's poor etiquette.

Mark

Share this post


Link to post
Share on other sites
Common now, I'm not a jackass. The output port is configurable. It is normally set to 0, which allows the OS to determine the port (usually around 1024-1030).

I'm trying to determine an open port to send from on the client's side.

You think it would bring the network admin trouble? I'm just trying to send from a lot of ports.

It wouldn't take a gross amount of time. It's not like I'm going to send 1 packet, then wait. I'm going to send about 1000 packets, then check for a reply from all of them.

Share this post


Link to post
Share on other sites
Yes, the network admin wouldn't like it, and such things tend to come up on their radar very quickly. It probably would take a 'gross' amount of time - have you tried running a port scanner yourself? The time consumed is nothing to do with the packet you send, it's to do with establishing the connection, and firewalled ports tend to fail silently and slowly.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
The time consumed is nothing to do with the packet you send, it's to do with establishing the connection, and firewalled ports tend to fail silently and slowly.


It will only have to establish a connection if the packet gets through. So I will only be establishing one connection. Firewalled ports may fail silently, but I don't see how they could fail slowly. Either the packet gets to its destination in ~30ms or it doesn't. Firewalls don't slow down packets.

I don't understand how the time consumed has nothing to do with sending the packets. Nothing else in the equation takes time from the program's point of view. The prog would have to:
a) create 65000 sockets and bind them to a certain port
b) send up to 65000 packets for a total of about 2.1 megs of data
c) listen for a packet on up to 65000 ports with multiple select calls
d) receive one packet (if we get through)

Now obviously I wouldn't do those in that order. I'd probably try to batch around 500 at a time. And those 500 wouldn't be 1024-1524, I would make sure to jump around and intelligently search in the hopes that there was a batch of open ports.

What really concerns me is that professional games work behind the router that initiated this problem. Although most every game uses TCP, even games like Battlefield 2 work fine... and I fail to believe they fall back on a TCP network plan.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
Yes, the network admin wouldn't like it, and such things tend to come up on their radar very quickly. It probably would take a 'gross' amount of time - have you tried running a port scanner yourself? The time consumed is nothing to do with the packet you send, it's to do with establishing the connection, and firewalled ports tend to fail silently and slowly.


Yep. A thorough port scan takes a "gross" amount of time. A faster approach may be to do the opposite, that is, list all TCP and UDP endpoints on your system, eg: TCPView.

Share this post


Link to post
Share on other sites
Are you sure your network is filtering SOURCE ports? Most of the time, it's destination ports that are the problem.

Note that UDP, being lossy, is exceptionally hard to do solid port detection for. If you send 1000 messages, each of which is 32 bytes, then the router might only have space for 500, and dump the other 500 on the floor. You don't know if the reason you didn't get an answer was that the port is blocked, or you just exceeded some queue or bandwidth capacity somewhere.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Are you sure your network is filtering SOURCE ports?


Yeah, I was pretty disappointed to find out that not even the initial packet made it to my server.

I never expected it to be easy to port scan all 65000 ports... but it is really my only option. Well, the other option would be to fall back on a TCP system, but that would give me more overhead than I want. I've heard that Battlefield 2 actually falls back to TCP if the UDP is blocked. This would explain why it works from the same place that I can't get to work with my prog. Could this be true?

And its mildly okay if it takes a "gross" amount of time. Although, I'm pretty sure that it won't take any longer than uploading 2 megs of data, I may have to do it 2-3 times to make sure my packet isn't getting dropped. Yes, there are a lot of other factors that will kill performance and reliability, but this is all going to happen when the player is playing single player. And once it works, the port gets saved and it never has to execute again.

None of that really matters though, because I've heard industry routers/switches will blacklist IP's that are "hacking" like this. Can anybody confirm this?

Share this post


Link to post
Share on other sites
I mentioned that port scanning was my only option in the previous post... well, its just the only one I know will work (pending the router/switch blacklist situation).

Some other ideas I had (and if you didn't like port scanning, you won't like these):

-Construct my own raw packets and fake a TCP or at least don't send an exact UDP header. Basically, try to find out what the switch is filtering out and change it. The problem being, this requires admin privileges on the PC running the prog.

-Take over an OS port. 21, 23, 80... there are a lot of ports that I could tap into in hopes that the switch does not filter UDP on these ports.

-I could try to "massage" the port by starting a TCP connection, and then switching over to UDP. But, I have no idea if the filter works like this.

Share this post


Link to post
Share on other sites
Yes, many games will try to fall back to TCP if UDP doesn't work.

Yes, there are routeres that will detect port scanning and blacklist the source.

No, you cannot "massage" a connection by switching between TCP and UDP -- they are totally different address spaces. Port 1234 for TCP has nothing to do with port 1234 for UDP.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Port 1234 for TCP has nothing to do with port 1234 for UDP.


What!? Really? How can that be? Are you telling me I can send/recv on port 1234 TCP in one thread, and sendto/recvfrom port 1234 UDP in another thread?

I was under the assumption that the port was physically the same thing, the only differnce in TCP and UDP was the header of the message... and, of course, the way winsock subsystem guarantees the send.

Share this post


Link to post
Share on other sites
Quote:
Original post by blaze02
Quote:
Original post by hplus0603
Port 1234 for TCP has nothing to do with port 1234 for UDP.


What!? Really? How can that be? Are you telling me I can send/recv on port 1234 TCP in one thread, and sendto/recvfrom port 1234 UDP in another thread?

I was under the assumption that the port was physically the same thing, the only differnce in TCP and UDP was the header of the message... and, of course, the way winsock subsystem guarantees the send.


hplus is correct. The ports are unrelated. The TCP and UDP implementations on the system do not talk. To understand this, think of the network stack. Incoming data on Ethernet has a "port" specifying what protocol to use, here IP. Incoming IP packets have a "port" showing what higher-level protocol to use, which will usually be TCP or UDP. TCP and UDP happen to both use a similar-looking port system out of convenience, but IP itself knows nothing of ports.

Share this post


Link to post
Share on other sites
well as both above posts say, a port can blocked on TCP and open on UDP.
they are not the same, I used to have the same port for a udp and a tcp packet on my network engine :P
blaze02: i dt think IT dept. will notice anyth if u blow up the bandwidth lol :)
damn dit IT dept :@

Share this post


Link to post
Share on other sites
Quote:
Original post by blaze02
I was under the assumption that the port was physically the same thing, the only differnce in TCP and UDP was the header of the message


'Physically' the port is only in the header of the message too. It's just a number, nothing more, that allows an operating system to determine which process needs a given bit of data.

Share this post


Link to post
Share on other sites
Quote:
Original post by blaze02
I mentioned that port scanning was my only option in the previous post... well, its just the only one I know will work (pending the router/switch blacklist situation).

Some other ideas I had (and if you didn't like port scanning, you won't like these):

-Construct my own raw packets and fake a TCP or at least don't send an exact UDP header. Basically, try to find out what the switch is filtering out and change it. The problem being, this requires admin privileges on the PC running the prog.

-Take over an OS port. 21, 23, 80... there are a lot of ports that I could tap into in hopes that the switch does not filter UDP on these ports.

-I could try to "massage" the port by starting a TCP connection, and then switching over to UDP. But, I have no idea if the filter works like this.


Consider nmap, which has a Paranoid setting for portscanning. At least you won't (potentially) be detected.

Share this post


Link to post
Share on other sites
Quote:
Original post by blaze02
Quote:
Original post by hplus0603
Port 1234 for TCP has nothing to do with port 1234 for UDP.

Are you telling me I can send/recv on port 1234 TCP in one thread, and sendto/recvfrom port 1234 UDP in another thread?


Since nobody answered my question specifically, I'll assume from the above posts that:
Yes, you can safely thread the same port if one is UDP and the other is TCP.

I still don't quite believe the UDP and TCP ports are unrelated. Also, how does that work with raw sockets?

Share this post


Link to post
Share on other sites
Quote:
Yes, you can safely thread the same port if one is UDP and the other is TCP.

I still don't quite believe the UDP and TCP ports are unrelated. Also, how does that work with raw sockets?


We actually answered this explicitly. Yes, you can use both at the same time for different purposes with no risk of interference.

For raw sockets, you don't bind to a specific port; you bind to a protocol number (or maybe even to just a device). It's up to you to decode the protocol and ports in that case.

I suggest you read up on the basic OSI layer model of networking, or maybe even a good TCP book such as TCP/IP Illustrated.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by hplus0603
I suggest you read up on the basic OSI layer model of networking, or maybe even a good TCP book such as TCP/IP Illustrated.


coincidentally, I'm pretty sure thats the Digipen standard textbook for the networking class, so *in theory* the OP should be reading it. At any rate, I'm sure IT wouldn't be happy about your port scanning, and a systematic check of all ports coming from a single machine (or even an unusually high volume of traffic aimed at different ports) will surely raise an alarm.

As a former student I can say that the tech guy that came in last year is amazing compared to the yahoos that were running the show when I started there a mere 4 years ago. I'm sure he's STILL working hard to resolve all the issues he's inherited from the last admin, so don't make his life any more stressfull :)

Share this post


Link to post
Share on other sites
I pretty much wrote off the idea after learning that most good routers will blacklist IPs that do this sort of thing. I can't imagine the IT guy raising too big of a fuss. Every student in our networking class made a port scanner and used it inside the building playing our little hide-and-seek networking games.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this