Greg wrote:

Apache in a Chroot Environment makes for a PITA for any kind of Real "Hosting" use...

You betcha. I guess part of my discontent about the Manual is the one I usually have about security articles/HOWTOs (and always about anything that other character, Kurt Seifried, writes): lack of perspective. That's a serious problem because doing security work without a good sense of perspective is the sort of attitude that eventually leads you to do goofy, ineffective, gadget-freak stuff like heaping on more layers of software to "add security" -- or wrapping the local console in ultimately meaningless password hurdles.

What I mean is: If you're so worried about Apache (or BIND) security that you're driven to the masochism of running it in a chroot jail, shouldn't you first look at smaller, simpler, less-security-risky alternative daemons? Where were the recommendations of Boa/thttpd/WN/mathopd and MaraDNS/pdnsd/dproxy/PowerDNS as alternatives? Why automatically stick to overfeatured software and try to paper over basic problems by tacking on additional protective layers?

The fundamental principles of security include: Simpler is easier to audit, and the minimum-complexity code with the required functionality (mutatis mutandis) should be heavily favoured. Anyone who ignores that vital principle really has no business writing about security.

(Greg, you've seen the following stuff before, in part.)

Changing subjects briefly to this forum's perennial topic (Microsoft haplessness and its victims): My mother-in-law, who's doing her doctorate in computer network security, figured she had a problem with her new XP Professional box on our home DSL line, but wanted me to see for myself, and so invited me to nmap her. Results follow:

\nguido:/home/rick# nmap -vv -sT -sR -O -I -oN nmap.log -n 10.0.1.3\n\nStarting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-08-15 12:14 PDT\nHost 10.0.1.3 appears to be up ... good.\nInitiating Connect() Scan against 10.0.1.3 at 12:14\nAdding open port 1025/tcp\nAdding open port 135/tcp\nAdding open port 5000/tcp\nAdding open port 139/tcp\nThe Connect() Scan took 27 seconds to scan 1623 ports.\nInitiating RPCGrind Scan against 10.0.1.3 at 12:14\nThe RPCGrind Scan took 1 second to scan 0 ports.\nFor OSScan assuming that port 135 is open and port 1 is closed and\nneither are firewalled\nInteresting ports on 10.0.1.3:\n(The 1619 ports scanned but not shown below are in state: closed)\nPort       State       Service (RPC)           Owner\n135/tcp    open        loc-srv\n139/tcp    open        netbios-ssn\n1025/tcp   open        NFS-or-IIS\n5000/tcp   open        UPnP\n[...]\n\n\nguido:/home/rick# nmap -vv -sU -sR -O -n -oN nmap2.log -n 10.0.1.3\n\nStarting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-08-15 12:22 PDT\nHost 10.0.1.3 appears to be up ... good.\nInitiating UDP Scan against 10.0.1.3 at 12:22\nThe UDP Scan took 15 seconds to scan 1471 ports.\nAdding open port 138/udp\nAdding open port 135/udp\nAdding open port 1031/udp\nAdding open port 500/udp\nAdding open port 137/udp\nAdding open port 1900/udp\nAdding open port 123/udp\nAdding open port 1032/udp\nInitiating RPCGrind Scan against 10.0.1.3 at 12:22\nThe RPCGrind Scan took 9 seconds to scan 0 ports.\nWarning:  OS detection will be MUCH less reliable because we did not\nfind at least 1 open and 1 closed TCP port\nInteresting ports on 10.0.1.3:\n(The 1463 ports scanned but not shown below are in state: closed)\nPort       State       Service (RPC)\n123/udp    open        ntp\n135/udp    open        loc-srv\n137/udp    open        netbios-ns\n138/udp    open        netbios-dgm\n500/udp    open        isakmp\n1031/udp   open        iad2\n1032/udp   open        iad3\n1900/udp   open        UPnP\n

For comparison's sake, here are the results for the prior Win98SE box it replaced:

\nuncle-enzo:~# nmap -vv -sT -sR -O -I  -n  192.168.0.4\n\nStarting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )\nHost  (192.168.0.4) appears to be up ... good.\nInitiating Connect() Scan against  (192.168.0.4)\nAdding open port 139/tcp\nThe Connect() Scan took 1 second to scan 1554 ports.\nFor OSScan assuming that port 139 is open and port 1 is closed and\nneither are firewalled\nInteresting ports on  (192.168.0.4):\n(The 1553 ports scanned but not shown below are in state: closed)\nPort       State       Service (RPC)           Owner\n139/tcp    open        netbios-ssn\n[...]\n\n\nuncle-enzo:~# nmap -vv -sU -sR -O -n  192.168.0.4\n\nStarting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )\nHost  (192.168.0.4) appears to be up ... good.\nInitiating UDP Scan against  (192.168.0.4)\nThe UDP Scan took 4 seconds to scan 1459 ports.\nAdding open port 137/udp\nAdding open port 138/udp\nWarning:  OS detection will be MUCH less reliable because we did not\nfind at least 1 open and 1 closed TCP port\nInteresting ports on  (192.168.0.4):\n(The 1457 ports scanned but not shown below are in state: closed)\nPort       State       Service (RPC)\n137/udp    open        netbios-ns\n138/udp    open        netbios-dgm\n

The machine in question is connected via NAT to a home LAN on a /29 CIDR block of real IP addresses. (That is, I have five real IPs.) Please note that I didn't set the machine up, and don't have Administrator access. (It's not my machine.)

The point of the above listing, for those not used to reading nmap output, is that the three network services Win98SE automatically offered to the world at large -- all potential foci of hostile action -- have been supplemented by nine more.

Out of habit, I tend to view these matters from a Unix-ey sysadmin perspective. As such, I immediately start wondering about things:

1. What are these things doing?
2. Was I (meaning: the installing user) informed during installation of the system being configured to run them, and failed to notice?
3. What relies on them?
4. Where are they turned on/off (at runtime and startup)?
5. Where do I control which network interfaces they listen on?
6. Where do I do hostaccess per network service (as in Unix tcpwrappers' /etc/hosts.allow and /etc/hosts.deny)?
7. Where do I specify system-wide blocks against exposed network services I find out I'm running, itemised by DENY rules specifying source netblock & destination port (as in Linux netfilter)?

You start at the top of the list, and try to find out (Q#1) what these are. There are dribs and drabs of information that you can smoke out if you're very determined, but it's pretty murky. And the answer to Q#2 ("Was I told?") is "No."

In the sort-of information you find on Q#1, you'll dig up vague advisories that if you somehow disable the service in question -- e.g., because it's a friggin' RPC portmapper that the worm du jour is trying to find -- then "some services may break". I kid you not: That's a direct quotation (or at least very close paraphrase) from a Microsoft article on the now-infamous 135/TCP RPC portmapper vulnerability. And that's a close as you'll come to an answer to Q#3.

I haven't fully chased down the answer to Q#4 (on/off mechanisms), but it probably boils down to frobbing mumbledy-mumble NT services in Services Manager, but you're steered away from trying it because "some services may break".

Q#5 (limiting listing interface) is the sort of thing you, as sysadmin, routinely have access to on (almost) any network service on any Unix box. E.g., if you want your copy of Apache to run as a local-only Web server, you edit /etc/apache/httpd.conf's Listen and VirtualHost directives to point to IP address 127.0.0.1 (loopback), instead of your outside-facing IP. How do you do this concerning any of XP's built-in network services? God Only Knows. I've tried to find out; I've asked -- up to the limits of my interest (which is more limited than if it were my host). If the information's available, I have no idea where -- and, what's even more spooky, nobody seems to be asking the question!

Ditto hostaccess/tcpwrappers equivalents (Q#6). Hey, guys! Tcpwrappers example code has been available under open-source licensing for a couple of decades. Is there honestly no per-service equivalent function available for MS-Windows? Not even for mucho dinero? C'mon. That's really sad.

Q#7 is of course what all the Redmondians push you towards if you talk about security and exposed ports. "Get a firewall! Use Internet Connection Firewall [ICF], at least!"

ICF is what's provided integral to XP -- a basic host-based IP-filtering mechanism. But, for better or worse, it doesn't work at all as described above in the Q#7 description: As far as I can tell, enabling ICF on a given network interface results in application of a predefined block of all non-loopback inbound traffic against a predefined collection of TCP, UDP, and ICMP ports. However, you are nowhere told even what those ports are, let alone given access to edit the list's definition. Your only edit access is to superimpose, onto the global block, individual exceptions to allow inbound traffic[1] to a specific port -- one port at a time, each one entered via an exception fill-in screen. To allow connections to ports 1024-1223, you'd have to fill in 200 individual screen dialogues: You can't specify a range.

More to the immediate point, you can't say "Hey, I want inbound traffic generally to be unimpeded, but just want to bar all but local traffic to TCP ports 135, 139, 1025, and 5000, along with UDP ports 123, 135, 137, 138, 500, 1031, 1032, and 1900. Leave all other traffic including ICMP alone." (That list corresponds exactly to the nmap charts of exposed WinXP services, above.) No can do. Not supported at all.

Greg tells me that doing something like the obvious (the foregoing) is possible -- but only if I shell out amazingly big bucks for Checkpoint Firewall One. Otherwise, No Way in Hell.[2]

So, I'm amazed, O Ye Microsoft Users. I'm amazed that people put up with running services the installer (apparently) didn't inform them they'd be running (leaving aside the pointlessness of running them and squandering machine resources on them for a home PC), whose purpose and needfullness is murky[3] and where the consequences of disabling them (if you can figure out how) is even more so. I'm amazed that you put up with not being able to configure what network interfaces they listen on, and whether they're loopback-only. I'm amazed that there's (apparently) nothing at all comparable to the bog-standard tcpwrappers library. And I'm dumbfounded that even compensating for this debacle in a straightforward way isn't even possible without dropping thousands of US$ on a enterprise-level add-on firewall.

[1] Oddly, ICF's rules cannot be applied to outbound traffic, only inbound. This is peculiar because obviously the underlying filtering software must be capable of such filtering, but Microsoft gives no access to use the tool in that fashion, for those wishing to do so.

[2] No, BlackIce and ZoneAlarm work pretty much like ICF in that regard. What's that you say? TinyFirewall, Sysgate, Agnitum, Kerio? Let me know if you think any of them qualifies, please.

[3] Not to mention the admin's helplessness to substitute a different daemon for one that has become vulnerable or too risky, as I can substitute thttpd for Apache, etc.

Rick Moen
rick@linuxmafia.com

Just to cover the material posted earlier in some greater detail, here is the results of some casual googling on the open TCP and UDP ports listed earlier:

135/tcp open loc-srv
135/udp open loc-srv

Location Service. This is the infamous RPC portmappper "svchost.exe" (supporting "DCE services" for remote hosts), focus of a recent NT/2k/XP vulnerability. It listens for both TCP and UDP packet types.

The idea of an RPC (remote procedure call) portmapper was invented by Sun Microsystems, and is both good (useful for network programming) and bad (raises security challenges). Its operation means you can code network daemons without assigning them ports, and instead have them request the portmapper for an assignment. The challenges are several: (1) It leaks valuable information about the system to the bad guys. (2) Its complexity means it's a likely place for vulnerabilities to crop up. (3) When you hear of such vulnerabilities, disabling it might be prohibitively painful, because too much relies on it. (It's a single point of failure for other things.) (4) Because it assigns ports dynamically to services that rely on it, those services no longer run on predictable ports, which makes them much harder to protect.

For all of those reasons, a running portmapper tends to make security people antsy. If it must be left running (e.g., because of NFS or NIS/NIS+ daemons, on Unix boxes), then security folk will try to heavily protect it.

123/udp open ntp

Network Time Protocol server. Just to clear up a point of frequent confusion: Many users, reading these reports, have as their initial reaction "Oh, Network Time Protocol sounds desirable. I definitely want my machine to have the correct time and be sync'd to atomic clocks. That's really cool. I certainly wouldn't want to turn that off or block it." But that's confusing two very different things: It's one thing to want your machine to be an NTP client and quite another to want it to be an NTP server. That item (and this list generally) consists of server broadcasts that XP is offering up to the world at large.

137/udp open netbios-ns

NetBIOS name server for SMB file/print services. In other words, this is the broadcast of resource-name information that would show up in other people's Network Neighbourhood listings, and corresponds to Samba's nmbd.

138/udp open netbios-dgm

NetBIOS datagram server for SMB file/print services. This is the broadcast of your system's actual file/print data to the wide world, and corresponds to Samba's smbd.

139/tcp open netbios-ssn

NetBIOS Session Service. Remote access to NT domain SID / host SID / browse-list information and guest-user login (NULL session). Very worrysome information leakage of security-sensitive information, there.

500/udp open isakmp

Key management (isakmp/oakley). This is Internet Key Exchange ("IKE") negotiation traffic for Kerberos5 authentication to Active Directory domains.

1025/tcp open NFS-or-IIS

On some hosts, this is IIS, NFS, or network blackjack, but on XP/W2k it might be (but see note on ports 1024+, following) the Task Scheduler service (MSTask.exe) listening for....? I can't even imagine why on Earth it would want to accept task requests from remote. Words fail me. To disable it, disable "Task Scheduler" in the services list.

If that is indeed what it is, then (to reiterate) it's a crying shame that it's so non-obvious how to make Windows services bind only to the localhost (aka loopback) network interface and not outside interfaces, so that they can be accessible from the local machine but not elsewhere.

"NET STOP Schedule" at the command line will do a runtime halt of the service.

1031/udp open iad2
1032/udp open iad3

Per IANA (as reflected in the standard Unix /etc/services list[1]), these are both supposed to be "bbn iad". In other words, they were assigned to Bolt, Beranek, and Newman (a firm that was one of the Internet's architects) for some long-forgotten project. However, in this case, they're in the range (1024 and up) that Windows NT and pieces thereof (MSTask, DNS Manager, Microsoft Exchange Administrator, WINS server, etc.) usually uses for dynamically assigned ports. If a server listens on a port but does not care what port number it uses, the portmapper assigns it one of those port numbers.

Often on a Windows box these are Microsoft RPC/DCOM services. Since the clients use the port mapper (port 135) to find the service, it does not need to reside on a fixed port number. (This is similar to how Sun RPC services work, though they use a different underlying protocol and a different portmapper port, number 111 TCP and UDP).

See: [link|http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q154/5/96.ASP&NoWebContent=1|http://support.micro...SP&NoWebContent=1] ...on how to regulate the Microsoft RPC portmapper's port usage via a Registry key (e.g., for the benefit of a firewall, so you can predict exactly what ports will be used).

1900/udp open UPnP

Universal Plug and Play Simple Service Discovery Protocol (SSDP) server, letting other hosts do discovery of its hardware offerings over networks and letting those offerings appear in those hosts' My Network Places listings. As one wag puts it, "UPnP/SSDP is the technology that, in years to come, will allow our refrigerators and can openers to send e-mail to our automobiles and softball mits. When the promise of IPv6 is realized such that every grain of sand on every beach can have a MAC address, Universal Plug 'n Play will undoubtably let remote hackers know we are running low on butter, and enable leet TCL scripts to lock us out of our own cars."

5000/tcp open UPnP

Universal Plug and Play: Specialised sort of Web server, advertising UPnP information via HTTP.


The above analysis is necessarily uncertain because it's based on an entirely outside view of the XP host (from a remote Linux box running nmap). Because of that, there is some guesswork (in particular cases) about what XP process is actually responsible for listening on a specific network port. Relevant to that problem, an intereseting tool:

[link|http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/proddesc/fport.htm|http://www.foundston...roddesc/fport.htm]

Quoting the Web site:

[Foundstone, Inc. "fport"] (TCP/IP process-to-port mapper) reports all open TCP/IP and UDP ports and maps them to the owning application. This is the same information you would see using the 'netstat -an' command, but it also maps those ports to running processes with the PID, process name and path. Fport can be used to quickly identify unknown open ports and their associated applications.

Late addition: My mother-in-law tried that program, and on the ports of interest it gives almost no useful information, saying just "system" as a description for most of them. Additionally, it lists processes binding to loopback only along with those binding to outside network interfaces, making no distinction between them. Still, maybe worth the download.

I also saw reference to a tool called "Inzider" to do pretty much the same thing. [link|http://ntsecurity.nu/toolbox/inzider/|http://ntsecurity.nu/toolbox/inzider/]

If you're running a Windows machine, it'd be an excellent idea to run such a utility to determine for certain what specific process is serving up each broadcast network service. You may or may not be able to act usefully on that information -- such as turning off pointless, resource-wasting network daemons or restricting them to localhost -- but knowing is better than not knowing,and at least you have a fighting chance of doing something less indiscriminate and scattershot than global blocks of thousands of ports (a la Microsoft Internet Connection Firewall, ZoneAlarm, BlackICE, etc.).

[1] I have a copy of someone's expanded version at [link|http://linuxmafia.com/~rick/linux-info/services-augmented|http://linuxmafia.co...ervices-augmented]

Rick Moen
rick@linuxmafia.com