Note For the rest of you, telnetting to a web server and looking at the page through it is a quaint and kind of geeky but PERFECTLY legal (and not covert as such) way of looking at a page. How do you guys think the client sends commands to the server, exactly?
Well, any web server that I set up wouldn't allow telnet in from the outside, and probably not from the inside, either. If it did allow telnet, it would include a warning banner about authorized use and investigating my website wouldn't be authorized.
I think the client sends commands to the server via http on port 80 rather than telnet. Yes, you can telnet to port 80 but there are easier ways to pull the information I think.
So, the fact that the RP was trying to telnet to the webserver set of alarms for me.
-David
kovar, johnR (and myself) was talking about telnetting to port 80 to begin with.
Given what you said here, I am presuming you were misinterpreting johnR's action as "connecting to the telnet port of the web server", which is clearly not the case so no alarm should have been set off for you.
http//
In this wikipedia entry you can see both the commands in the application-layer protocol and the way the client and server interact. What firefox, IE, Opera and so on, and so forth, essentially have more than telnet is a rendering engine, formally known as a layout engine (http//
So, simply stated, what we do when we connect to the web is we "telnet" to port 80 on the webserver, send commands, receive data, send more commands, receive more data, disconnect. And because it is stateless (as defined by the protocol), we do that one command at a time (which is why the telnet session closes after each request for data).
SO, where is the bad in using telnet, then?
Cheers
DarkSYN
Hmm interesting indeed, the wiki page got me thinking. If you issue the commands in "raw" format… eg telnet rather than using a browser could you obtain more data? Afterall if you had a suspicion that the site was 'up to no good' you'd have to prove it first before raiding it.
Ping, DNSlookup, nslookup, traceroute and whois all provide details for the server and the owner (maybe). But what about the pages - I figure that if you telnet and start issue commands over port 80 the worst case your caching pages and writing to the servers logs. (Assuming you do it correctly, you shouldn't be giving anything away?).
I've never investigated a web site, but to my knowledge there isn't a reason to hide things like the User Agent unless the UA is an anomaly like that of a vulnerability scanner like Nikto or a crawler like maybe HTTrack which will raise a flag to anyone monitoring the web servers logs.
If you're hiding your UA, that itself can be an anomaly which can raise an eyebrow. I would think your best bet would be to use IE or FF (or spoof their UAs) and keep things as normal as possible, which should result in more normal logs, which should result an investigation that's harder to detect.
Then again I would imagine it would be pretty hard to determine whether suspicious activity such as crawling a web site was part of a criminal investigation or just part of the many attacks that happen when you connect a computer to the internet.
I've never investigated a web site, but to my knowledge there isn't a reason to hide things like the User Agent …
If you suspect the site discriminates, there may be. (User Agent info may tell the web server what client has connected.) At several times, there have been rumors that microsoft.com or other microsoft sites try to make life difficult for non-MS web browsers – that could in theory be done by sensing user agent string.
However, if you suspect that connecting to a web site with a 'magic' user agent string will let you into totally secret places … it's technically possible to do, but it will be very difficult to find without further clues.
Penetration testers sometimes run into web servers that try to hide their identity to make it more difficult to figure out what vulnerabilities may be present. For ways around this, google for 'HTTP fingerprinting' and particularly the 'httprint' utility. Unfortunately, it doesn't seem to have been kept up to date.