Individual Entry

Limiting bandwidth hogs in SWS

I sat down at my desk one morning to perform my usual morning rituals — reading email and usenet news, and checking whether any new web site members were or were not on SPAM lists — while enjoying a first cup of coffee. I had noticed that my network seemed rather slower than usual, and I noted that the status LEDs on the Cisco router and other network equipment were near steady on. Something or someone was consuming a large amount of my network bandwidth. I checked the Cisco router syslog and looked for several other typically suspect reasons for the high utilization. I finally found it. A client in Canada was downloading files from one of my servers. Not typically a problem or I wouldn't have made these files available. However, this particular client had started numerous downloads of some rather large .ZIP files.

My first thought was to put a stop to this abuse. So, I entered $ TCPIP SHOW DEVICE to see how many downloads were in progress. I saw 6 BGAn: devices with the same IP address on socket port 80. I then entered $ TCPIP DISCONNECT DEVICE BGAn:, specifying the appropriate BGAn: for each of the connections. The network response immediately returned to normal and the LEDs on the network equipment began flashing again from their stead on state. However, the nicely quiesced state did not persist for long. In a matter of moments, the same IP connected and began to download more large .ZIP files. I immediately thought that this might be a DoS (denial of service) attack. I was very tempted to put the IP address on the block list in the Cisco router but decided against it as it could be a legitimate request for the files.

I couldn't, however, live with this download affecting the network, so stopped serving the particular virtual domain until I could do a bit of research on how to limit such files to a single download. This would satisfy two needs — my need to have some useable bandwidth and the client's need to download the .ZIP files.

I check through the documentation at the Apache.org site for some usable configuration file directives which would permit me to specify that certain files/file-types would be limited to a single connection per client/IP. Alas, after about an hour, perhaps two, I couldn't find anything in the native Apache distribution. However, I did find that there was an Apache extension module that did appear to have the requirements that I needed to limit such download activity. The module was called MOD_LIMITIPCONN.

Of course, after googling for this module, I learned there was no OpenVMS port. I posted a query to comp.os.vms to inquire if anyone had attempted to build this for OpenVMS. There were no responses. So, if I was to use this module, I would have to make the effort to port it to OpenVMS. This was my first foray into building anything for Apache on OpenVMS.

I downloaded the MOD_LIMITIPCONN-0.23 to my Ubuntu linux laptop to have a look-see at just what was involved in building this Apache extension module. There are various ways to download the source but % wget http://dominia.org/djao/limit/mod_limitipconn-0.23.tar.bz2 will get you the MOD_LIMITIPCONN-0.23 source code under linux -- Ubuntu linux in my case. I extracted the contents to a folder and went in for a closer look.

I found that MOD_LIMITIPCONN-0.23 was a single .C source file — mod_limitipconn.c — which should help to simplify the port to OpenVMS. I sftp'ed the entire folder to the OpenVMS system running the particular instance of Apache with the virtual domain that served the .ZIP files that started the whole exploration. Now, I would need the Apache source. This is, fortunately, available from the HP.COM web site. You can download it from this page at HP.COM

I restored the HP Apache build environment to APACHE$ROOT:[BUILD...]. I figured that I'd keep all Apache related code, executables, and configuration in one place. I restored all but the TOMCAT source because I wasn't using it. I then went to take a closer look at how some of the modules which are included with the SWS distribution with built. Modules are simply built as shareable images.

I then created a new directory, which I called EXTENSIONS, under the APACHE$ROOT:[BUILD] root and I copied the MOD_LIMITIPCONN.C file into it. I then attempted to compile the module using...

$ CC/VERSION
HP C V7.3-009 on OpenVMS Alpha V8.3
$ CC/INCLUDE=APACHE$COMMON:[BUILD.apache.ALPHA-CSWS-V0201-1-ECO-2...] -
_$ /NODEBUG MOD_LIMITIPCONN.C

Source file MOD_LIMITIPCONN.C built cleanly; without even so much as an informational complaint!

Next, following clues from the LINKER option files I found in the source tree for other Apache modules, I created one specifically for MOD_LIMITIPCONN. The contents of this file, which I called MOD_LIMITIPCONN.OPT, are as follows:

IDENTIFICATION="CSWS V2.1-1" ! VMS port version
BUILD_IDENT="HTTPD V2.0.52" ! HTTP release build
GSMATCH=LEQUAL,2,0 ! major.minor ID: 2.0

APACHE$HTTPD_SHR/Shareable ! HTTPD Shareable Library
APACHE$APU_SHR/Shareable ! APU Shareable Library
APACHE$APR_SHR/Shareable ! APR Shareable Library

SYMBOL_VECTOR=(LIMITIPCONN_MODULE=DATA)

APACHE$HTTPD_SHR, APACHE$APU_SHR, and APACHE$APR_SHR refer to logical names which are defined to point to the respective shareable images. Thus, Apache should be started before attempting to link MOD_LIMITIPCONN. The module was linked together using:

$ LINK/SHAREABLE MOD_LIMITIPCONN.OBJ,MOD_LIMITIPCONN.OPT/OPTION

The resultant executable image, MOD_LIMITIPCONN.EXE, was copied to APACHE$ROOT:[MODULES]. Now to check it out.

I edited the Apache configuration file, HTTPD.CONF. and I included into the file and amended the file to contain the following.


LoadModule status_module modules/mod_status.exe
LoadModule limitipconn_module modules/mod_limitipconn.exe

ExtendedStatus On

<virtualhost *>
ServerName www.virtual-domain-name.com
ServerAlias virtual-domain-name.com
ServerAdmin webmaster@virtual-domain-name.com

DocumentRoot /virtual-domain-name

<ifmodule mod_limitipconn.c>

<directory "/virtual-domain-name/*">
Options +Indexes
Options +Indexes
IndexOptions +SuppressLastModified +NameWidth=*
AllowOverride None
Order allow,deny
Allow from all
MaxConnPerIP 1
OnlyIPLimit application/x-gzip application/zip

</directory>

</ifmodule>

ErrorLog logs/virtual-domain-name.error_log
CustomLog logs/virtual-domain-name.access_log "%h %l %u %t \"%r\" %>s %b" env=!no_log
</virtualhost>

The Apache server was restarted to read and use this newly amended configuration file. I then set out to test it.

MOD_LIMITIPCONN appeared to do everything I needed and wanted it to do. As configured, there were no restrictions placed on any typical web page accesses. However, when I clicked on one of the large .ZIP archives to start a download, attempts to do the same from another browser window received a 503 error page. The only thing left to do now was to amend the 503 error page to indicate that multiple downloads of large files was limited. I added the following:

ErrorDocument 503 "<h3>Bandwidth abuser!</h3> You are limited to 1 download at a time."

to the Apache HTTPD.CONF file and restarted Apache.

There were other alternative modules providing similar capabilities and some with even greater and more flexible capabilities. Sadly, when I tried to compile those modules, I learned that the DECC RTL did not provide support for some of the unix library functions these employed. Hope looms ever eternal though as I did find that some of the needed functionality is present in the field test E8.4 of OpenVMS. I have the Apache server running on V8.3. When V8.4 is finally released, I may upgrade the operating system of the Alpha running Apache server to OpenVMS version V8.4 and give some of the other extension modules another go-around.


Comments?


To thwart automated comment SPAM, you must answer this question to post.

Comment moderation is enabled. Your comment(s) will not be visisble until approved.
Remember personal info?
Notify?
Hide email?
All html tags, with the exception of <b> and <i>, will be removed from your comment. You can make links by simply typing the url or email-address.
Powered by…