A minimal outside web service reached via the domain name you want to use can redirect all requests to a slightly different domain name, along with a port number which won't be 80. That won't prevent them from deciding to block every incoming TCP connection not recognized by various protocol proxies (e.g. FTP), so this isn't a perfect solution. As the cat and mouse game continues, you may end up having to keep up a tunnel to an outside server, and run that tunnel through faked HTTP as well.
But will your transparent proxy connect to the exact same IP address that your client tries to connect to, regardless of what the "Host" header in the HTTP request identifies for the virtual host selection within that server?
Now the question is, when someone connects to an IP address, does the proxy, which intercepted the request, connection to that same IP address? Or does it do a DNS lookup and try to connect to what it thinks is the IP address? And if it does the latter, is it smart enough to fall back to the clients original destination IP address if it doesn't get one via DNS?
The classic proxy server, which is connected to directly by the browser client, does not know what IP address the client wanted, because it didn't try to connect to one. But in the case of transparent proxy, there is now the issue of the IP address that the client was connecting to. Have you verified what your proxy is doing?
If the user configured his browser to use a specific proxy, then I would agree with you regarding RFC2068. The client in essence is delegating DNS responsibility to the proxy server. However, what is happening here is called transparent proxy. There is no DNS delegation taking place. And RFC2068 requires that semantic transparency be preserved (although it does not seem to differentiate types of proxies). It says:
semantically transparent
A cache behaves in a "semantically transparent" manner, with
respect to a particular response, when its use affects neither the
requesting client nor the origin server, except to improve
performance. When a cache is semantically transparent, the client
receives exactly the same response (except for hop-by-hop headers)
that it would have received had its request been handled directly
by the origin server.
In this case the origin server would have delivered a web page (I actually tried it and it works fine for me), and so the proxy has the responsibility to deliver the same thing. In that, it seems, it failed.
This is a method of getting things solved that really does work... but generally only with smaller businesses. Before I went to work for an ISP, I had an account with another ISP that was doing an excellent job. About a month into the job I called up the other ISP to cancel my service (as it was a dedicated full time nail-up service, and thus a bit more costly that plain old dial-up). The lady that answered took my request and proceeded to ask why I was dissatisfied with the service. I then said "Oh, no, I was perfectly happy with the service". She then asked "Oh, you're moving out of town?". To that I finally explained to her that I had taken a job with an ISP in town, and had free service through it. She told me "well, I guess it won't do any good then for the owner to give you a call and see if he can get you back".
You're not likely to get that kind of response from a big national ISP. One customer is just too small a percentage for a manager to call to find out why you are unhappy. Mostly, whatever changes they might need to do to make you happy would be too costly for such a big company, anyway. The trouble with small ISPs is that there is such a great variation of competency. But when you get a good one, you have a gem. With the big ones, it's generally a fairly uniform level of pathetic service.
If you connect to a specific IP address, a transparent proxy should connect to that very same IP address. If it connects to any other for any reason, it is apply a sort of "routing" logic. Apparently what happens is because the client includes an HTTP version 1.1 "Host" header, the proxy prefers to do a DNS lookup on the hostname given, and (if it finds it) connect there instead of the client's original destination IP address.
This is broken. If the proxy has a different idea of what domain names mean, it gets the wrong web site, or perhaps fails to get one at all. A correct transparent proxy implementation should always connect to the very same IP address the client tried to connect to without regard to the "Host" header (which must also be passed along). A DNS lookup can still be done to optimize the cache. If the destination IP address is in the list of A records from the DNS query, then it can simply be matched to the cache by name alone. However, if the IP address does not match any that DNS gets, then those pages can still be cached, but they must be cached under the tuple of both the destination IP address and the "Host" header name together (as this content can be different than any other for the same host name or the same IP address).
Maybe someone can provide a list of which transparent proxy cache programs do it wrong, and which do it right (as I have not examined these programs). I don't know if peakpeak.com will change out the software once they find something that does it right (or even make a configuration change if it turns out that's all that is needed). Ironically, if you find an outside proxy server which can do it right for you, you could connect directly to that service via a different TCP port and end up defeating the efforts of your ISP to save upstream bandwidth by caching.
I did system level encryption in 1978 on the mainframe VM/CMS system. Under the CMS component, which ran in a virtual machine, all I/O was done through an interface known as SVC 202. This interface was used for modular execution of both external (a file) and internal functions. I wrote a program in assembly language which first ran in what was known as the "transient area". This program then allocated memory on a permanent basis, and copied part of itself there. That part was written in relocateable assembly code (was not hard to do in S/370 assembler). It then substituted the SVC interrupt vector with its own, and intercepted all SVC instruction traps. The intercept handler was now in control and the program did a graceful exit, but without deallocating the memory. This was similar to the DOS TSR (Terminate and Stay Resident) feature. The intercept handler checked for SVC traps being code 202. If not, it passed them on to the original SVC handler in CMS. If it was 202, then it checked for the request name for reading and writing. If that matched, it then checked to see if it was a file to be encrypted (writing) or decrypted (reading). CMS had disk letter/number combinations added to each file, and I allowed the program to be told to use either a letter (specific disk) or number (file mode) to be matched to indicate that the file was encrypted. It them modified the buffer appropriately before (writing) or after (reading) the system function completed. The net effect was the ability to have selected files, or a whole disk, encrypted. All native CMS programs, and some OS/VS/MVS emulated programs, would successfully do I/O through this encryption system. I was able to edit a Fortran program, save it, and compile it with the Fortran G compiler, and subsequently run it. I placed a call to my encryption facility in a script called "PROFILE EXEC A1" which made it run every time I logged in. It prompted me for the key, which was a string that was hashed to construct the encryption vector for the algorithm I used (which is probably terribly insecure today).
I was a student at Ohio University at the time. A group of us were "hackers" (and at times did a little cracking, too). All the disk space was partition-like slices on big (in the physical sense, about the size of a small washing machine) hard drives shared with a lot of other people. The computer center administrators could easily spy on any user's disk space. So this was used as a means to keep nosey people out. About 3 months after I started regularly using this, I was summoned to the office of the Director of Academic Affairs at the computer center. I was told by Dr. Craig Farrar that he was aware that I was encrypting my files, and that this was against computer center and university policy. He gave me a copy of the policy. He was at least an honest man, and also told me it was a brand new policy adopted specifically because I was encrypting my files. He then told me I had 2 days to unencrypt all files before the disk space would be entirely erased. I simply backed up most of them to a private tape, removed it, and unencrypted a few remaining files and deleted the rest. I never used the program again.
When the PC came out with DOS, and I learned of TSR, I thought about that program, and thought I'd like to do the same thing again. I didn't at that time because I didn't make the committment to learn x86 assembly, and didn't have a suitable C compiler at the time. So a DOS version, unfortunately, never actually happened. However, I did see among some shareware on a BBS, around 1989, a description of a program that did exactly that. Unfortunately for that program, at that time I was doing the Amiga thing. Hopefully someone can track down that program.
When I moved to Texas in 1993, I left all my old mainframe tapes (about 120 of them by then) behind. I had gotten hooked on Linux and swore to never use a mainframe again, so I had them discarded. Now I wish I had them back, because I could now run them on Linux using emulators... after I figured out how to get stuff off those old tapes.
Wholesale blocking can be made to work if done right. Using a blacklist for *@yahoo.com and a whitelist for sistersname@yahoo.com has the right effect. It deletes anyone claiming to be from Yahoo other than those claiming to be his sister. What's the chance of some spammer using his sister's Yahoo address as the FROM address?
It is capitalized for emphasis, not for being an acronym (which it isn't). If there was a way to do bold text in plain ascii, I would have used that. I prefer not to send HTML mail.
It is not everyone's goal to "punish" spammers. My goal is principly to keep it away from me. I don't care if the spammers end up sending it to someone else. There may in theory be someone else who wants spam. Who am I to deprive them. I just don't want it sent to me.
Eventually, as spammers are crowded into fewer open relays, those that do remain open are not only unable to get to more and more places on the net, their servers are overloaded because they are the few that spammers can use. And they are dealing with more and more bouncing mail. The pressure rises, and maybe they, too, will close the relaying.
The DNSBL maintainers and users do get less spam. That's the goal. Reporting it to the spammer's ISP is NOT the goal; it's just another machanism to use to accomplish the real goal of getting less spam.
That's very unlikely to happen in normal circumstances. Perhaps it would have been prudent for ORBZ to suspend testing for a few days after 9/11, as that was an abnormal time.
Here is the letter I sent, sans the spam itself (typical relayed spam). As you can see, I didn't focus on the spam, and I didn't subject them to my usual "block first, ask questions later" approach (else how would I have gotten his response).
The following is a complaint regarding SPAM from the Spencer
Public Schools.
Spam is bad enough for some company on the internet sends it
out to you. But it can be stopped easily by recording the
location it comes from in a list of places to reject mail from.
Thousands of Internet Service Providers and other companies
are now doing this.
Now spam is coming from the Spencer Public Schools. I don't
think this is what the tax dollars of your community are for.
Yet it is paying for helping some spammer on the internet to
send his junk mail to millions of people. It not only costs
you money, but it also costs other people money.
I have been seeing this kind of thing happen in many many
places throughout the Internet. Mail servers are set up on
the Internet, and they are either set up incorrectly, or they
are set up with bad software. One or the other of these did
happen at Spencer Public Schools. That's how the spam came
through.
When a mail server is set up, if the person who sets it up is
not specifically thinking about making sure others cannot relay
their spam through it, they might as well accept the fact that
it is going to happen. The same thing applies to security.
Can you be sure that your servers (all of them) are really so
secure if the person who sets them up is so careless as to let
spam come through a mail server? Do you know that when they
set up the other servers they thought carefully about all the
security issues when they did it to make sure no one can access
things like confidential records? Have you audited the security
of the Spencer Public Schools computers?
So you're running Windows 2000. That doesn't make it secure.
Obviously it doesn't if a simple thing like using your computer
to send spam throughout the world for some con artist can be
done. Setting up ANY computer requires that the person who
sets it up realizes that it is NOT secure until they do all the
steps necessary to make it secure.
You are sure to get many complaints due to this spam. The first
thing that will happen is someone will quickly go make changes
to the mail server to prevent this one security leak. That may
seem fine at first. But what about all the other security holes?
Will they also be plugged up? Do you even know what they are?
And what about your computer operating procedures and policies?
Did they cover this kind of situation? They obviously failed
to prevent it. But were they even written to prevent it or did
they just not even address the issue at all?
You clearly need to get some competent computer help involved
in making sure your computers are secured. Perhaps you can get
this help from WiscNet. But you definitely need to get that
help, and get it soon. And don't ask one of the students who
might seem to be very bright with computers. They might be
good at cracking into computers or writing nifty programs, but
what you need is a professional analysis of your procedures and
security policy. And you need to get it done before the fall
school term begins. If not, you are almost certain to become
a victim again, and again; if not from spammers, then maybe
even from one of your own students.
As for this spam incident, normally my very first action after
sending a formal complaint is to totally cut off the offenders
network from our network. If I did that here, you'd have to
make a request to me to restore that access by some means other
than through your own mail server. It's usually inconvenient,
but it gets a serious message across to Internet scofflaws.
In this case, I'm not going to do this. I won't be blocking
your network. If the problem repeats, I'll change my mind.
I have over 21,000 networks blocked right now (over 3,000 of
them are in China). And those are the ones where the people
running them just don't care.
Normal spam complains include a copy of the spam that caused the
complaint to be made. So I'm including that below. Each line
of the original is intended with a "|" character at the left
side of each line. Here it is:
Interesting that the latest banner I get is....
220 battlecreek.org GroupWise Internet Agent 5.5.3.1 Ready (C)1993, 1999 Novell, Inc.
I had a run in that went a slightly different way with a member of the school board for the Spencer Wisconsin school district. I got spam from them. I reported the problem to them, noting also that this was an inappropriate way for tax dollars to be spent. I got this response:
Dear Phil,
We have talented people working hard to keep our system clean. Somehow
it seems that criminals and crackers are better funded than public school
systems. Figure that out. Meanwhile, if you would spend less time
criticizing honest hard working people and more time helping put a stop to
this sort of thing, we'd all be better off.
You sir, are a Prick.
What I'd like to know is why honest hard working people are incompetent and leave a mail server open to spamming abuses. Of course Mr. Darga doesn't really seem to care.
Then what needs to be done is to recognize the versions of Lotus that are defect, and just don't send any tests to those. Do go ahead and list them as a "spam risk due to incompetent administration" (e.g. because they have not yet been upgraded).
The press release referred to Mr. Gulliver's attorney. Apparently he has an attorney. That attorney should be paid for his services. Mr. Gulliver should not be the one to pay that.
There's no reason to believe that a server that has NOT sent any spam is MORE likely to have defects in design, coding, or configuration, when compared to a server that has sent spam. In fact, if a server HAS sent spam, THAT is the server that should not be tested. The server that has sent spam is more likely to be afflicted by at least one of bad design, bad coding, or bad configuration.
There is no reason for any properly designed and managed server to crash and burn as a result of any piece of mail delivery. That some do is not a valid reason to devalue an important tool in the effort against spam. It could be of value if it is possible to identify from the SMTP banner if some server is a defective one, such as an older version of Lotus Notes. If that can be determined, then ORBZ should simply add the server to the list and not send anything there at all (except maybe a notice of why they are being listed). I suggest they be added because I do not want them to be sending my servers any mail because that mail has a risk of being spam, due to an obvious situation of inadequate or incompetent administration of that server.
From the press release by Michelle Reen, Assistant to the City Manager, Battle Creek, Michigan:
"But, if I can draw the analogy that just because everyone should wear a computerized bulletproof vest doesn't mean that shooting people to find out who isn't wearing one is the best answer. If Mr. Gulliver chooses to do this, he perhaps shouldn't be surprised that he will occasionally be confused with the type of individual he is fighting against."
This analogy is flawed. Here's why:
Shooting people is something where, if a vest is not worn, can be expected to cause serious injury or death. Even if a vest is worn, the outcome can be injury, and death has been known to happen.
A more accurate analogy would be tapping someone on the shoulder to see if they are alive. But you don't expect that one in tens of thousands happens to have a very sore shoulder, and this tapping causes great pain.
My analogy is more correct because the kinds of tests ORBZ does is not one where a reasonable person doing this kind of activity (reasonable in this case meaning someone who understands the SMTP protocol, and related standards like RFC822, TCP, etc) would expect to cause serious problems. At most, this should trigger an alarm in more secure servers, which can then be filtered for this known testing source. ORBZ is not including codes intended to damage or destroy computer systems in these tests just to see if they would be destroyed (as Ms. Reen's analogy would suggest).
It seems to me that the city of Battle Creek perhaps acted a bit hasty in the way they reacted. I'm not saying that they shouldn't have the police involved in the investigation, and I'm not saying they shouldn't pursue acquiring information to further that investigation. However, such an investigation should be tempered by the understanding that defective software, especially that which has not been properly maintained, or properly configured, can, and very frequently does, fail on account of that defect simply as the result of a properly formed standards defined computer or network activity. We all know PC systems (especaily, but not exclusively, Windows) can fail at times even though only normal activity is taking place. Just because an activity can come from outside, from the internet, does not mean that it can only be malicious.
I recommend the City of Battle Creek Michigan, and any other government or business in like circumstances, operate under the following suggestions:
Whenever something causes a system to fail, include in any investigation of the cause an analysis of why it failed, including the protocols and software codes involved. Don't just hand it over to the police after the first jump to conclusion. Gain an understanding of exactly why the system failed, especially if the failure repeats.
Whenever a problem is tracked to some source, don't jump into threatening mode on initial contact, unless you have a reason to believe the communication would fail any other way. Serious intent to investigate and followup on real crimes does not mean aggression in legal procedures gains anything. Were this a real internet cracker, there wouldn't have been any useful information from this first step, anyway.
Place stronger protection between office LANs and city WANs and the internet itself. But do more than just a simple firewall that allows raw TCP streams to pass. Use a strong secure server with proxying where possible. Systems like Lotus Notes are Microsoft Exchange are too likely to be vulnerable, and too mission critical for staff operations, to be expected to also serve as the shield facing the internet. Run an OpenBSD server with something like Postfix to forward mail, and Squid to cache web accesses both in and out.
Institute new procedures that outline standard timeframes for keeping computer systems up to date, especially with the latest security alerts. All security patches should be installed within 7 days of availability or a report made to the top official regarding why that patch cannot be applied, describing alternative steps to deal with the risk. All other systems should be upgraded to the latest version within 90 days, if free. If not free, an analysis of the benefits (if any) of purchasing such an upgrade should be provided to the person in charge of making system software purchasing decisions, within 90 days.
Also, get the reverse DNS fixed on your mail server.
It would. It could be substantial, too. And it may still be possible to find out who, though not find out the settlement terms. Since the case was filed with a small claims court, the records should exist, and should be public, unless a judge orders them sealed (and I don't know it would have been carried that far).
Re:Lotus Notes now a Target?
on
ORBZ Shuts Down
·
· Score: 2
Thanks for the info! I'm about to block them. But in the course of digging for info, I also found that they cannot send me mail anyway due to the fact they failed to put in their reverse DNS. That solidifies my knowledge that their network/server is being operated by someone not very competent.
Slashdot Mirror
A minimal outside web service reached via the domain name you want to use can redirect all requests to a slightly different domain name, along with a port number which won't be 80. That won't prevent them from deciding to block every incoming TCP connection not recognized by various protocol proxies (e.g. FTP), so this isn't a perfect solution. As the cat and mouse game continues, you may end up having to keep up a tunnel to an outside server, and run that tunnel through faked HTTP as well.
But will your transparent proxy connect to the exact same IP address that your client tries to connect to, regardless of what the "Host" header in the HTTP request identifies for the virtual host selection within that server?
Now the question is, when someone connects to an IP address, does the proxy, which intercepted the request, connection to that same IP address? Or does it do a DNS lookup and try to connect to what it thinks is the IP address? And if it does the latter, is it smart enough to fall back to the clients original destination IP address if it doesn't get one via DNS?
The classic proxy server, which is connected to directly by the browser client, does not know what IP address the client wanted, because it didn't try to connect to one. But in the case of transparent proxy, there is now the issue of the IP address that the client was connecting to. Have you verified what your proxy is doing?
If the user configured his browser to use a specific proxy, then I would agree with you regarding RFC2068. The client in essence is delegating DNS responsibility to the proxy server. However, what is happening here is called transparent proxy. There is no DNS delegation taking place. And RFC2068 requires that semantic transparency be preserved (although it does not seem to differentiate types of proxies). It says:
semantically transparentA cache behaves in a "semantically transparent" manner, with
respect to a particular response, when its use affects neither the
requesting client nor the origin server, except to improve
performance. When a cache is semantically transparent, the client
receives exactly the same response (except for hop-by-hop headers)
that it would have received had its request been handled directly
by the origin server.
In this case the origin server would have delivered a web page (I actually tried it and it works fine for me), and so the proxy has the responsibility to deliver the same thing. In that, it seems, it failed.
This is a method of getting things solved that really does work ... but generally only with smaller businesses. Before I went to work for an ISP, I had an account with another ISP that was doing an excellent job. About a month into the job I called up the other ISP to cancel my service (as it was a dedicated full time nail-up service, and thus a bit more costly that plain old dial-up). The lady that answered took my request and proceeded to ask why I was dissatisfied with the service. I then said "Oh, no, I was perfectly happy with the service". She then asked "Oh, you're moving out of town?". To that I finally explained to her that I had taken a job with an ISP in town, and had free service through it. She told me "well, I guess it won't do any good then for the owner to give you a call and see if he can get you back".
You're not likely to get that kind of response from a big national ISP. One customer is just too small a percentage for a manager to call to find out why you are unhappy. Mostly, whatever changes they might need to do to make you happy would be too costly for such a big company, anyway. The trouble with small ISPs is that there is such a great variation of competency. But when you get a good one, you have a gem. With the big ones, it's generally a fairly uniform level of pathetic service.
If you connect to a specific IP address, a transparent proxy should connect to that very same IP address. If it connects to any other for any reason, it is apply a sort of "routing" logic. Apparently what happens is because the client includes an HTTP version 1.1 "Host" header, the proxy prefers to do a DNS lookup on the hostname given, and (if it finds it) connect there instead of the client's original destination IP address.
This is broken. If the proxy has a different idea of what domain names mean, it gets the wrong web site, or perhaps fails to get one at all. A correct transparent proxy implementation should always connect to the very same IP address the client tried to connect to without regard to the "Host" header (which must also be passed along). A DNS lookup can still be done to optimize the cache. If the destination IP address is in the list of A records from the DNS query, then it can simply be matched to the cache by name alone. However, if the IP address does not match any that DNS gets, then those pages can still be cached, but they must be cached under the tuple of both the destination IP address and the "Host" header name together (as this content can be different than any other for the same host name or the same IP address).
Maybe someone can provide a list of which transparent proxy cache programs do it wrong, and which do it right (as I have not examined these programs). I don't know if peakpeak.com will change out the software once they find something that does it right (or even make a configuration change if it turns out that's all that is needed). Ironically, if you find an outside proxy server which can do it right for you, you could connect directly to that service via a different TCP port and end up defeating the efforts of your ISP to save upstream bandwidth by caching.I'll just lie and say "I meant, a traditional old mainframe OS". Really, with Linux on the mainframe, I might have to eat those words.
I did system level encryption in 1978 on the mainframe VM/CMS system. Under the CMS component, which ran in a virtual machine, all I/O was done through an interface known as SVC 202 . This interface was used for modular execution of both external (a file) and internal functions. I wrote a program in assembly language which first ran in what was known as the "transient area". This program then allocated memory on a permanent basis, and copied part of itself there. That part was written in relocateable assembly code (was not hard to do in S/370 assembler). It then substituted the SVC interrupt vector with its own, and intercepted all SVC instruction traps. The intercept handler was now in control and the program did a graceful exit, but without deallocating the memory. This was similar to the DOS TSR (Terminate and Stay Resident) feature. The intercept handler checked for SVC traps being code 202. If not, it passed them on to the original SVC handler in CMS. If it was 202, then it checked for the request name for reading and writing. If that matched, it then checked to see if it was a file to be encrypted (writing) or decrypted (reading). CMS had disk letter/number combinations added to each file, and I allowed the program to be told to use either a letter (specific disk) or number (file mode) to be matched to indicate that the file was encrypted. It them modified the buffer appropriately before (writing) or after (reading) the system function completed. The net effect was the ability to have selected files, or a whole disk, encrypted. All native CMS programs, and some OS/VS/MVS emulated programs, would successfully do I/O through this encryption system. I was able to edit a Fortran program, save it, and compile it with the Fortran G compiler, and subsequently run it. I placed a call to my encryption facility in a script called "PROFILE EXEC A1" which made it run every time I logged in. It prompted me for the key, which was a string that was hashed to construct the encryption vector for the algorithm I used (which is probably terribly insecure today).
I was a student at Ohio University at the time. A group of us were "hackers" (and at times did a little cracking, too). All the disk space was partition-like slices on big (in the physical sense, about the size of a small washing machine) hard drives shared with a lot of other people. The computer center administrators could easily spy on any user's disk space. So this was used as a means to keep nosey people out. About 3 months after I started regularly using this, I was summoned to the office of the Director of Academic Affairs at the computer center. I was told by Dr. Craig Farrar that he was aware that I was encrypting my files, and that this was against computer center and university policy. He gave me a copy of the policy. He was at least an honest man, and also told me it was a brand new policy adopted specifically because I was encrypting my files. He then told me I had 2 days to unencrypt all files before the disk space would be entirely erased. I simply backed up most of them to a private tape, removed it, and unencrypted a few remaining files and deleted the rest. I never used the program again.
When the PC came out with DOS, and I learned of TSR, I thought about that program, and thought I'd like to do the same thing again. I didn't at that time because I didn't make the committment to learn x86 assembly, and didn't have a suitable C compiler at the time. So a DOS version, unfortunately, never actually happened. However, I did see among some shareware on a BBS, around 1989, a description of a program that did exactly that. Unfortunately for that program, at that time I was doing the Amiga thing. Hopefully someone can track down that program.
When I moved to Texas in 1993, I left all my old mainframe tapes (about 120 of them by then) behind. I had gotten hooked on Linux and swore to never use a mainframe again, so I had them discarded. Now I wish I had them back, because I could now run them on Linux using emulators ... after I figured out how to get stuff off those old tapes.
Wholesale blocking can be made to work if done right. Using a blacklist for *@yahoo.com and a whitelist for sistersname@yahoo.com has the right effect. It deletes anyone claiming to be from Yahoo other than those claiming to be his sister. What's the chance of some spammer using his sister's Yahoo address as the FROM address?
It is capitalized for emphasis, not for being an acronym (which it isn't). If there was a way to do bold text in plain ascii, I would have used that. I prefer not to send HTML mail.
It was actually running Windows 2000 at the time. I checked through the site back then. This was 9 months ago. They apparently have changed things.
It is not everyone's goal to "punish" spammers. My goal is principly to keep it away from me. I don't care if the spammers end up sending it to someone else. There may in theory be someone else who wants spam. Who am I to deprive them. I just don't want it sent to me.
Eventually, as spammers are crowded into fewer open relays, those that do remain open are not only unable to get to more and more places on the net, their servers are overloaded because they are the few that spammers can use. And they are dealing with more and more bouncing mail. The pressure rises, and maybe they, too, will close the relaying.
The DNSBL maintainers and users do get less spam. That's the goal. Reporting it to the spammer's ISP is NOT the goal; it's just another machanism to use to accomplish the real goal of getting less spam.
I'm so .... scared!
That's very unlikely to happen in normal circumstances. Perhaps it would have been prudent for ORBZ to suspend testing for a few days after 9/11, as that was an abnormal time.
Here is the letter I sent, sans the spam itself (typical relayed spam). As you can see, I didn't focus on the spam, and I didn't subject them to my usual "block first, ask questions later" approach (else how would I have gotten his response).
The following is a complaint regarding SPAM from the Spencer
Public Schools.
Spam is bad enough for some company on the internet sends it
out to you. But it can be stopped easily by recording the
location it comes from in a list of places to reject mail from.
Thousands of Internet Service Providers and other companies
are now doing this.
Now spam is coming from the Spencer Public Schools. I don't
think this is what the tax dollars of your community are for.
Yet it is paying for helping some spammer on the internet to
send his junk mail to millions of people. It not only costs
you money, but it also costs other people money.
I have been seeing this kind of thing happen in many many
places throughout the Internet. Mail servers are set up on
the Internet, and they are either set up incorrectly, or they
are set up with bad software. One or the other of these did
happen at Spencer Public Schools. That's how the spam came
through.
When a mail server is set up, if the person who sets it up is
not specifically thinking about making sure others cannot relay
their spam through it, they might as well accept the fact that
it is going to happen. The same thing applies to security.
Can you be sure that your servers (all of them) are really so
secure if the person who sets them up is so careless as to let
spam come through a mail server? Do you know that when they
set up the other servers they thought carefully about all the
security issues when they did it to make sure no one can access
things like confidential records? Have you audited the security
of the Spencer Public Schools computers?
So you're running Windows 2000. That doesn't make it secure.
Obviously it doesn't if a simple thing like using your computer
to send spam throughout the world for some con artist can be
done. Setting up ANY computer requires that the person who
sets it up realizes that it is NOT secure until they do all the
steps necessary to make it secure.
You are sure to get many complaints due to this spam. The first
thing that will happen is someone will quickly go make changes
to the mail server to prevent this one security leak. That may
seem fine at first. But what about all the other security holes?
Will they also be plugged up? Do you even know what they are?
And what about your computer operating procedures and policies?
Did they cover this kind of situation? They obviously failed
to prevent it. But were they even written to prevent it or did
they just not even address the issue at all?
You clearly need to get some competent computer help involved
in making sure your computers are secured. Perhaps you can get
this help from WiscNet. But you definitely need to get that
help, and get it soon. And don't ask one of the students who
might seem to be very bright with computers. They might be
good at cracking into computers or writing nifty programs, but
what you need is a professional analysis of your procedures and
security policy. And you need to get it done before the fall
school term begins. If not, you are almost certain to become
a victim again, and again; if not from spammers, then maybe
even from one of your own students.
As for this spam incident, normally my very first action after
sending a formal complaint is to totally cut off the offenders
network from our network. If I did that here, you'd have to
make a request to me to restore that access by some means other
than through your own mail server. It's usually inconvenient,
but it gets a serious message across to Internet scofflaws.
In this case, I'm not going to do this. I won't be blocking
your network. If the problem repeats, I'll change my mind.
I have over 21,000 networks blocked right now (over 3,000 of
them are in China). And those are the ones where the people
running them just don't care.
Normal spam complains include a copy of the spam that caused the
complaint to be made. So I'm including that below. Each line
of the original is intended with a "|" character at the left
side of each line. Here it is:
Interesting that the latest banner I get is....
220 battlecreek.org GroupWise Internet Agent 5.5.3.1 Ready (C)1993, 1999 Novell, Inc.
I had a run in that went a slightly different way with a member of the school board for the Spencer Wisconsin school district. I got spam from them. I reported the problem to them, noting also that this was an inappropriate way for tax dollars to be spent. I got this response:
Dear Phil,
We have talented people working hard to keep our system clean. Somehow
it seems that criminals and crackers are better funded than public school
systems. Figure that out. Meanwhile, if you would spend less time
criticizing honest hard working people and more time helping put a stop to
this sort of thing, we'd all be better off.
You sir, are a Prick.
Sincerely,
Jeff Darga
VP-Spencer Board of Education
What I'd like to know is why honest hard working people are incompetent and leave a mail server open to spamming abuses. Of course Mr. Darga doesn't really seem to care.
Actually, it's now running....
220 battlecreek.org GroupWise Internet Agent 5.5.3.1 Ready (C)1993, 1999 Novell, Inc.
Then what needs to be done is to recognize the versions of Lotus that are defect, and just don't send any tests to those. Do go ahead and list them as a "spam risk due to incompetent administration" (e.g. because they have not yet been upgraded).
The press release referred to Mr. Gulliver's attorney. Apparently he has an attorney. That attorney should be paid for his services. Mr. Gulliver should not be the one to pay that.
Competent IT professionals cost a lot of money ... unless you import them from India.
No. But they might get a court order to turn over all the account information. Maybe then we can find out who the real Anonymous Coward is :-)
Is that something you do with your boyfriend?
Russ, you're still wrong.
There's no reason to believe that a server that has NOT sent any spam is MORE likely to have defects in design, coding, or configuration, when compared to a server that has sent spam. In fact, if a server HAS sent spam, THAT is the server that should not be tested. The server that has sent spam is more likely to be afflicted by at least one of bad design, bad coding, or bad configuration.
There is no reason for any properly designed and managed server to crash and burn as a result of any piece of mail delivery. That some do is not a valid reason to devalue an important tool in the effort against spam. It could be of value if it is possible to identify from the SMTP banner if some server is a defective one, such as an older version of Lotus Notes. If that can be determined, then ORBZ should simply add the server to the list and not send anything there at all (except maybe a notice of why they are being listed). I suggest they be added because I do not want them to be sending my servers any mail because that mail has a risk of being spam, due to an obvious situation of inadequate or incompetent administration of that server.
From the press release by Michelle Reen, Assistant to the City Manager, Battle Creek, Michigan:
This analogy is flawed. Here's why:
Shooting people is something where, if a vest is not worn, can be expected to cause serious injury or death. Even if a vest is worn, the outcome can be injury, and death has been known to happen.
A more accurate analogy would be tapping someone on the shoulder to see if they are alive. But you don't expect that one in tens of thousands happens to have a very sore shoulder, and this tapping causes great pain.
My analogy is more correct because the kinds of tests ORBZ does is not one where a reasonable person doing this kind of activity (reasonable in this case meaning someone who understands the SMTP protocol, and related standards like RFC822, TCP, etc) would expect to cause serious problems. At most, this should trigger an alarm in more secure servers, which can then be filtered for this known testing source. ORBZ is not including codes intended to damage or destroy computer systems in these tests just to see if they would be destroyed (as Ms. Reen's analogy would suggest).
It seems to me that the city of Battle Creek perhaps acted a bit hasty in the way they reacted. I'm not saying that they shouldn't have the police involved in the investigation, and I'm not saying they shouldn't pursue acquiring information to further that investigation. However, such an investigation should be tempered by the understanding that defective software, especially that which has not been properly maintained, or properly configured, can, and very frequently does, fail on account of that defect simply as the result of a properly formed standards defined computer or network activity. We all know PC systems (especaily, but not exclusively, Windows) can fail at times even though only normal activity is taking place. Just because an activity can come from outside, from the internet, does not mean that it can only be malicious.
I recommend the City of Battle Creek Michigan, and any other government or business in like circumstances, operate under the following suggestions:
Also, get the reverse DNS fixed on your mail server.
It would. It could be substantial, too. And it may still be possible to find out who, though not find out the settlement terms. Since the case was filed with a small claims court, the records should exist, and should be public, unless a judge orders them sealed (and I don't know it would have been carried that far).
Thanks for the info! I'm about to block them. But in the course of digging for info, I also found that they cannot send me mail anyway due to the fact they failed to put in their reverse DNS. That solidifies my knowledge that their network/server is being operated by someone not very competent.
phil@pollux:/home/phil 33> dnstracer 120.158.120.216.in-addr.arpa | head
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; 120.158.120.216.in-addr.arpa, type = PTR, class = IN
;; Total query time: 288 msec
;; FROM: pollux.ipal.net to SERVER: NSB.TRIVALENT.NET. 216.120.131.35
;; WHEN: Thu Mar 21 15:56:15 2002
;; MSG SIZE sent: 46 rcvd: 46
Tracing to 120.158.120.216.in-addr.arpa via 209.102.208.30, timeout 15 seconds
209.102.208.30 (209.102.208.30)
|\___ D.ROOT-SERVERS.NET (128.8.10.90)
| |\___ JERK.ARIN.NET (192.12.94.32)
| | |\___ NSB.TRIVALENT.NET (216.120.131.35)
| | \___ NSA.TRIVALENT.NET (216.120.131.34)
| |\___ INDIGO.ARIN.NET (192.31.80.32)
| | |\___ NSB.TRIVALENT.NET (216.120.131.35) (cached)
| | \___ NSA.TRIVALENT.NET (216.120.131.34) (cached)
| |\___ HENNA.ARIN.NET (192.26.92.32)
phil@pollux:/home/phil 34> dig @NSB.TRIVALENT.NET. 120.158.120.216.in-addr.arpa. ptr
; <<>> DiG 8.3 <<>> @NSB.TRIVALENT.NET. 120.158.120.216.in-addr.arpa. ptr
; (1 server found)
phil@pollux:/home/phil 35>