Section 10.9 Nonprofit Organization Runs Out of Luck | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

10.9 Nonprofit Organization Runs Out of Luck

In the first edition of this book, we looked at an organization's Web site that made the effort to use HTTPS (SSL-wrapped http) when accepting a new member's personal data and credit card number, but then accepted the new member's password in clear text over the Internet. That was two years ago, and I did them the courtesy of sending them an e-mail notifying them of the problem.

Several years later, my pager received an alert that this organization's DNS server tried to SSH into one of my client's networks. This occurred at 4:32 P.M. in the organization's time zone. (The Cracker Trap had locked them out immediately so my client was in no danger.) I telephoned the organization's New York and Washington offices to alert them to a possible compromise of their DNS server. At both offices, I was connected to answering machines with no mention of an after-hours emergency number. I left messages explaining what happened and my concern that their DNS server may have been compromised, along with my name, telephone number, and e-mail address.

This organization made a number of technical and policy errors. Lessons to be learned include:

Run minimal services on critical servers.
Never run X on critical systems. When you do use X, commonly on desktop systems, invoke it with the -nolisten tcp argument so that it will not listen on TCP port 6000 or use IP Tables to block its access to all but trusted systems. Using SSH's encrypted X channel is a much preferred option for remote X access.
Use a firewall and include Egress filtering. Servers like this (i.e., ones that should be in a DMZ anyway) should be blocked by the firewall from initiating any connections to the Internet that are not necessary for their job. In other words, a DNS server should be allowed to send DNS requests only to the upstream DNS server and only receive DNS requests from those that it serves. A Web server should only be allowed to send HTTP and HTTPS replies (and possibly send e-mail and communications with its back-end database or similar server) and initiate DNS requests to the organization's DNS server.
This way, even if a buffer-overflow attack against named was successful, the server could do nothing but send evil packets to those making DNS requests of it and send them to its upstream DNS servers. Had this been done, my client never would have been attacked.
Scan your network from the Internet by doing
```
 
```
```
 nmap -P0 -sT -O -F -sR -I -T Aggressive yournet/netbits 
```
This usually will reveal problems.
Have a good procedure for handling possible compromises. There should be a 24-hour emergency phone number on the Web site, in publications, and available from telephone information.
Train your frontline people who answer the phones to treat all calls regarding possible security problems as emergencies.

Shortly before noon the next day, I received a phone call from a woman in their office who seemed to me to be very "put out" by my message. When again I explained what had happened, she said that I should go onto their Web site and leave a message and was clearly hoping that I would just "go away." I said that since their computers may have been compromised, the hacker may delete my e-mail before their people see it. (I used "hacker" because I doubted that she was familiar with the term "cracker.") The line went quiet without explanation and there was no one on the other end.

As I was debating whether I had been hung up on, she came back on the line and said that there was no answer when she tried to reach their computer operations department. I reiterated the importance of this matter and asked that she contact someone and that I wanted a call back with status. I never received any further contact. An nmap scan of their DNS server offered only one service: X. This did not appear to be a trap similar to the Cracker Trap technique discussed in "Adaptive Firewalls: Raising the Drawbridge with the Cracker Trap" on page 559. My nmap scan of this system (allowed by those in the southeastern U.S. due to a Federal District Court ruling) also showed no firewall rules in place.

Top