Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a homework in which I should explain how I would break into a server, retrieve a file and cover my tracks. My main question: is it possible to packet sniff a remote web server?

Other information would be appreciated on covering tracks.

Edit. the complete question:

In attempting to gain unauthorized access to data, hackers perform the following operations:

  1. Reconnaissance (Active or Passive)
  2. Scanning
  3. Gaining Access (operatating system, application or network level)
  4. Maintaining access (uploading or altering data)
  5. Clearing tracks.

Briefly describe how you would go about doing these and what tools you would use. What counter measures can someone put in place to block you?

share|improve this question
6  
Well don't let us stop you getting on with your homework then. –  RobM Jun 15 '10 at 21:54
    
This is not the best venue to ask: "How do I hack a server and cover my tracks". I HIGHLY doubt schools will come up with that type task in that context! –  l0c0b0x Jun 15 '10 at 22:07
1  
Codez. I needz them. Plz send. –  Holocryptic Jun 15 '10 at 22:10
    
All I'm asking is if it is possible to packnet sniff a remote web server, and @l0c0b0x the course is called data security. –  Shawn Mclean Jun 15 '10 at 22:23
    
@Holo: That made me laugh. :) –  joeqwerty Jun 15 '10 at 23:28

3 Answers 3

up vote 2 down vote accepted

Sniffing a remote server is possible, though not easy. The most effective (though not reliable) is to compromise another device on the same subnet as the web server to the level that you can execute a sniffer. At that point you deploy ARP Poisoning to convince the switch that you need to see that server's traffic. If the switch isn't set up to defend against that kind of attack, this should give you the full network stream to the target web-server. However, it does require you to compromise a host to get access to another host, so the bootstrap chain to get to this capability is pretty long and complicated as it is.

The next most effective method is to compromise the router attached to that network. At that point you can do a lot of interesting things including (depending on the router) forwarding traffic destined to that target web server to another network location you control. This method, however, is generally a lot harder than the first one. Network admins tend to lock this kind of thing down a LOT harder than server admins, in large part because the attack surface is a lot smaller. Also, rare is the router administrative address accessible to a public network in any way.

As a recon method, sniffing is more useful when breaking into an application once the web server has already been cracked. Perhaps they're looking to sniff a back-end network for credentials passed in the clear to a database over an assumedly secure channel. This method is one used by sophisticated attackers, and generally isn't in the 'sploit toolkit repertoire.

share|improve this answer

To packet sniff anything you need to get the packets - no matter what you're sniffing.

There are many ways to accomplish this, the easiest two are being a "man in the middle" (say linux system with two ethernet ports in bridging between the server and the network it talks to) or getting a copy of the actual traffic (you can set a port in "monitor mode" on most manageable ethernet switches).

The latter is actually routinely used to get a copy of your network traffic to your IDS. In the good old days of 10mbit and in the first days of 100mbit you could also use an hub, but that'd lead to lower performance than the switch solution and is no more applicable on gigabit ethernets.

If you do not have direct access to the network then you need to get a copy of the data in any other way, for example running a probe on the server (tcpdump, to name one). This way you can also record the traffic for later analysis.

This is about 'packet sniffing' (which is not something "bad" per se, btw), and assumes you have some control over the network or the server.

share|improve this answer

See this, under section 1.6.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.