Ed, On 12/23/-58 20:59, [EMAIL PROTECTED] wrote: > Quoting Volker <[EMAIL PROTECTED]>: > >> On 12/23/-58 20:59, ;048<8@ 0?CAB8=rote: >>> 2. If i have some malware on my PC and use mail-client program. If I >>> send the same message some times I automatically get into WHITE-list >>> and my malware can spam as much as it must? >> >> Not really related to your spamd problem, but probably useful... >> >> If you need to limit an internal client system for sending out mail >> through your system, IMO you may also use pf's limit functions. >> >> Imagine something like: >> >> pass in quick on $int_if from any to $int_if port smtp keep state >> (max-src-conn 1, max-src-conn-rate 2/60) >> >> This should limit an internal client to one concurrent connection >> and a maximum of 2 connections per 60 seconds and so mass mailing by >> abusing your mail gateway should be impossible. >> >> Combining this by a rule like 'block in quick on $int_if from any to >> ! $int_if port smtp' should efficiently block spam originating from >> your internal net. > > Has anyone tried using a table and blocking smtp connections similar to > the ssh brute force solution that I've often seen on the list and have > been using happily for some time?
Yes, I'm doing this on some mail hubs. You should make sure not to block legitimate smtp clients by these rules, so take values high enough to let backup MXes etc. deliver their mail. For me, values of conn-src-rate 80/90 (maximum 80 connections in 90 seconds) work well. Using max-src-conn-rate of 30/90 caused problems when the machine has been offline for some reason and the backup MX wanted to send all buffered mail messages. Your mileage will vary! ;) > Something like: > > pass in quick on $ext_if proto tcp from any to ($ext_if) port smtp keep > state > (max-src-conn 1, max-src-conn-rate 2/60, overload <smtp-excess> > flush global) > block drop in quick on $ext_if from <smtp-excess> Nope, that's the wrong way. You let pass smtp (by a quick rule) but the block rule is after that. That is rendering your blocklist useless as all traffic is passing by the first rule. AFAIK the first connection causing an overload is being dropped but subsequent connections are still passing (as long as they don't overload). It should look like: block drop in quick on $ext_if from <blockhosts> to any pass in quick on $ext_if proto tcp from any to ($ext_if) port smtp keep state ( max-src-conn [ANYVAL], max-src-conn-rate [ANYVAL]/[ANYTIME], overload <blockhosts> flush global ) Whenever any host is overloading ssh or smtp access, I'm loading their IP address into the blockhosts table and so the machine will never again talk to that IP address (forever!). You may want to do it different (for example flushing the table once a week or at midnight). One machine running this for months has already blocked 1400 IP addresses and as far as I've checked, all have been dynamic zombies (no regular mail clients have been blocked by that). I haven't found a way to use that mechanism to block such hosts for, say 120 minutes (which would be a great feature). > Could it work and be controlable or would it make a bad situation worse? You may use a blocking mechanism like that for any other host service, too. If you're going to use that for UDP "connections" you should be aware that they're connectionless and so options like " max-src-connXXX" don't match here. HTH, Volker _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
