September 26th, 2003, 10:38 AM
lol i'm sorry.
I'm running a client...
I just want to connect to someonr on XP, port 60666.
September 26th, 2003, 10:39 AM
So, can you ping the XP machine? Is there any other server (such as a web server) you can try to connect to? If you can't get a standard client to connect, don't bother trying to debug your code!
September 26th, 2003, 10:43 AM
September 26th, 2003, 10:44 AM
No, that's for ftp data.
The port ranges are:
0 - 1023: The Well Known Ports -- reserved for common services like telnet, ftp, sendmail
1024 - 49151: The Registered Ports -- registered by companies and organizations
49152 - 65535: The Dynamic and/or Private Ports -- available for the rest of us to use
All I know is to not use the lower-numbered ports unless our app uses or provides that service. I do not know what the consequences of violating that rule can be.
September 26th, 2003, 10:50 AM
You can use any server port you want (as long as you are logged on as administratory for the lower ports), the only 'problem' is if a client process tries to use that port. I have used port 23 (telnet) for a lot of experimentation because I don't run a telnet server on my computer and I don't mind giving hackers headaches trying to connect to that port (I never leave the server running for longer than a few minutes anyway). The OS couldn't care less what process is running on which port (as long as there is no contention, then it is first come, first server), so using port 20 as a server only prohibits an FTP server from trying to use it.
On the other hand, if your (non-FTP) client tries to connect to port 20 on a remote machine, you are likely to get some unexpected results!
September 26th, 2003, 10:52 AM
Another wrinkle in trying to reach a server behind a firewall is stateful inspection. In that, the firewall will only allow in packets that it expects to get in response to a packet that went out. So a server behind a firewall that uses stateful inspection will be unreachable from the outside.
FTP runs into this problem all the time. When you connect with the server's command port on port 21, it tries to connect back to you on the data port, port 20. Stateful inspection prevents that from happening. FTP's solution is choosing between active and passive modes, which I forget at the moment but I think that in one mode the server makes the port 20 connection while in the other it's up to the client.
Another solution is to place the server in the DMZ (demilitarized zone). This increases its vulnerability, but makes it accessible. I know that most routers allow you to set up the DMZ. Try searching for information on XP security and setting up a DMZ.
September 27th, 2003, 03:39 PM
I ran netstat while transferring to someone with windows 2000.
What is ingreslock?
September 27th, 2003, 09:32 PM
I Google'd and found:
is a daemon process which insures consistency of an ingres database. You may want to start ingreslock from /etc/SERVICES
Which doesn't look right. Most of the hits I see are questions on discussion forums asking what it is. Playboy.com seems to come up a lot. And here's this response:
And then I found this one:
And at http://www.usethesource.com/articles...1/123212.shtml I found this after an email that said it was from Hugh Hefner:
So it looks like a UNIX attack, so the obvious question is: what is it doing on a Win2k box?
September 28th, 2003, 01:47 AM
Huh, linux attack? I was just running my program!
September 28th, 2003, 09:47 AM
Actually, that ingreslock thing appears to not be the actual attack but rather is planted as a back door as a result of the attack.
And as I said, from what I read it appears to apply to UNIX machines -- can Windows even run the ingres database (apparently so, since MSDN lists it as a port assignment and it is listed in the Win2k services file)? I still don't know whether it would serve as a back door on a Windows machine.
That last thing I quoted that refered to a 1999 CERT advisory -- on that part of the page was a link to that advisory at http://www.cert.org/incident_notes/IN-99-04.html. (obviously, I'm Google'ing as I write this) That advisory still appears to be UNIX-specific, but it does refer to this attack as exploiting RPC services. One of the features of Win2k and especially XP is its RPC services.
In another forum, I read of this test:
Was that ingreslock on your own machine (a Win98 or WinME, if I recall correctly)? Probably must have been. Try that test with telnet. If on your own machine, from the command line you should be able to start it with telnet localhost ingreslock or with telnet localhost 1524. If there's a back door, then it should connect.
I've checked my Win2k, WinME, and 2 Linux boxes at home (neither Linux box has ever been online). netstat showed nothing on port 1524 and attempts to telnet to that port were refused in each case; in other words, nothing was listening on that port.
BTW, apparently that Playboy story was big news in 2001. CNN's report is at http://www.cnn.com/2001/TECH/interne...ked/index.html .
September 28th, 2003, 02:52 PM
Now I'm really confused. I just connect to a remote computer on port 60666 and this is an attack and/or backdoor?
I'd better buy a book. A very thick book for a stupid person like me. Do you know something good and simple?
September 28th, 2003, 03:36 PM
Now hold on a moment. We don't know exactly what's going on there.
You did a netstat -an and the word "ingreslock" came up.
Was that netstat performed on your machine or on the XP server?
Just what did the line containing that word say? X out the IP address for security if it isn't 0.0.0.0 or 127.0.0.1 . Is it listening or what?
Your attempt to connect is not itself an attack. That exploit was already planted before you came along. The exploitation establishes a backdoor at port 1524. You are not attempting to connect to that port.
What I had suggested, by posting that other guy's suggestion, was to use telnet to try to connect to port 1524. If it accepts the connect, and especially if it gives you a command-line prompt, then that machine is compromised and needs to be fixed. I have seen some details for what to look for on Linux (basically, a daemon is set up to be serviced by the super-daemon inetd), but I haven't seen the same for an WinNT/2k/XP machine.
Of course, if it's on the other guy's computer, then get his cooperation to track this down and clean it up -- we know you are already in contact with him because he's trying to run your server. There are some very weird and bad things happening out there, so we need to do all we can to keep them from happening.
Last edited by dwise1_aol; September 28th, 2003 at 03:39 PM.
September 29th, 2003, 04:24 AM
I can't connect to port 1524, so it's OK - are you trying to tell me I was attacked?
How popular am I. :)
When I just listen, netstat gives me the right information - listening 0.0.0.0:60666.
When i tested f2f I did it with my friend who has an extremmely fast dial-up - it took 20 minutes to send 4 MB. Does this matter?
September 29th, 2003, 05:26 AM
What is an extremely fast dialup? 56K is the 'legal' maximum and that almost never happens in real life. Keep in mind that 56K is thousands of bits per second, divide by 8 to get bytes per second. Also realize that the actual data transmitted per packet is less than the packet size. Generally speaking, you are doing good to realize 80% of the advertized bandwidth of your connection (advertized for dialup is what rate at which you supposedly connected). Do the math and then decide if 20 minutes for 4 MB was good, bad, or just right. I use DSL that is advertized as 384 Kbps/ 128 Kbps (download vs upload). Therefore, I would expect to see a download duration for 4 MB of:
Total bits to transfer:
4194304 bytes * 8 bits / byte = 33554432
.80 * 384000 = 307200
Seconds to download:
33554432 / 307200 = 109
So I would expect around 2 minutes or a bit less to download your file. Keep in mind that the speed is limited by the slowest connection (meaning it makes no nevermind if your friend has a T3 line if you have a dialup). Further, if the connection path betwixed the twain of you is busy, you won't be able to get your advertized rate (I have noticed that Friday and Saturday evenings are the worst and often don't even bother to surf then). This last is less likely to be a problem, but if the server or client is very busy, it may not be sending/recieving at the same rate as the connection can handle.
BTW: I estimated it to take around 16 minutes on a 'fast dialup'.
September 29th, 2003, 09:18 AM
Extremmely fast means too slow - f2f works just fine.