Virus Filtering by ISPs vs the need to receive security/abuse traffic
This is one that i've come across from time to time and often pondered myself - Obviously virus traffic can fluctuate up and down and become an annoyingly high percentage of an ISPs total mail load. Thus AV filtering which drops these messages is beneficial and can be provided as a benefit to customers, etc... So what happens to role accounts like, heaven forbid, abuse@ ? And for that matter, if the messages are dropped, is there any logged trace of the fact the message was sent in the first place? The reason I ask is that i've seen at least one ISP to whom i've reported viral infections to recently actually reject the report, because of the 'illegal file attatchment' (where the criteria used was the file extension... not even viral code within the attatchment)... So I had to manually copy/paste headers only to get my point across. The argument can be made that headers are all thats required, and that the actual payload isnt needed - but what if theres occaision where you want said payload? (To provide actual evidence of the infection, to identify what variant of the virus is infected, to help build filters ...?) Do ISPs out there regularly exclude their security team or at least build in means for one-off exceptions on an as-required basis? Do ISPs that drop viral (or suspected viral) traffic do anything to report said infection, or do they just drop the virus and pretend it never happened? (Doesn't actually fix the problem, does it...) Appreciate your thoughts. Mark.
This is one that i've come across from time to time and often pondered myself -
Obviously virus traffic can fluctuate up and down and become an annoyingly high percentage of an ISPs total mail load. Thus AV filtering which drops these messages is beneficial and can be provided as a benefit to customers, etc...
So what happens to role accounts like, heaven forbid, abuse@ ?
And for that matter, if the messages are dropped, is there any logged trace of the fact the message was sent in the first place?
The reason I ask is that i've seen at least one ISP to whom i've reported viral infections to recently actually reject the report, because of the 'illegal file attatchment' (where the criteria used was the file extension... not even viral code within the attatchment)... So I had to manually copy/paste headers only to get my point across.
Sounds like some braindead "filter" such as MailMarshal, if it really did reject it just based on the extension of an attachment. A real email virus scanner wouldn't reject it or drop it unless there was an actual working virus body detected in the message. Personally, I'm sick of these MailMarshal type systems, I've lost count of how many times I've received a "notification" of an "illegal file attachment" that I've supposedly sent to somebody I've never heard of before, during an outbreak of a new virus. C'mon people running these kinds of systems, clean up your act... It is surprising to hear of an ISP doing this though, especially on an abuse@ contact address...at least people in the SOHO area running their own mail servers who are usually guilty of this have the "excuse" of ignorance, but an ISP doesn't..
The argument can be made that headers are all thats required, and that the actual payload isnt needed - but what if theres occaision where you want said payload? (To provide actual evidence of the infection, to identify what variant of the virus is infected, to help build filters ...?)
Personally I can't think of a legitimate reason to purposely send an email with a working virus body to an abuse@ contact address, you're just asking for the message to either be blocked, or potentially infect the recipient, if they don't have their act together. A copy of the message minus virus should be sufficient.
Do ISPs out there regularly exclude their security team or at least build in means for one-off exceptions on an as-required basis? Do ISPs that drop viral (or suspected viral) traffic do anything to report said infection, or do they just drop the virus and pretend it never happened? (Doesn't actually fix the problem, does it...)
The truth is that there are so many viruses going around out there, that upon detecting a confirmed virus body in an email (and a virus scanner has pretty close to zero false positives, unlike a spam filter) there is really no choice but to silently drop an infected message. (Perhaps logging an entry to a log file) Who are you going to report it to ? Return addresses are bogus with modern viruses, so virus scanners that reply automatically are just inflicting annoyance on innocent third parties, the only way to track down the sender is based on a complicated set of lookups based on ip address, whois records, contact addresses, and manual co-operation of the senders ISP, which can't be automated in any satisfactory way. Besides, does an ISP the size of Xtra (for example) really want to be receiving an automated "your customer at ip x.x.x.x is infected with a virus" at their abuse@ address from some clever clogs who thinks its a good idea to autoreport viruses, for EVERY virus every one of their customers sends ? Would they ever be able to process legitimate human sent abuse@ notifications with that amount of automated junk being fired at them ? I doubt it. Would it solve anything ? Not really. Would sure increase the amount of useless mail flowing around the place though.... If virus scanning was prone to the same level of false positives as spam filtering, then dropping virus infected messages might be cause for concern, but with extremely low FP's it isn't. Anyway, you can notify the attempted recipient of the virus and let them decide if it might be a real email or not. (Which is what our system does by default, but people can turn off the notifications, and a lot do) Trying to notify the "sender" using any automated system is out of the question though. Regards, Simon
Hi all, thanks for the responses thus far. Note I'm not talking about notifications based on the from address, because as we all know, thats forged 99% of the time... I am talking about tracking of IP addresses and date/time info. ISPs should at least be able to automatically notify their _own_ customers, right? ;) On Sat, 22 Jan 2005, Simon Byrnand wrote:
Personally, I'm sick of these MailMarshal type systems, I've lost count of how many times I've received a "notification" of an "illegal file attachment" that I've supposedly sent to somebody I've never heard of before, during an outbreak of a new virus.
C'mon people running these kinds of systems, clean up your act...
It is surprising to hear of an ISP doing this though, especially on an abuse@ contact address...at least people in the SOHO area running their own mail servers who are usually guilty of this have the "excuse" of ignorance, but an ISP doesn't..
Agree 100%. Mind you those who run Mailmarshall and have cloo(tm) usualy turn off the notifications.
The argument can be made that headers are all thats required, and that the actual payload isnt needed - but what if theres occaision where you want said payload? (To provide actual evidence of the infection, to identify what variant of the virus is infected, to help build filters ...?)
Personally I can't think of a legitimate reason to purposely send an email with a working virus body to an abuse@ contact address, you're just asking for the message to either be blocked, or potentially infect the recipient, if they don't have their act together.
A copy of the message minus virus should be sufficient.
Agreed, but still curious that an ISP would rather turn away the traffic based on the file extension than receive it in order to process it. I use pine for mail reading most of the time (I pop the box once every week or so) so as such when I hit 'forward' it bundles the whole lot, attatchment included. I don't often find that it gets bounced due to viral payload, as most of the overseas providers I deal with exclude their security mailboxes. Was interested on an NZ perspective.
Do ISPs out there regularly exclude their security team or at least build in means for one-off exceptions on an as-required basis? Do ISPs that drop viral (or suspected viral) traffic do anything to report said infection, or do they just drop the virus and pretend it never happened? (Doesn't actually fix the problem, does it...)
The truth is that there are so many viruses going around out there, that upon detecting a confirmed virus body in an email (and a virus scanner has pretty close to zero false positives, unlike a spam filter) there is really no choice but to silently drop an infected message. (Perhaps logging an entry to a log file)
Who are you going to report it to ? Return addresses are bogus with modern viruses, so virus scanners that reply automatically are just inflicting annoyance on innocent third parties, the only way to track down the sender is based on a complicated set of lookups based on ip address, whois records, contact addresses, and manual co-operation of the senders ISP, which can't be automated in any satisfactory way.
As above, i'm convinced this could be effectively logged for your own customers at least - of course legwork would be required in the implimentation. If we assume a single customer sends out one message per minute of a viral nature, theres a fair chance that over the course of say, 30 minutes, one of those messages is going to have the same to: destination as their ISP uses? (thus the message will actually hit your MTA, and you can then automate something to resolve ip/time to a user account...?)
Besides, does an ISP the size of Xtra (for example) really want to be receiving an automated "your customer at ip x.x.x.x is infected with a virus" at their abuse@ address from some clever clogs who thinks its a good idea to autoreport viruses, for EVERY virus every one of their customers sends ?
I can't speak for Xtra, but I can say that if it were me, i'd rather get multiple reports than none at all - in terms of customer service it would otherwise seem to third parties that Xtra don't care about their virus infectees (and thus affecting their PR state). Its not hard for the security staff to act on the first report, then do a search within their mailbox for all other reports pertaining to that IP and flag them all as completed.... accepted theres a small risk in sending a different clients infection data away in the case of dynamic IP customers but a certain amount of intuition would come into it there.
Would they ever be able to process legitimate human sent abuse@ notifications with that amount of automated junk being fired at them ? I doubt it.
I'm convinced ISPs should be putting sufficient manpower into dealing with legitimate abuse reports (including virus infections) "For the good of the Internet". More automated systems (such as the above I described) would make it relatively easy. Then theres always the way a few american providers have gone - dropping port 25 to hosts other than their mail relays, tied to decent AV filtering.
If virus scanning was prone to the same level of false positives as spam filtering, then dropping virus infected messages might be cause for concern, but with extremely low FP's it isn't.
except its not, right? You're using definitions provided by an AV Vendor that specifically match a pattern to a known piece of Virus Code. Not anywhere near as many false positives.
Anyway, you can notify the attempted recipient of the virus and let them decide if it might be a real email or not. (Which is what our system does by default, but people can turn off the notifications, and a lot do)
This I don't agree with necessarily, and would probably turn it off. Do I care that $FORGED_RECIPIENT is trying to email me? Not really... (Hey, Bill Gates, havn't heard from you in a while...) Cheers :) Mark.
Mark Foster
Then theres always the way a few american providers have gone - dropping port 25 to hosts other than their mail relays, tied to decent AV filtering.
This saves a nearly unbelievable amount of pain. Most email-borne viruses seem to go direct to port 25 at other people's MXs, so don't hurt anyone when 25/tcp is blocked. The rest try to go via the actual relays and get dropped due to AV scanning.
Simon Byrnand wrote:
If virus scanning was prone to the same level of false positives as spam filtering, then dropping virus infected messages might be cause for concern, but with extremely low FP's it isn't.
except its not, right? You're using definitions provided by an AV Vendor that specifically match a pattern to a known piece of Virus Code. Not anywhere near as many false positives.
I've seen one vendor's AV software fire on example code, laid out in plain text emails, e.g. on ntbugtraq. I believe Russ Cooper has ranted about this in the past. cheers, Jamie -- James Riden / j.riden(a)massey.ac.nz / Systems Security Engineer Information Technology Services, Massey University, NZ. GPG public key available at: http://www.massey.ac.nz/~jriden/
On Fri, 2005-01-21 at 21:37 +1300, Mark Foster wrote:
Obviously virus traffic can fluctuate up and down and become an annoyingly high percentage of an ISPs total mail load. Thus AV filtering which drops these messages is beneficial and can be provided as a benefit to customers, etc...
So what happens to role accounts like, heaven forbid, abuse@ ?
At the UoA we virus scan *all* mail, including internal email for viruses, no exceptions, all mail is treated the same.
And for that matter, if the messages are dropped, is there any logged trace of the fact the message was sent in the first place?
The reason I ask is that i've seen at least one ISP to whom i've reported viral infections to recently actually reject the report, because of the 'illegal file attatchment' (where the criteria used was the file extension... not even viral code within the attatchment)... So I had to manually copy/paste headers only to get my point across.
We do not rely on Mime Types or file extensions. We examine actual file contents to determine type. If someone were stupid enough to send a live virus (or any executable file) to abuse/security(a)auckland.ac.nz then, if the attachment matched virus signatures the mail would be silently deleted. OTOH if the file was executable but not obviously malicious then it would be quarantined and a notice sent to abuse. This is *exactly* the same as for any other address. Under no circumstances should anyone send email containing live malware anywhere except to the notification address of AV vendors and these should be sent in a password protected zip file (usual password used is "infected") along with the password in the body of the email. As Simon points out there are real problems with many brain dead AV scanners which A. bounce/drop messages based on inadequate evidence and B. send erroneous bounce messages to whatever address happens to be in the From: field Sigh.... Cheers, Russell
The argument can be made that headers are all thats required, and that the actual payload isnt needed - but what if theres occaision where you want said payload? (To provide actual evidence of the infection, to identify what variant of the virus is infected, to help build filters ...?)
Do ISPs out there regularly exclude their security team or at least build in means for one-off exceptions on an as-required basis? Do ISPs that drop viral (or suspected viral) traffic do anything to report said infection, or do they just drop the virus and pretend it never happened? (Doesn't actually fix the problem, does it...)
Appreciate your thoughts.
Mark.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Russell Fulton
On Fri, 2005-01-21 at 21:37 +1300, Mark Foster wrote:
The reason I ask is that i've seen at least one ISP to whom i've reported viral infections to recently actually reject the report, because of the 'illegal file attatchment' (where the criteria used was the file extension... not even viral code within the attatchment)... So I had to manually copy/paste headers only to get my point across.
We do not rely on Mime Types or file extensions. We examine actual file contents to determine type.
If someone were stupid enough to send a live virus (or any executable file) to abuse/security(a)auckland.ac.nz then, if the attachment matched virus signatures the mail would be silently deleted.
Same here - abuse@ is AV scanned but doesn't have any form of spam filtering. If anyone wants to send actual malware samples, it's easy enough to encrypt it using PGP or WinZip. Incidentally, I think the last time I submitted a sample to an AV vendor, they wanted it in a password protected zip file. Wrt. Mail Marshal, it's perfectly possible to configure it to silently drop 'bad' email rather than bouncing it to the purported sender. cheers, Jamie -- James Riden / j.riden(a)massey.ac.nz / Systems Security Engineer Information Technology Services, Massey University, NZ. GPG public key available at: http://www.massey.ac.nz/~jriden/
participants (4)
-
James Riden -
Mark Foster -
Russell Fulton -
Simon Byrnand