Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If you install wireshark on a web server sitting in the DMZ, is there a hack that can be used to get backdoor entrace to that server even when RDP is disblaed? I'm trying to monitor the wire on the DMZ web server but getting pushback from the DMZ team that it opens up a back door hack without a lot of details

share|improve this question

A proper DMZ will isolate hosts on the DMZ from each-other in addition to managing access between the hosts and the internet / internal network. The DMZ environment provides for a single choke-point to enforce security and access policies, and provides one single point to monitor traffic into, out of, and within the DMZ.

A DMZ isn't just a network that has access to the internet and the internal network. That's called a security risk and poor planning.

There are potential buffer overruns and security risks with any application that is taking data from uncontrolled sources, especially if the application is running with root / superuser privileges. This is true of wireshark, this is true of sendmail, IIS, true of anything.

To my knowledge, there aren't any "RDP back doors" in wireshark.

My point is "So what if it does open a back-door?"

A proper DMZ should

  1. prevent that compromised system from interacting with anything else except in the predefined manner (DNS to the DNS server, ftp to the FTP server, http to the http server, but no ssh to anything, no rdp from anything to anything, etc)
  2. Identify that improper traffic is attempting to take place (I just got an alert that the SQL server is getting RDP / VNC traffic from the FTP server!)
  3. Be easy to use for everyone else in the enterprise. If the DMZ properly enforces security, it is safer to put "dangerous" things there than in the enterprise network. Would the DMZ team rather have a back-door into the enterprise network or into the DMZ? The answer should be "DMZ, because we monitor and restrict traffic into and out of the DMZ."
share|improve this answer
+1 for explaining the true essence of a DMZ which is grossly overlooked in practice – squillman Jun 12 '10 at 14:47
+1 - I'm in total agreement with squillman re: common DMZ practices. I've run into a goodly number of DMZs that fit the bill of "a routed IP subnet separate from the LAN, but with unrestricted access to the LAN and the Internet, hanging off a dedicated interface on a firewall". >sigh< – Evan Anderson Jun 12 '10 at 14:51
Chris, thanks for excellent writeup – G33kKahuna Jun 12 '10 at 18:07
@chris: I disagree with definition of DMZ here. Generally, the DMZ (De-Militarized Zone) is a subnet with UNFILTERED access to/from the INTERNET. Hence the term. Traffic from DMZ to internal network would be filtered. That doesn't mean to/from the Internet wouldn't be monitored, just not filtered. Hosts on a DMZ are typically hardened because they need to defend themselves. The scenario you are describing (protecting each DMZ host from every other DMZ host) is NOT what I'd expect in the typical DMZ. Sounds more like access control between VLANs to me. – paxos1977 Jun 17 '10 at 15:13
@Evan Anderson: DMZ should not have unfiltered access to the secure internal network... all traffic in the secure internal network should be filtered coming and going according to the principle of least privilege. – paxos1977 Jun 17 '10 at 15:15

I'm not completely in agreement with the DMZ descriptions described above. The security professionals who operate the DMZ probably have "paranoid" in their job descriptions and the DMZ is a "production" space, so see it from their point.

Many of the vulnerabilities cited occur due to flaws in packet dissectors, which are only used during the interactive rendering of traces. This interactive access does not require the same elevated privileges required for packet capture.

Since what you seem to need this for is analyzing local packet capture from the web server, why not separate the functions? Run packet capture on one host, and do the analysis (keeping the dissectors up to date, etc) from another, more restricted, non-production segment after retrieving the trace files.


Wireshark Security:

Platform-Specific information about capture privileges:

and implement the practices described there.

share|improve this answer
+1 for vulns in packet dissectors – Josh Brower Jun 14 '10 at 18:15

Wireshark doesn't offer any networking service and doesn't open any port on the system it's running on, so this just doesn't make sense. Having it installed on a system doesn't pose any security threat on its own.

The only potential risk here is, if someone manages to take control of that server, he can use Wireshark to examine network traffic in the DMZ. But, if someone takes full control of your server, he could also install any program he wants on it... so not having it installed wouldn't stop him from installing it, if he wants to.

I really can't see any problem in installing it on a server.

share|improve this answer
If I have wireshark installed on a system in the DMZ I should be able to see my traffic and and my traffic alone. Otherwise, the DMZ isn't really well designed. – chris Jun 12 '10 at 15:07
Massimo, touche ... – G33kKahuna Jun 12 '10 at 18:08

Wireshark has suffered from its fair share of remote compromise vulnerabilities [CVE-2010-1455, CVE-2010-0304, CVE-2009-4377 + 8, CVE-2009-4376] (CVE lists hundreds). As anyone whose gone to Defcon or the Blackhat security conventions knows, Running any sort of packet sniffing software is wildly dangerous if you're in a secure environment. I'd guess that practically every Security Metrics book published in the last few years would strongly recommend against it.

That said, a proper DMZ would prevent an attacker from gaining any leverage anyway, however, you need to weigh the potential of your IDS or routing control software of choice to be compromised with the usefulness of running WS.

share|improve this answer
Zephyr, thanks. Most of the CVE lists buffer overruns and DOS, which happens even with IIS/ apache running in the DMZ. I've researched some of the CVE's and they dont list any back door just DOS due to buffer overruns. I have to agree with Massimo below wireshark listens to a service but doesn't have a service to allow access to a specific port. As a test I stopped IIS running on port 80 while wireshark running listening to port 80, launched an online port scanner to scan for port 80. It returned as blocked. I'm letting the scanner run on all ports just in case – G33kKahuna Jun 12 '10 at 18:07
Any buffer overrun type attack that causes a program to crash may also possibly be exploited to give access to the system. It isn't easy, or always possible, but if you can cause a program to crash, beware that someone else can probably cause the program to run a program you don't want it to run. – chris Jun 12 '10 at 23:28
Keep in mind, Due to the nature of Wireshark, many of the dangerous bugs are not buffer overflows (Which are fairly easily mitigated in the modern world), but are rather parsing errors like use-after-free attacks or Invalid pointers exploitable through heap spraying (Of course instead of spraying the heap with Javascript as you would with other client side attacks like web browsers, You would do so with network traffic) – Zephyr Pellerin Jun 12 '10 at 23:51

First up, I'm of the opinion that anything extraneous installed on any machine in the DMZ is a potential security risk. I work on the principle that anything in the DMZ is a target and has been placed there to try and minimise risk through isolation. Such machine should be treated as if it can be expected to be compromised.

Despite the foregoing, while Wireshark could potentially be used to watch the traffic in the DMZ the reality is that in order to use it the machine must already be compsomised, which means the perpetrator could just as easily install it themselves if they wanted to. By having it already installed you might at worst be saving them a few seconds of time.

share|improve this answer

Wireshark has had plenty of vulnerabilities in the past, and will likely continue to have more discovered in the future. They usually lie in the protocol analyzers. If an attacker sends specially crafted packets, wireshark could have a buffer overflow while analyzing those packets and execute arbitrary code. (So RDP is irrelevant). Try using a simpler sniffer like tcpdump and just analyze the pcap files elsewhere. (Why do you really need Wireshark's GUI anyway if you're not RDPing into the box?) Another thing to keep in mind is that depending on what this webserver does, sniffing the traffic may reveal info you're not supposed to have.

share|improve this answer

Your Answer


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.