reynotm
asked on
Using telnet to send e-mail to a Novell Groupwise account.
We are getting e-mail from anonymous users who are using telnet to send e-mail with administrators return address. We are using Novell 5.1 and Groupwise 6.5.
Question:
What can we do to keep this from happening?
I will add points, if I can, for a good answer...
Thanks!
reynotm
Question:
What can we do to keep this from happening?
I will add points, if I can, for a good answer...
Thanks!
reynotm
Setup a Groupwise filter rule to discard email send from <your administrators return address>.
Most likely the <your administrators return address> will not send from external to internal but internal to external.
Most likely the <your administrators return address> will not send from external to internal but internal to external.
Hm. That assumes that the mail in question, is being sent from outside of his network, in. I'm guessing that what he's got is a spammer, spoofing his administrator's address, and sending mail to the Universe At Large, pretending to be his administrator, and selling penile enlargement to everyone - male or female. (I've always wondered what kind of woman would ever go to their mate and give a penile enlargement product, as a 'gift'... Perhaps a good gag gift for a brother...?)
Good answer, though, if the assumption is correct.
Good answer, though, if the assumption is correct.
It is nearly impossible to stop spammers from impersonating as others and using email addresses not belonging to them.
I have been hit several times with thousands of bounced emails sent by spammers to Everybody seemingly from my address,
as well as by several angry demands that I stop my spam... :-<
My bitter experience shows me that sysadmins at ISPs either do not care for abuse from their networks, or the abuse teams are overloaded with complaints. The only way for you to get some cooperation from most ISPs where the emails originated, is to go legal, a court order is prefered.
How to find the ISP where email originated?
The SpamCop web site is running a crusade against spam, and provides an online tool that analyzes the submitted spam, discards all the phony information and fake headers mass mailers use, and pinpoints the culprit networks.
Free registration, and donations are welcome (I am not associated in any way).
I have been hit several times with thousands of bounced emails sent by spammers to Everybody seemingly from my address,
as well as by several angry demands that I stop my spam... :-<
My bitter experience shows me that sysadmins at ISPs either do not care for abuse from their networks, or the abuse teams are overloaded with complaints. The only way for you to get some cooperation from most ISPs where the emails originated, is to go legal, a court order is prefered.
How to find the ISP where email originated?
The SpamCop web site is running a crusade against spam, and provides an online tool that analyzes the submitted spam, discards all the phony information and fake headers mass mailers use, and pinpoints the culprit networks.
Free registration, and donations are welcome (I am not associated in any way).
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hello again,
First, thanks for all the commentary. Some more info:
I work for a school disctrict. Our administrators were getting weird e-mail, nothing like penile enlargement...yet..., but strange just the same. One of the site tech.'s started hitting hacking sites and found out about this telnet exploit. We have since tried it from outside to inside and haven't got it to work yet. Sooo that is looking good...well better at least. We can do it pretty easily from inside our firewall just using a telnet program that comes with 98 and well geez you can download telnet stuff from the internet.
Sorry for not being more responsive to these comments. i'm just swamped right now, but this is important, and again THANKS!
I don't know what kind of weight the points carry with You all but it's what I have to give...
First, thanks for all the commentary. Some more info:
I work for a school disctrict. Our administrators were getting weird e-mail, nothing like penile enlargement...yet..., but strange just the same. One of the site tech.'s started hitting hacking sites and found out about this telnet exploit. We have since tried it from outside to inside and haven't got it to work yet. Sooo that is looking good...well better at least. We can do it pretty easily from inside our firewall just using a telnet program that comes with 98 and well geez you can download telnet stuff from the internet.
Sorry for not being more responsive to these comments. i'm just swamped right now, but this is important, and again THANKS!
I don't know what kind of weight the points carry with You all but it's what I have to give...
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Sorry, In the above message instaed of RETURN - PATH look at
RECEIVED :
Which have everything you need in front
RECEIVED :
Which have everything you need in front
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
grrr.
what should all these huge (manly useless) descriptions help to the question?
reynotm, *again* please explain why you're shure that it is telnet.
If it is from inside your network, it's a 2 minute work for an admin to tell you which computer was the source.
If it was from outside your network, it's 2 minutes to, but you cannot locate it easyly.
If it's from outside, tell your admin to close your open-relay.
That's it. Dot.
KISS - keep it stupid simple
what should all these huge (manly useless) descriptions help to the question?
reynotm, *again* please explain why you're shure that it is telnet.
If it is from inside your network, it's a 2 minute work for an admin to tell you which computer was the source.
If it was from outside your network, it's 2 minutes to, but you cannot locate it easyly.
If it's from outside, tell your admin to close your open-relay.
That's it. Dot.
KISS - keep it stupid simple
ASKER
Thanks ahoffmann...we have already shut off open-relay and we're still able to do it...
ahoffman...to answer the question you posed...because we can do it using a free telnet .exe
Thanks MrYowler...Great analysis and information...I'll be doing what I can to hit the Cyber Army site, often.
Thanks Somewhat_different...we'll
Again...the points are what I have to offer and this was ALL great info! We are SERIOUSLY understaffed so I REALLY appreciate this resource. I'll try this plitting the points thing and see how much I can jack them up.
ahoffman...to answer the question you posed...because we can do it using a free telnet .exe
Thanks MrYowler...Great analysis and information...I'll be doing what I can to hit the Cyber Army site, often.
Thanks Somewhat_different...we'll
Again...the points are what I have to offer and this was ALL great info! We are SERIOUSLY understaffed so I REALLY appreciate this resource. I'll try this plitting the points thing and see how much I can jack them up.
> .. because we can do it using a free telnet .exe
and what is the problem with it?
using telnet.exe is totally legal, nozthing else is done by any MUA.
> .. we're still able to do it...
What can you do? using telnet?
telnet is legal. Dot.
Just treat it as poor-mans-MUA.
Your server never knows which client connects to its port, this is not important.
What is your problem? (telnet.exe from anywhere is not a problem).
and what is the problem with it?
using telnet.exe is totally legal, nozthing else is done by any MUA.
> .. we're still able to do it...
What can you do? using telnet?
telnet is legal. Dot.
Just treat it as poor-mans-MUA.
Your server never knows which client connects to its port, this is not important.
What is your problem? (telnet.exe from anywhere is not a problem).
ASKER
Hi again ahoffman: The problem is this:
If a user, say a student, decides that they don't like a certain teacher, what is to stop them from sending an e-mail, using telnet, to the superintendent that infers a propensity towards penile enlargement. The return address is being seen, by the superintendent, as the teacher's in question return address. This hasn't happened...yet. I'm asking for advice on how to prevent this. I think this is what is meant by being proactive?
Thanks for you point of view. Anyone else?
reynotm
If a user, say a student, decides that they don't like a certain teacher, what is to stop them from sending an e-mail, using telnet, to the superintendent that infers a propensity towards penile enlargement. The return address is being seen, by the superintendent, as the teacher's in question return address. This hasn't happened...yet. I'm asking for advice on how to prevent this. I think this is what is meant by being proactive?
Thanks for you point of view. Anyone else?
reynotm
Why would students need to be permitted to send email from school computers? Simply filter them from being permitted to make connections to anything, on port 25, as close to the workstations as possible. Instructors can either use different workstations, for email, or use a webmail interface, such as squirrelmail, to send email within the district email system (this has the added effect of getting them to all use a single interface to email, reducing your technical support workload). If an instructor leaves their workstation logged into whatever authentication scheme is used to permit them to send email, and restrict the students from doing so, then the instructor deserves to get egg on his face.
The kids will still be able to use the web, to send email through Hotmail, for example, and it will still be possible to spoof a teacher's address, from outside of the district network - but such spoofing attempts are easily identified as fraudulent, based upon their Received-by: headers, which will show that the message came from outside of the network. You can establish filters, to prevent such email from being accepted by your Internet gateway mail servers, but it sounds like that might be a stretch on your resources. If teachers feel the need to send email to other members of the district, from outside of the district's facilities (from home, perhaps), then perhaps they should be required to VPN into the district network, in order to do so.
My suspicion is that by filtering port 25 at the student-accessible workstations, you'll stop most of the network wiseacres. The more capable rug-munchkins will try this from the open network, but they will likely be rare, and more easily dealt with through training the staff to be vigilant for fraudulent email messages, then by establishing complex, difficult to implement, or invasive network policies. That's a judgement call, however, and yours to make - not mine... :)
Besides, we all knew that our teachers were eunichs, and the Principal was the biggest weiner of them all, when I was in school... :-P
Another, perhaps simpler method (which could be used in conjuction with the methods already described), might be for the students to simply not be told the teacher's district network email addresses, and to make them somewhat more obscure than first initial+last name or firstname.lastname. Perhaps you have employee numbers, or something to that effect?
The kids will still be able to use the web, to send email through Hotmail, for example, and it will still be possible to spoof a teacher's address, from outside of the district network - but such spoofing attempts are easily identified as fraudulent, based upon their Received-by: headers, which will show that the message came from outside of the network. You can establish filters, to prevent such email from being accepted by your Internet gateway mail servers, but it sounds like that might be a stretch on your resources. If teachers feel the need to send email to other members of the district, from outside of the district's facilities (from home, perhaps), then perhaps they should be required to VPN into the district network, in order to do so.
My suspicion is that by filtering port 25 at the student-accessible workstations, you'll stop most of the network wiseacres. The more capable rug-munchkins will try this from the open network, but they will likely be rare, and more easily dealt with through training the staff to be vigilant for fraudulent email messages, then by establishing complex, difficult to implement, or invasive network policies. That's a judgement call, however, and yours to make - not mine... :)
Besides, we all knew that our teachers were eunichs, and the Principal was the biggest weiner of them all, when I was in school... :-P
Another, perhaps simpler method (which could be used in conjuction with the methods already described), might be for the students to simply not be told the teacher's district network email addresses, and to make them somewhat more obscure than first initial+last name or firstname.lastname. Perhaps you have employee numbers, or something to that effect?
ASKER
Mr Yowler,
Now I'm sorry I awarded the points in the disribution that I did! This is GREAT advice! I would like to see what I can do to get some points to you for this...
Again,
Thanks!
Now I'm sorry I awarded the points in the disribution that I did! This is GREAT advice! I would like to see what I can do to get some points to you for this...
Again,
Thanks!
as long as the clients have telnet.exe (or anything similar, perl, tcl, etc.), they are able to do it.
You my try to setup your MTA with authentification, for example SMTP-auth.
You my try to setup your MTA with authentification, for example SMTP-auth.
I live to server... (even when the solution can be procedural, rather than technical, in nature!) And thank-you for the extra points... :)
ahoffman - if the student workstations are unable to make TCP connections on post 25, then they would have to tunnel out to a system that is so permitted - outside of the district network, or to an instructor workstation. Assuming that the instructors know better than to install programs just because the kids ask them to, the instructor workstations should not be offerring network relay services of any kind. That only leaves the outside world, which is identifiable in those Received-by headers. That, and making sure that the students do not know the addresses being used procedurally, for internal district communications, should be pretty darned effective in either preventing the abuses, or mitigating their effectiveness, by making them easy to identify. Where things get hairy, is if the teachers use email to communicate with the parents - that sort of communication could be spoofed, and it's hard to train the parents to spot it - they typically lack the interest or motivation to do so. But that really wasn't the issue presented - and there are other ways to handle parent-teacher communications, that are perhaps more secure from meaconing-style tactics, and more effective, if it's a relevant issue... :)
Where do you see the little monsters escaping their cages?
ahoffman - if the student workstations are unable to make TCP connections on post 25, then they would have to tunnel out to a system that is so permitted - outside of the district network, or to an instructor workstation. Assuming that the instructors know better than to install programs just because the kids ask them to, the instructor workstations should not be offerring network relay services of any kind. That only leaves the outside world, which is identifiable in those Received-by headers. That, and making sure that the students do not know the addresses being used procedurally, for internal district communications, should be pretty darned effective in either preventing the abuses, or mitigating their effectiveness, by making them easy to identify. Where things get hairy, is if the teachers use email to communicate with the parents - that sort of communication could be spoofed, and it's hard to train the parents to spot it - they typically lack the interest or motivation to do so. But that really wasn't the issue presented - and there are other ways to handle parent-teacher communications, that are perhaps more secure from meaconing-style tactics, and more effective, if it's a relevant issue... :)
Where do you see the little monsters escaping their cages?
My guess is that they are actually using spam software, and may be cabale of rotating through remote proxy addresses, to send mail into your servers - if, in fact, they are sending the email to your servers.
The most probable scenario, is that you have someone using spam software to spoof your administrators, when sending mail to other people who are not neccessarily even on your network. If that's the case, then you are limited to hoping that the recipients are educated and intelligent enough to question the source of the message, and see that it did not originate on your email servers. If the attacker is actually sending this mail from within your network, then you need to get copies of the message, with delivery headers intact, and track down the IP address that is the source of the message, to a specific workstation, and kick someone's... well, someone will be needing to file an unemployment insurance claim.
If they are not sending from or to your network, but are merely spoofing your administrators, then your recourse is limited to legal action, if you can find the perpetrator/s. If they are spammers, then they are unlikely to have much that you can sue for, but you could still possibly jail them - again, if you can find them. Most spammers get nailed once or twice, and either stop what they have been doing, or get good at it. If they have learned to mask their source IP addresses, then you may be forced to buy whatever garbage they are selling, and then follow the money, to catch the little weasels.
It depends upon exactly what they are doing, and how badly you want them...