Webserver Security (Part I)

This first article in a two-part series deals with tools to find security holes in webservers and workstations. Some of the topics covered are: port scanning, finding NFS security holes, and using lsof.

If you examine the security problems reported with stolen credit card numbers or web server defacements in the last few months, it becomes obvious that many web applications have been slapped together with little care or planning for security. What are the most common problems leading to insecure webservers and how does one avoid them? How can one as a customer or end user recognize if a server fullfills the most elemental security requirements?

An analysis of the reported security flaws shows that most problems belong into one of three categories:
  • The server offers services to the public it was not intended to offer.
  • The server keeps supposedly private data in publicly accessible areas.
  • The server trusts data from untrustworthy sources.
{mospagebreak title=The server offers services it was not intended to} Obviously many server operators have never had a look at their machines from the outside, for example with a port scanner. If they had, they would not be operating so many services on their machines which have no place on a production server or which need not be accessible from all IP addresses. One promiment example was featured on the Heise newsticker. This particular server, a german bookstore, was being operated completely without a firewall (“for performance reasons”) and exported several filesystems via Sun Network Filesystem world writeable. Their Oracle database was connectable from everywhere, too. For increased convenience, passwords for Oracle connections were stored in scripts available from the exported network drives. Could this be your server? Have you looked recently?

Often this particular mistake is being combined with the use of insecure and snoopable protocols for maintenance access. For example, on webservers there are commonly POP3 accesses to gather orders and FTP accesses or even database access to upload new article data. These protocols may in some cases offer secure authentication (i.e. APOP) or even secure transmission (i.e. SSL versions of POP or FTP), but commonly the insecure versions of these protocols are used. Some protocols, such as the msql database server, offer almost no authentication at all.

It is good advice for webmasters to get network access outside of their company and run a full scale scan and attack against their own site to see what happens. Services that were available in the default configuration of a machine after install or which were needed during installation and initial deployment may not have been shut down properly. For example, some systems come with a webserver on a nonstandard port serving example scripts and manuals. These servers contain often erroneous CGI scripts or can become a security risk in other ways. There is no need to keep such servers around on a production machine accessible from the Internet – shut these services down. Another very common source used by attackers is SNMP (Simple Network Management Protocol), which will give a potential attacker extremely verbose and valuable information about your system and network layout. Because this is an UDP service, it does not show up on many of the simpler security scans.

Of course, not only web servers need protection. All other machines hosted outside the firewall much conform to the same security standards.{mospagebreak title=nmap-Scan against an example host} You can get nmap at http://www.insecure.org/nmap/
# nmap -sS -T Agressive -p 1-10000 www.example.server | grep open
Port    State       Protocol  Service
21      open        tcp       ftp
22      open        tcp       ssh
25      open        tcp       smtp
80      open        tcp       http
111     open        tcp       sunrpc
119     open        tcp       nntp
3306    open        tcp       mysql
4333    open        tcp       msql
www.example.server is being used as a WWW and FTP server. Additionally, it offers ssh, smtp, sunrpc, nntp, mysql and msql.

Of these, ssh is a protocol with strong encryption and authentication. It should be safe to use, if a current version of the server is being run.

http, ftp, smtp and nntp are the actual services provided by this server and need to be up and running. As long as FTP is being used only for anonymous services no passwords are being transmitted in clear. All other file transfers should be done using the scp utility and the ssh protocol.

The sunrpc, mysql and msql services need not be accessible from outside the firewall to all IP addresses. These ports should be blocked at a firewall or a packet filter instead.

For all services offered to the public you need to keep track of current versions and security information about these programs. Prepare to update quickly if security issues come up concerning any of these programs. For example, there have been problems with certain versions of ssh, where the server could be tricked into running nonencrypted connections under certain circumstances. Buffer overflows or other security relevant problems are known for several ftp servers, for old versions of sendmail and for some releases of INN.

There can be cases where your scan does find an open port, but you are unable to tell which program is operating on this port. Here a tool as lsof comes in handy. The command “lsof -P -n -i” can list all locally opened ports and the programs operating on these ports.
# lsof -P -n -i
COMMAND    PID USER   FD   TYPE DEVICE SIZE NODE NAME
xfstt       46 root    4u  IPv4     30       TCP *:7100 (LISTEN)
httpd      199 root   19u  IPv4     99       TCP 192.168.1.12:80 (LISTEN)
…
smbd     11741 root    5u  IPv4  28694       UDP 127.0.0.1:1180
smbd     11741 root    6u  IPv4  28689       TCP 192.168.1.3:139
                             ¬ -<192.168.1.2:1044 (ESTABLISHED)
With additional options you are able to search for specific protocols and ports:
# lsof -P -n -i tcp:139
COMMAND   PID USER   FD   TYPE DEVICE SIZE NODE NAME
smbd      276 root    5u  IPv4    175       TCP *:139 (LISTEN)
smbd    11741 root    6u  IPv4  28689       TCP 192.168.1.3:139
                           ¬ -<192.168.1.2:1044 (ESTABLISHED)
{mospagebreak title=Dumping a zone using nslookup} To get a listing of all known hosts in a domain you could run nmap scan against the complete network containing the server of interest. Alternatively you could look into the DNS and see what the server operator has published about his domain.

Using the example.server domain again:
# nslookup

< set type=ns
< www.example.server.
Server:  ns.provider.net
Address:  10.4.3.1

example.server
        origin = ns.example.server
        mail addr = postmaster.ns.example.server
        serial = 2000032201
        refresh = 10800 (3H)
        retry   = 3600 (1H)
        expire  = 604800 (1W)
        minimum ttl = 86400 (1D)
< server ns.example.server
Default Server:  ns.example.server
Address:  192.168.129.37

< ls example.server.
[ns.example.server]
$ORIGIN example.server.
@                       1D IN A         192.168.240.131
wwwtest                 1D IN A         192.168.240.135
news                    1D IN A         192.168.240.136
localhost               1D IN A         127.0.0.1
listserv                1D IN A         192.168.240.136
…
igate                   1D IN A         192.168.129.34
The “set type=ns” (Nameserver) command instructs nslookup to ask only for information about the nameserver of a domain. Our query for “www.example.server.” will then return all nameservers for that host, in this case only a single server, “ns.example.server.”

We now use the command “server ns.example.server” to direct all further queries directly to that server. With “ls example.server.” we ask that particular server for a complete listing of the zone “example.server”. We receive a listing of all hostnames and ip numbers published by the operator of example.server.

A better-configured BIND8 allows us to limit zone transfers to known secondary name servers. “ls” commands from arbitrary hosts will be blocked and logged. If a domain has multiple nameservers it is often worthwile to try all of them: While the primary server is often secured, the secondaries are not and will happily list the zone for you.

Security conscious network operators run their internal DNS from a different server than their Internet setup. There is no need to tell the world which machines are running in your offices and how they are named. It is completely sufficient to publish the names and addresses of your production machines.{mospagebreak title=Other Helpful Tools}

Use the gnome program Cheops (http://www.marko.net/cheops) to produce a graphical network plan with machine types and connections. The program can do portscans, too, but is not as flexible and powerful as nmap.




Using the network monitor Ethereal (http://ethereal.zing.org/) to analyze network traffic. Ethereal can follow TCP streams and is useful for dumping clear text passwords as transmitted by telnet, ftp, pop3 and other protocols.{mospagebreak title=rpcinfo query to www.example.server} Using rpcinfo and showmount (Linux: also kshowmount in some installations) you may query which services the sunrpc service of your machine offers. If NFS is running, it is possible to get a list of exported filesystems from the server.
# rpcinfo -p www.example.server
   program vers proto   port
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
As can be seen, the sunrpc service of www.example.server is talking to external machines like ours. This is unnecessary and can be blocked by installing a rpcbind program with access control or by configuring the firewall.

Because the NFS defaults are as braindead as the behaviour of NFS in case of syntax errors in the configuration file, it is a very common error to export filesystems completely unprotected and world writeable. Here a particularly severe case:
# /usr/sbin/kshowmount -e center2.sample-university.net
Export list for center2.sample-university.net:
/usr/lib/cobol       (everyone)
/usr/sys/inst.images (everyone)
/stadtinf            (everyone)
/var/spool/mail      (everyone)
/usr/lpp/info        (everyone)
/usr/local           (everyone)
/pd-software         (everyone)
/u1                  (everyone)
/user                (everyone)
/fix                 (everyone)
/u                   (everyone)
/ora                 rzws01
/install             (everyone)
/ora-client          192.168.15.20
All directories listed as “everyone” are wide open. This includes “/var/spool/mail”, containing life mail from several hundred users as well their homes under “/u” and “/u1″. Also writeable are “/usr/local” and “/usr/lib/cobol”, making is very easy to install trojans. This system can be taken by anyone without noticeable resistance. By manipulating software under “/install”, you will probably subvert additional clients produced from the images stored in this tree. This particular system will make a fine base to trade warez and is an ideal system to launch attacks against other sites. Does their insurance company cover the damages which will follow? Does yours?{mospagebreak title=Remote SNMP queries} SNMP is a service which can provide an attacker with very detailed information about the target system and its networking environment. Many standard installations provide this service and often it is not disabled or secured. As an added bonus, this is an UDP service, so it will not show up in standard portscans – it is under the radar of many system administrators.

Again we are stalking sample-university.net:
# snmpwalk center2.sample-university.net public
system.sysDescr.0 = OCTET STRING: “Fore Systems ATM Host (AIX 1 000005016600)”
system.sysObjectID.0 = OBJECT IDENTIFIER: enterprises.326.2.1
system.sysUpTime.0 = Timeticks: (0) 0:00:00
system.sysContact.0 = OCTET STRING: “”
system.sysName.0 = OCTET STRING: “center2.”
system.sysLocation.0 = OCTET STRING: “”
system.sysServices.0 = INTEGER: 72
interfaces.ifNumber.0 = INTEGER: 7
interfaces.ifTable.ifEntry.ifIndex.1 = INTEGER: 1
interfaces.ifTable.ifEntry.ifIndex.2 = INTEGER: 2
interfaces.ifTable.ifEntry.ifIndex.3 = INTEGER: 3
interfaces.ifTable.ifEntry.ifIndex.4 = INTEGER: 4
interfaces.ifTable.ifEntry.ifIndex.5 = INTEGER: 5
…
We are told the type and patchlevel of the system, we get a list of all interfaces (not shown) and we can even use SNMP to dump the complete routing tables. This is useful to remotely gather information about the topology of the target network and enables us to direct our attacks to the strategically valuable hosts. Together with data taken from the DNS as shown above we will be able to construct a complete network map for the target. If additional management modules are being installed, we get even more important data, such as management information about Oracle, SAP or other remotely controlled subsystems. SNMP is being used in many routers and in RMON network probes, too. If these are not secured properly, we are even able to get traffic measurements from the target.
[gp-comments width="770" linklove="off" ]
antalya escort bayan antalya escort bayan