Recently I was shoring up the defenses of BSD hosts in the DMZ and enabling the IPFW firewall. The goal of that effort was two-fold: 1) make certain services are only available to ip addresses or ranges that are require, say for example I need SSHd open, but I only want the trusted LAN to be able to access,and 2) prevent the BSD box from inadvertently broadcasting anything I don’t want it to, through a simple egress ruleset.
I have a straightforward stateful ruleset, I have no delusions about IPFW, but it certainly serves a purpose and I am pretty confident in the setup. One of my final explicit rules it a deny log all rule that I use to help further tune the rules and that I rely on as a cheap sniffer of sorts. By tailing the security log, occasionally or for periods at a time, I get an idea of what I have broken with my rules, what other hosts are hitting the box and for what reason, and in this case, which other hosts in the DMZ are overly chatty.
As some can likely guess, the BSD hosts are not alone in the DMZ and while the BSD systems may be content to serve in silence, the Redmondian hosts seem to chatter nervously, perhaps overly aware of the peril they are in being bastion hosts. Looking at the firewall log, I see frequent UDP broadcast traffic, ports 137/138. It seems they are going out of their way to get noticed, this make me cringe a bit and I set out to accomplish 2 thing. First I need to see if I can silence the Windows servers to some degree, certainly they should require UDP broadcasts in order to function. Second, I think I need to do a port scan and vulnerability assessment from within the DMZ. I think the latter is important because should any bastion host be compromised, an attacker will often look into lateral movement to other DMZ hosts before making the push to get to the LAN. If your security measures are such that you are: relying on the perimeter firewall only to protect the DMZ hosts; and, believe that the DMZ itself provides any true, magical protection for your trusted network – you are likely in for a rude awakening. All too often, network admins are requested to created too many lax DMZ-to-LAN ACLs for things like database connections, easy file sharing (SMB), remote access (RDP etc.) effectively converting the DMZ into an attacker’s dream. All the more reason to harden each host in the DMZ as much as possible.
Also in larger organizations, weak change management could easily allow for a system manager to install VNC on a host in the DMZ so that he/she can readily hit a desktop without having to sign into a busy management server. Lack of egress rules on the perimeter firewall means nothing gets in the way of the LAN-to-DMZ connection, and by default DMZ-to-DMZ will also be able to utilize VNC. One quick scan from a compromised host in the DMZ shows an open port 5900 and the attacker has his second victim system with little effort.
A quick scan with NMap and my cringing returns:
PORT STATE SERVICE VERSION
80/tcp open http redacted
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
443/tcp open ssl/http redacted
445/tcp open netbios-ssn
3389/tcp open ms-wbt-server Microsoft Terminal Service
5357/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
8192/tcp open redacted redacted
8193/tcp open tcpwrapped
8194/tcp open redacted redacted
49152/tcp open msrpc Microsoft Windows RPC
49153/tcp open msrpc Microsoft Windows RPC
49154/tcp open msrpc Microsoft Windows RPC
49155/tcp open msrpc Microsoft Windows RPC
49156/tcp open msrpc Microsoft Windows RPC
In all fairness, I also scanned a *nix host and found more open ports than I expected, like Postfix listening intently on TCP/25 when it should be a null host. The lesson here is that placing hosts in the DMZ does not instantly secure them, and being overly reliant on the perimeter firewall only bolsters a false sense of security. Take the time to harden each bastion host, they need to be protected from each other as much as they do from outside attackers.