Sam Varshavchik wrote: >> Unfortunately, that cannot be done with netfilter queue: one invokes >> the userspace program with "iptables -A <cond> -j NFQUEUE". (<cond> is >> where one can decide about packet direction, SYN flag, and the like.) >> The userspace utility will only be able to say ACCEPT or DROP. Mine, >> ipqbdb, just looks up a bdb file to decide the verdict. >> >> Iptables also has a "recent" module, that can be specified in the >> <cond> in order to match a dynamic list of IPs. That allows to specify >> "-j REJECT" as the action. However, the dynamic list consists of plain >> files; they can be read and written from userspace programs by >> accessing /proc/net/ipt_recent/<name>, but it is not clear how >> synchronization with the kernel can be achieved. >> >> Any other ideas for blocking existing connections? > > I don't follow. If you insert a rule to REJECT outbound packets to a > given IP address,
Since the IP address is dynamic, AFAIK the rule has to use "-m recent" in its <cond> part. I dislike updating ipt_recent's virtual files from userspace because of the above mentioned synchronization problem. Possibly, it's just me being overly ignorant about iptables inner workings... > if there's an existing connection, its next outbound > packet will get rejected, and the socket layer should then drop the > connection, passing back an ECONNRESET to the application. Correct, AFAIK. > netfilter > doesn't just look at initial SYNs, it can also reject packets from > existing connections. No, it seems netfilter queues can only drop (or accept) packets. :-( >> Using smtpaccess is clever. However, its access is implemented >> generically and I'm not sure one can deploy, say, bdb's concurrent >> data store model. Does that imply using makesmtpaccess (and restarting >> couriertcpd) every time? > > There is no need to restart couriertcpd. Couriertcpd detects when the > smtpaccess file has changed, and reloads it. However, "couriertcpd -restart" is issued by makesmtpaccess. In case someone else is following this thread, let me clarify that makesmtpaccess does synchronization by creating a new file and then using rename. Running processes that have an open handle to the old inode may continue to read it (even without a directory entry), and the inode will be freed when the last one closes it. W.r.t. ipt_recent's virtual files, I don't think using this technique in the /proc filesystem would make sense. > This does not need to be realtime. Updating the list hourly should be > sufficient. Even with several thousand records, makestmpaccess > shouldn't take long to rebuild. Fine, thanks :-) ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
