...making Linux just a little more fun!
Ben Okopnik [ben at linuxgazette.net]
[[[ I viciously snipped out the entirety of the original message which headed this thread, as it was horrendously replete with html garbage. - Kat ]]]
On Fri, Jul 06, 2007 at 11:33:15AM -0400, Bank Of America wrote:
> Bank of America Higher Standards > Online Banking Alert > Need additional up to Re-Update Your Online Banking > the minute account > information? Sign in Because of unusual number of invalid login > attempts on you account, we had to believe > that, their might be some security problem on > you account. So we have decided to put an extra > verification process to ensure your identity > and your account security. Please click on sign > in to Online Banking to continue to the > verification process and ensure your account > security. It is all about your security. Thank > you. and visit the customer service section.
[snip] Nice, even though completely ungrammatical. The 'sign in to Online Banking' link points to
https://www.tsv-betzigau.de/contenido/includes/hypper/repute/bankofamerica/online_bofa_banking/e-online-banking/index.htmTheir images are coming from yet another domain:
https://release35.par3.com/images/client/bankofamerica/em_logo.gifYet another example of PHP fuckmuppetry. And this isn't going to stop, since the creators of PHP refuse to fix the well-known vulnerabilities in the language. [sigh]
If someone who speaks Deutsch wants to contact the owners of the first domain and let them know, that would be a nice thing to do. I've just contacted the webmaster of the second domain; hopefully, they'll take that garbage offline and fix their leaks.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Rick Moen [rick at linuxmafia.com]
Quoting Ben Okopnik (ben@linuxgazette.net):
> [snip] Nice, even though completely ungrammatical. The 'sign in to > Online Banking' link points to > > `` > https://www.tsv-betzigau.de/contenido/includes/hypper/repute/bankofamerica/online_bofa_banking/e-online-banking/index.htm > '' > > Their images are coming from yet another domain: > > `` > https://release35.par3.com/images/client/bankofamerica/em_logo.gif > ''
Also, just so you know, I nuke the originating SMTP hosts' IPs (blacklist them in my MTA configuration), the moment they bleat these phishing frauds in our direction. You'll therefore never see two fraudmails from the same IP -- or at least not unless they're really quick. (It's a bit harsh, but I hold the admins responsible for their outgoing traffic.)
Of course, it would be good if I were able to also reject more of them up-front (without collateral damage), something one works on, as an MTA admin, but must be careful in testing.
Martin J Hooper [martinjh at blueyonder.co.uk]
Rick Moen wrote:
> Of course, it would be good if I were able to also reject more of them > up-front (without collateral damage), something one works on, as an MTA > admin, but must be careful in testing.
Wouldn't something like Spamassasin work for filtering out the phishing?
Rick Moen [rick at linuxmafia.com]
Quoting Martin J Hooper (martinjh@blueyonder.co.uk):
> Wouldn't something like Spamassasin work for filtering out the > phishing?
As a SMOP, yes. ;-> (https://www.catb.org/jargon/html/S/SMOP.html)
As background:
The MTA (Exim) has a fairly elaborate set of rules used to check the incoming SMTP stream prior to saying "200 OK" in the SMTP conversation (rules including "callback" ones that check the delivering IP for RFC-complianc). Then, if the stream passes those tests, and still before Exim is willing to say "2000 OK", Exim runs a system-wide SpamAssassin check on the mail, and allows the mail through only if SA-measured spamicity isn't too high.
Deferring the SA-checking until after the more-extensive Exim rules is important for system performance, as Exim's engine is much lighter and faster than SA's.
Anyhow, if someone can tackle the phishing exercises du jour and craft appropriate rulesets for me, preferably that don't also produce too much collateral damage, I'll be glad to drop them in.
I'm not really good at writing those, myself -- and badly written SA rules turn out to be a very nicely efficient way to make a mail server fall over. I know this empirically, from having insouciantly grabbed a bunch of rules from https://www.rulesemporium.com/rules.htm (and yes, I did check them with spamassassin -D --lint), restart spamd, and watched spamd immediately eat all my RAM.
(I do play with SA settings, occasionally, I'm just saying I have to be careful about it, given that it's a production system and I really hate having to drop everything and deal with sudden emergencies.)
