Introduction to Snooping Around
by copycat
There are many reasons to poke and snoop around.
Curiosity - "Hum... what is that IP?"
Security - "Hum... why is that IP in my firewall logs?!"
Script kiddies (may have their own reasons) - "Humbah... Me c001 hax0r Internet spy!!"
Whatever your cause, be prepared to answer questions if someone traces your phone number from the IP you left on their logs. This article will give a few tips and tricks for snooping around, and a brief overview of simple tools that can assist you in this task. I am not going to include a disclaimer because I think snooping around is perfectly okay as long as you do not enter the system. Many people do not agree. You choose.
For whatever reason, you have an IP number. Now what? Port scan?
No. Some firewalls are smart enough to detect port scans and then deny the access to all services behind the firewall automatically from the IP that originated the port scan. If you do not want to be kicked out so quickly, it's better to leave the actual brute-force-intrusive-snooping for the end. First one must do some poking.
One thing to try with an IP number is reverse lookup in order to get its name. Names are more meaningful for most humans. nslookup should do the trick. The host utility that comes with the bind distribution is nicer, but everyone's got nslookup.
Some ISPs, rude ones, do not provide this. Fear not, there is still hope! One way to figure out, approximately, where this IP is, is to perform a traceroute. This way a reverse lookup might be found for a host that is a hop or two away from the IP in question hinting at the location of this IP and its ISP.
If this is not so, you are still not out of luck. You can check the owner of this IP block by looking it up in ARIN's WHOIS database:
Now this should give you the ISP name or company name, plus the name of the misbehaved DNS that is in charge of the reverse mapping. (Bad ISP! Bad! Bad!)
If you have stumbled upon joe-schmoe-dsl or lucy-modem-luser, learning the whole structure of their ISP's network will not help you much. However there are a few things that can help. Naturally, one would like to find out the login name associated with this IP. For this you must act quickly. Sometimes ISPs have a Finger daemon running on their modem boxes that these IPs go through. It should be a hop or two away from the mystery IP.
Again traceroute and:
The reason to do this check immediately is that the IP itself may be irrelevant once the host disconnects, as it is assigned a new one via DHCP each time it logs on to the ISP. In fact, if you have been attacked by such a host and it has already disconnected, one of the only things to do would be to give the ISP the IP and the time of the event, and ask them to check their own logs in order to take care of the matter. Another possibility is to wait for the attacker to return.
The better ISPs offer shell accounts. A Finger on the shell box might show you the users and where they connect from. If this is your lucky day, the mysterious IP will show up. If this snooping business is extremely important to you, you might want to get an account on this box. There is a lot of information you can get when you and the mystery user share the same machine: mail last checked, files, processes, the times the user connected, from where, etc. Um, kids, I said get an account, not crack one. You can go and sign up with this ISP for a month...
Equipped with the login name you can search the ISP's web pages for info about this user, perhaps a personal web page. And also, you can poke at the mail server.
For argument's sake, let's say you have encountered an IP that belongs to an actual organization. Usually educational organizations are more interesting then commercial ones because they run all kinds of neat stuff. But be it an ISP, a company, a university, or whatever, we are armed with our domain name and we can check out info with DNS. But what DNS do we poke at?
Besides looking for owners of IP blocks in ARIN's WHOIS, you can use whois to find contact info (that means phone numbers and addresses) of actual people, plus our desired DNS. It might be a good idea to:
in your: ~/.cshrc
whois.geektools.com is a WHOIS proxy and saves you the trouble of looking up whois.internic.net, plus the actual registrar's database. The whois should give us a list of well known DNSes that are in charge of this domain. So now let's head out to our next target.
DNSes are pretty cool as they can hold all kinds of info, and not only names and the related IP addresses. This is an example for a hackish use for DNSes.
That is definitely one elite hostmaster.
One way to find out info from a DNS in charge of a domain is to initialize a request for DNS zone transfer, like a slave DNS would do to its master. nslookup, which is used to debug DNS problems, can emulate this.
You may get lots of really interesting information at this point! You may get the whole layout of the domain. You may get info on the machines themselves, their OS, and hardware. You may get more contact information - even phones and names. It all depends what the hostmaster put in there.
Now a properly secured name server will not respond. It should only answer non-recursive queries about its domain. So you cannot list the zone, only guess its contents. I mean, why should it tell you anything unless you are really one of its slave DNSes? Many DNSes are not configured properly. Let's say you've encountered one of the better hostmasters.
Is all lost? Do not worry, never fear, you may still have luck with one of the other DNSes. There are at least two that show up in the WHOIS database. But there may be more DNSes that are not public but still hold info about this domain. You can try and guess their names: dns.example.com, ns3.example.com, nameserver.example.com
But in fact you can get this info from those secured DNSes themselves:
This will give you a list of DNSes authoritative for this zone - which is what we wanted.
In addition, it will provide you with an email (it comes in the form hostmaster.example.com instead of hostmaster@example.com), plus some MX records of the machines that will accept mail for this domain... which means an SMTP box.
Woo hoo! Now you've got SMTP to poke at. Perhaps more then one - there are backup MX records. SMTP is lots of fun. Let's see who will receive mail for root@example.com. Before we send them a complaint we might want to snoop on those people too! (This will not work on a Qmail server.)
Well, it looks like Rafa's on vacation. If you acquired a login name earlier, now would be a good time to see where its mail is sent to. Perhaps to another SMTP box on an entire different network that is worth exploring.
But what about other machines? If you can't get the zone from the DNS, you have to start guessing common names for well known services: www.example.com might exist, ftp.example.com, gw.example.com, etc.
By now we've got so many IPs and names that are related to our original IP that we can actually start seeing more or less how this organization is set up.
So now we can move to a more intrusive method of snooping. Obviously one should check each IP for the services running on it. This can be accomplished by a port scan. Once you see which ports are open, simply connect and check them out. If you feel a bit queasy running port scans, you can try to Telnet to the well known services' ports. One might guess that the FTP port is open on ftp.example.com. This will give you an opportunity to find out the operating system plus the versions of the services running.
The Telnet or FTP might have an interesting MOTD. FTP might allow anonymous access as well, perhaps leave your email there in case someone has any questions about your snooping. Web server, etc.
Some machines have all kinds of stuff running that no one bothered to close, things like the netstat and systat ports. Telnet'ing into them would give you information about the hosts processes and network connections. Cute stuff.
However, the Internet has grown to be a dangerous, unfriendly place - so one can seldom find such interesting services running. There are other services that you can bump into that may be open to the public. A good example is an LDAP server or any directory service. Although it provides lots of information, I am not covering it. Not to say it isn't interesting, but the tools and services I describe here are more common.
If you bump into something interesting, go learn its protocol and snoop more! But don't forget that just because a machine declares it's running some old version of WU-FTPD, it doesn't mean it's true. Perhaps it's a honey pot designed to lure you in to hacking some skillfully planned "vulnerabilities." Needless to say, even if this is not the case, the better admins will log any connection to these services.
Well, after you've checked out all the interesting things in /etc/services, SSH, the r-commands, blah blah blah - you are probably quite upset you cannot Telnet directly to SSL-ified services and check out their responses such as secure IMAP and HTTPS. This is worth saying once: just because something has SSL doesn't mean it's secure!
All it means is that you cannot sniff SSL traffic, which is a good thing™ because SSL users do not send their passwords and info in the clear. But this doesn't mean that one cannot crack passwords with brute-force. Or in our case, poke around! For our task there is a stelnet (SSL-enabled Telnet server) package floating around. So you can use that or any other SSL wrapper for your Telnet.
Even though Deja News are evil bastards, equipped with emails and names you can run a search to see if these people wrote anything of interest on USENET. Head over to Google and run some more searches. If you are bold, maybe pick one of the phone numbers and do some social hacking. But this is just getting too boring.
Apart from port scanners there are other tools available that automate a lot of this process, attempting to guess a machine's OS and the services running on it. But if you are bored and you don't have hundreds of IPs to scan, a manual snoop is definitely more fun.
Happy snooping!