Hmmm... Please allow me to combine two different sub-threads. >>> simran <[EMAIL PROTECTED]> 03/07/03 12:02AM >>> On Fri, 2003-03-07 at 13:51, R. Joseph Newton wrote: > Wiggins d'Anconia wrote: > > > > > In general this would be handled with a lock file. When the first
<snip> > Good idea, but I think the lock file in this case needs a little more information--specificically, the ip address currently being inserted into the blacklist file. That way, if the new ip in the queue is identical to the one being inserted, the insertion is dropped, but if the ip is different, it waits in the queue to be added next. > > Joseph <snip> >You might want to use the flock subroutine in perl and use that... >( http://perl.about.com/library/weekly/aa011203a.htm ) > >simran. > and from Luke Bakken's response: > >The following should be atomic, and thus can be used for a **simple** >locking mechanism: > >use Fcntl; > >until ( sysopen F, $lockfile, O_CREAT|O_EXCL ) { > sleep 10; >} >close F; How about if I use /dev/shm for the storage area? A shared memory file system should be pretty quick, and I don't have to worry about stale locks when the system reboots. What if I create a file /dev/shm/bad-ips and use flock to simply open the file exclusively? If I succeed in the open() I am either first or alone in trying to detect an abuse. If I fail, I simply loop until success or 10,000 tries. Once I have the file open, I scan for the IP that is being nuked. If I find it, unlock and close the file and exit. If I don't, run the iptables command, log the entry, update the bad-ips file, unlock and close it. I'm not tracking bad IP numbers across reboots, only in the log files. If an IP shows up a couple of times in my log file I add it to my firewall script as a permanent nuke. Holes? Other issues with /dev/shm I'm not aware of? Thanx! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
