The AOLserver list has had a thread going today about the nimda worm. Some sites are being hit by hundreds of requests. To avoid the cost of these hits a filter is being used to capture these hits and hold the connection open for a minute or so. This seems to help because the worm tries numerous exploits before moving on to another ip.
The filter I am using is being sourced from the private tcl/init.tcl file, which should guarantee that it is the first to be read at server startup. In that script I register a filter for preauth. This should guarantee that it is the first filter to run for a matching request. For some reason rp_filter is still running. Below is the filter, and some of the server log showing what is being executed per request.
nsv_set nimda conns 0
nsv_set nimda max 20
nsv_set nimda count 0
proc nimda {conn ignore} {
global breaktrace
set breaktrace 1
set req [ns_conn request]
set reqlist [split $req " "]
set url [lindex $reqlist 1]
set host [ns_conn peeraddr]
nsv_incr nimda count
if {[nsv_get nimda conns] < [nsv_get nimda max]} {
nsv_incr nimda conns
ns_sleep 60
nsv_incr nimda conns -1
}
ns_returnredirect http://$host$url
return filter_return
}
proc nimda_breaktrace {conn ignore} {
global breaktrace
if {[info exists breaktrace] && $breaktrace == 1} {
ns_log Notice "Nimba BreakTrace holding: [nsv_get nimda conns]
total: [nsv_get nimda count] [ns_conn peeraddr]"
return filter_return
}
return filter_ok
}
ns_register_filter preauth GET /scripts/* nimda
ns_register_filter trace GET /scripts/* nimda_breaktrace
------ Server.log ---
[18/Sep/2001:15:21:13][2986.15375][-conn5-] Notice: Security:
1000851673 sec_generate_session_id_cookie setting 340225, 0.
[18/Sep/2001:15:21:15][2986.25612][-conn11-] Notice: Nimba BreakTrace
holding: 2 total: 241 216.138.84.30
Also, not shown are calls to ad_permission looking for a match on the directory.
Any hints on how rp_filter is getting into the request?
Request notifications