another honey pot thought |
Post Reply |
Author | |
keizersozay
Groupie Joined: 26 January 2005 Location: United States Status: Offline Points: 77 |
Post Options
Thanks(0)
Posted: 10 May 2005 at 12:15pm |
I really like the new honey pot feature, but I think it can be expanded to also read a file for content. Right now it just checks to see if the 'email to' is in the honey pot address list, but what about adding a honey pot keyword file (with regex support) This could be real dangerous, but if you know that certain email content is alway spam like... well, I can't think of anything right now, but you know what I mean. What do you think? |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
In the next build we've added support for an extra tag in some of the
blacklists, similar to the :NULL and :NoNDR tags already supported. The
new :Honeypot tag will cause the sender's IP to be added to the
honeypot blacklist when there's a match for the particlar blacklist
entry with the :Honeypot tag.
Unfortunately this does not apply to the keyword filter, as that list does not support the extra tags... |
|
Desperado
Senior Member Joined: 27 January 2005 Location: United States Status: Offline Points: 1143 |
Post Options
Thanks(0)
|
Real Nice! Will you list the Black Lists that this tag will be valid in? Regards, |
|
The Desperado
Dan Seligmann. Work: http://www.mags.net Personal: http://www.desperado.com |
|
keizersozay
Groupie Joined: 26 January 2005 Location: United States Status: Offline Points: 77 |
Post Options
Thanks(0)
|
Great idea Roberto. Looking forward to it. Thanks again |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
keizersozay,
Another valid idea. Most likely it will be included in the next build. If you email us directly we can provide you with an alpha version for you to test (it's available right now). |
|
Alan
Groupie Joined: 06 May 2005 Location: United States Status: Offline Points: 43 |
Post Options
Thanks(0)
|
Roberto at one point last year the use of the extra tags (null, nondr)
on keywords was talked about being implimented and may have been for
test-build, but now it appears it is not. It may have been a
performance issue.
This is still something I would really like to be able to utilize. While keywords are not my weapon of choice they still act as one layer that catches a lot of spam, especially for certain short term spam campaigns. |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Alan,
We've implemented "modifiers" for many of the blacklists, but as we've talked about i nthe past, the keyword list does not the use of any extra tags. The reason for this is that the list supports wildcard filtering and RegEx filtering. Adding support for a modifier will make the parsing engine do too much extra work to handle it at the moment. We've tested some workarounds (using something other than the defualt ":" to designate a extra tag) but we don't have any time estimates on when it will be implemented yet. |
|
Alan
Groupie Joined: 06 May 2005 Location: United States Status: Offline Points: 43 |
Post Options
Thanks(0)
|
Thanks Roberto. This is a big want for me. It would really
help clean up and reduce the size of the quarantine that users would
have to look through.
|
|
Marco
Senior Member Joined: 07 June 2005 Location: Netherlands Status: Offline Points: 137 |
Post Options
Thanks(0)
|
I was going to suggest the exact same (topic), from then on anyone with 'case of fine wine' 'improved cialis without prescription' (to name some) in the subject would get blocked into oblivian.
This feature would only need to be active for a limited time, and would catch quite a few of the badasses that got hold of our domain name and are swamping it with spam. Any users that forward such spam and dont change at least the titles are deserving of a block :-> But i would also like to see a limited timeblock, say - a day- with notification to the sender, so that they are warned not to do it again.
Just my 2 cents
|
|
Anyone who is capable of getting himself made president, should on no account be allowed to do the job. D.Adams
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Marco, Alan, keizersozay, everyone,
We now have a pre-release build that does include support for extra tags in the keyword filter as well. This was done with practically no performance loss. The build is still being tested, but is available in the registered user area as build 2.6.3.476. The syntax for the extra tag had to be slightly different. In this list you MUST use a double colon rather than a single one to separate the tag from the keyword entries. The updated help file for that sectionis as follows: Keywords Filter - You can check email content and subject header for specific keyword and/or phrases. If found, the email is rejected. You can also use Regular Expressions (RegEx). If the keyword file does not exist it will be created. The file is reloaded every minute. The contents of the file will be loaded in the memo box, allowing you to make changes to the file. This list supports the ::NULL option to send emails in a black hole. If an entry is in the form keyword::NULL it will cause all emails to be accepted and then sent to NULL right away. Such emails will not cause NDRs, they will not be quarantined, they will not be seen by the users. If an entry is in the form keyword::NoNDR such emails will not cause NDRs as in the DoNotSendNDROnQuarantine parameter in the ini file. This list supports the ::Honeypot option, which will cause the sender's IP address to be automatically blacklisted in the future. Please note that unlike in other cases, with the keyword list you must enter the ":" symbol twice to specify the extra tag. |
|
Marco
Senior Member Joined: 07 June 2005 Location: Netherlands Status: Offline Points: 137 |
Post Options
Thanks(0)
|
Fantastic! great work roberto.
just to make sure, the following lines are correct? subject:challenged on live tv::honeypot Edited by Marco |
|
Anyone who is capable of getting himself made president, should on no account be allowed to do the job. D.Adams
|
|
Marco
Senior Member Joined: 07 June 2005 Location: Netherlands Status: Offline Points: 137 |
Post Options
Thanks(0)
|
ok, one of them badasses sent us one... and it seems to work.. but you guessed it: the ISP's relay server got blocked :))) I think the order of filters needs to be looked at again, so that DoNotAddIPToHoneypot has preference again. Other than that it works great! This is gonna give the spammers some serious headaches. How to try and sell something if the text needed to sell it will cause you an ipblock? muhahaha (sorry, was beeing myself for a sec there) :) regards, Marco Edited by Marco |
|
Anyone who is capable of getting himself made president, should on no account be allowed to do the job. D.Adams
|
|
Alan
Groupie Joined: 06 May 2005 Location: United States Status: Offline Points: 43 |
Post Options
Thanks(0)
|
Thank you Roberto for getting such a jump on that one. It really
has made a noticable difference already in my testing. And I do
not see any performance hit either. I am still very impressed at
how quickly you have been able to encorporate new ideas and user
requests over the years of using SF.
Seems like some of the old requests from years ago are starting to get included in the product now. So how about some way to set a time limit on filters? Maybe something like "::NULL/08102005" to have a filter that will no longer be effective as of a certain expiration date (08/10/2005 in this case). Of course it would be either up to the admin to clean up or you can have the app auto-remove expired filters. This would be good for outbreaks or spambot attacks where certain is suddenly a big problem but will probably not be in the future. And another thought, a way to also scan within attached text files such as spoofed bounces resulting from joe-job instances. Oh and finally, how about that darned mailing list for registered users so we can be notified immediately of new official and beta versions? That seems like a no-brainer and another reason for people to pony up for a fine product. |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Alan,
We honestly don't see expirations on filters to be available any time soon. What we do have next on the list however is a "timed cache" on source IPs. If an IP has sent more that "n" number of spams in the last "x" number of minutes, it will be immediately disconnected even before it sends any data for "y" number of minutes. This will save a considerable amount of bandwidth and will prevent filling user's quarantine with massive amounts of spam to sort thru. We're trying to make these options available for each type of filter, so that for example the timer is active on the "virus" filter but not on the "reverse DNS" filter. |
|
Marco
Senior Member Joined: 07 June 2005 Location: Netherlands Status: Offline Points: 137 |
Post Options
Thanks(0)
|
Maybe you missed the hidden bugreport i mentioned in my earlier post Roberto, just making sure. The DoNotAddIPToHoneypot ini entry is beeing ignored in build 476 Regards,
Marco |
|
Anyone who is capable of getting himself made president, should on no account be allowed to do the job. D.Adams
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Marco,
I'm not sure if you refer to your comment below or not: ============================== I think the order of filters needs to be looked at again, so that DoNotAddIPToHoneypot has preference again. ============================== If it's not this comment, but another "hidden bugreport", then it's hidden really good since I have no idea of where it is... Can you repost it? If instead it was the above comment, it looked like a "wish" not a bug report. Looking over the behavior again, we noticed that the DoNotAddIPToHoneypot optionis doing exactly what it was asked and designed to do. That is, if an email comes in from an email address that is in the honeypot email list, the IP won't be added if it's listed in the DoNotAddIPToHoneypot list. When we started adding extra tags to add sender's IP to the honeypot blacklist if they triggered other filters, that process ignored the DoNotAddIPToHoneypot. It's technically not a bug... but you're correct, it would be more appropriate if that "whitelist" would be expanded to all other filters as well. We're pre-testing a build with this ability internally right now. We'll make it available in a few days, but if you wish to test it please let us know and we'll make it available to you. |
|
Marco
Senior Member Joined: 07 June 2005 Location: Netherlands Status: Offline Points: 137 |
Post Options
Thanks(0)
|
ahh, that is exactly what i was referring to, and i see how it happened. The problem is that an 'unknown' sender is mailing us spam to legit mail adresses. adding those adresses to honeypot list is not an option. Since the senders don't use honeypot adresses, and some of the incoming mails are relayed throuygh to our primary mailsystem, the possibility that the relay's ip gets trapped is high. This is what happened, and i agree, the honeypot is working fine, but the donotaddiptohoneypot setting needs to be applied to the content tagging system also. So maybe the tag 'honeypot' is a bit out of place in the keyword filter, perhaps a tag called '::blacklistIP' (or something) would be better. Regardless, a system that blacklists senders ip's on the basis of mail or subject content could proove invaluable. But caution has to be applied not to blacklist legit ip's. Another wish that might proove useful if possible is extending the 'automatic blacklisting' when the sender's mail is matched in MAPS and/or surbl search. Also 'FROM' domain names /attachment filter perhaps. Thank you for taking the effort in looking into this 'issue' i would gladly help test the new prerelease.
Regards, Marco Edited by Marco |
|
Anyone who is capable of getting himself made president, should on no account be allowed to do the job. D.Adams
|
|
Alan
Groupie Joined: 06 May 2005 Location: United States Status: Offline Points: 43 |
Post Options
Thanks(0)
|
How about adding a checkbox to add IP's to the honeypot block list who
exceed the "maximum concurrent connections from same IP"
|
|
Post Reply | |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.070 seconds.