VoIP 911 service is badly needed, however there are some major issues that HAVE to be worked out.
Unlike traditional telephone services, VoIP services do not have to be geopraphicly routed. A given NPA/NXX combination provides NO reliable indication of the callers location. The methods used for cellular phones (triangulation, signal strength analysis, and GPS) aren't workable either because the phone may be operating where GPS signals are not available (GPS doesn't penetrate solid objects very well), and doesn't use a system of local radio uplinks to access the PSTN.
Even when the expected address is in some sort of database, VoIP devices can be highly portable, so special call handling is really needed. This means operators that are specially trained to drill the caller for address information -- and that can be VERY difficult when the person on the other end is panicing -- especially if its a very young or elderly caller that may not be particularly aware of their surroundings! Because IP addresses don't map conveniently to physical addresses, it may NOT be possible to dispatch accurately to such a highly mobile device in the event of abandoned 911 calls, at least not without timely and IMMEADIATE cooperation from internet service providers. (Of course, this form of cooperation is being resisted by many ISPs on privacy grounds thanks to overzealous actions by such wonderful organizations as the RIAA and SCO. "Hello, Verizon" "This is the New York City E-911 center, we have a caller from IP address xx.xx.xx.xx". "Sorry, we can't give out any information without a court order". )
Using a PXE boot rom, possibly in conjunction with a secondary loader such as bpbatch (http://www.bpbatch.org/), you can leave the drives in place, but have a full reimage process in a matter of minutes anytime the machine is rebooted.
If you are using a software based metering system, you could also install watchdog cards in the machines, and tie the metering software into those cards - the timer on the card is automatically set to the customer's time left, and if they somehow disable the metering software, the machine still reboots.
After that, you really don't need to bother with locking down the machine, regardless of how well it's trashed, the reset switch will cure it.
In reality, port 25 blocking proves to be only a minor inconvenience for legitimate users. They will either use the SMTP servers of the provider they are directly connected to, or they will make alternate arrangements to send mail out another way. Port 25 blocking can be accomplished in such a way that attempts to send mail through outside mailservers instead go through the providers mailservers. That way, users with email accounts on other providers can send mail without changing settings, and spammers can be caught quickly.
Yes, I agree it's sad that such measures have to be taken, but for the most part, they are for the better.
AOL apparently redirects port 25 through their own mailservers now, so anyone trying to access outside SMTP servers instead leaves an audit trail on AOL's mailserver.
I definantely have to agree there. That said, market forces CAN force a legitimate company that has crossed the line into spamming to change. Start sending mail to DoubleClick advertisers, let them know that so long as they advertise using DoubleClick, and DoubleClick advertises using spam, you won't buy they products. Enough people do that, and doubleclick will find it very expensive to spam, as all their more legitimate customers start walking away.
There are two diffrent common methods of copy/paste in X. the "PRIMARY SELECTION" and "CUT BUFFER 0"
The xcutsel program allows you to copy beween the two. Theres also a neat little program autocutsel which can be used to keep the two "clipboards" in sync with each other, providing a copy/paste that works everywhere:) http://freshmeat.net/projects/autocutsel/
While most system administrators are aware of the need to make sure that servers under their control do not relay to third parties, few are aware of all of the vunerabilites through which their mailserver can be used to relay mail, and which aren't exposed by the most basic form of relay tests.
I've seen many administrators insist that they were not an open relay, only to be shown that they had been used as a relay, and that some very simple method was used to trick the mailserver into relaying the mail.
One example, the relay_local_from option in sendmail (which you SHOULD NOT ever use!).
With this option, the mailserver will relay
any message supposedly originating from a local
email address. So any mail supposedly from postmaster@that.server.com would be blindly relayed. There are at least 15 or so vuenerabilities that I've heard of, which can be used to trick what at first glance appeared
to be a secure mail server into relaying spam.
At one point, these were commonly overlooked by both spammers and sysadmins. These days, the spammers are testing for even the most obscure relaying vunerabilities, as wide open
relays are getting harder to find, they are finding huge numbers of servers that were only secured against the most basic methods of unauthorized mail relay, and therefore, aren't
secure at all. Theres a pretty comprehensive tester on MAPS web site, as well as several standalone testers availible under various licenses. And yes, there are commercial mailservers that *CAN'T* be secured. If you are running one of them, its your responsibility to secure it by denying unauthorized users connectivity to it, either by physically disconnecting it, or by use of firewalls or other technical means to insure that only authorized users can connect to the SMTP port on the mailserver. Even if its not practical to replace one of these mailservers, it *is* practical, and perfectly reasonable to place them behind a firewall, and put a properly secured smarthost outside the firewall
to provide the means for authorized mail to
enter and leave the network. Any of several secure-by-default mailservers can be installed and configured by any competent administrator in less than a day, providing an instant replacement to (or gateway for) an insecure mailserver. As for those administrators that haven't yet found out that their relay is insecure:
Test regularly, especially after any configuration change. Adopt a policy requiring customer mailservers to be tested for relaying periodicly, and deny connectivity to those servers which are found to be open relays until they are fixed. Fully investigate any claim that your mailserver is relaying spam.
Deal with spammers on your network as soon as you learn about them. Consider checking the antispam newsgroups occasionally for evidence of major problems (hint: google makes it very easy to search news.admin.net-abuse.*:). Make sure abuse@ and postmaster@ works and is read regularly. Block port 25 inbound to hosts which aren't authorized to run mailservers so you don't have problems with unauthorized mailservers you don't know about. Block port 25 inbound AND outbound for your dialup hosts, cable modems, dsl , and other "consumer" links, which shouldn't be running mailservers, and should be using only YOUR mailservers to send email. This will stop direct-to-MX spammers from operating from your network, as well as prevent spammers from using your dialups to abuse open relays.
Slashdot Mirror
VoIP 911 service is badly needed, however there are some major issues that HAVE to be worked out.
Unlike traditional telephone services, VoIP services do not have to be geopraphicly routed. A given NPA/NXX combination provides NO reliable indication of the callers location. The methods used for cellular phones (triangulation, signal strength analysis, and GPS) aren't workable either because the phone may be operating where GPS signals are not available (GPS doesn't penetrate solid objects very well), and doesn't use a system of local radio uplinks to access the PSTN.
Even when the expected address is in some sort of database, VoIP devices can be highly portable, so special call handling is really needed. This means operators that are specially trained to drill the caller for address information -- and that can be VERY difficult when the person on the other end is panicing -- especially if its a very young or elderly caller that may not be particularly aware of their surroundings! Because IP addresses don't map conveniently to physical addresses, it may NOT be possible to dispatch accurately to such a highly mobile device in the event of abandoned 911 calls, at least not without timely and IMMEADIATE cooperation from internet service providers.
(Of course, this form of cooperation is being resisted by many ISPs on privacy grounds thanks to overzealous actions by such wonderful organizations as the RIAA and SCO. "Hello, Verizon" "This is the New York City E-911 center, we have a caller from IP address xx.xx.xx.xx". "Sorry, we can't give out any information without a court order". )
Two words. Boot Rom.
Using a PXE boot rom, possibly in conjunction with a secondary loader such as bpbatch (http://www.bpbatch.org/), you can leave the drives in place, but have a full reimage process in a matter of minutes anytime the machine is rebooted.
If you are using a software based metering system, you could also install watchdog cards in the machines, and tie the metering software into those cards - the timer on the card is automatically set to the customer's time left, and if they somehow disable the metering software, the machine still reboots.
After that, you really don't need to bother with locking down the machine, regardless of how well it's trashed, the reset switch will cure it.
In reality, port 25 blocking proves to be only a minor inconvenience for legitimate users. They will either use the SMTP servers of the provider they are directly connected to, or they will make alternate arrangements to send mail out another way. Port 25 blocking can be accomplished in such a way that attempts to send mail through outside mailservers instead go through the providers mailservers. That way, users with email accounts on other providers can send mail without changing settings, and spammers can be caught quickly.
Yes, I agree it's sad that such measures have to be taken, but for the most part, they are for the better.
AOL apparently redirects port 25 through their own mailservers now, so anyone trying to access outside SMTP servers instead leaves an audit trail on AOL's mailserver.
Not a perfect solution, but a start.
http://www.anybrowser.org/campaign/
I definantely have to agree there. That said, market forces CAN force a legitimate company that
has crossed the line into spamming to change.
Start sending mail to DoubleClick advertisers, let them know that so long as they advertise using DoubleClick, and DoubleClick advertises
using spam, you won't buy they products. Enough people do that, and doubleclick will find it very expensive to spam, as all their more legitimate customers start walking away.
There are two diffrent common methods of copy/paste in X.
:) http://freshmeat.net/projects/autocutsel/
the "PRIMARY SELECTION" and "CUT BUFFER 0"
The xcutsel program allows you to copy beween the
two. Theres also a neat little program autocutsel which can be used to keep the two "clipboards" in sync with each other, providing a copy/paste that works everywhere
/me puts up a don't feed the trolls sign :)
While most system administrators are aware of the need to make sure that servers under their control do not relay to third parties, few are aware of all of the vunerabilites through which their mailserver can be used to relay mail, and which aren't exposed by the most basic form of relay tests.
:). Make sure abuse@ and postmaster@ works and is read regularly. Block port 25 inbound to hosts which aren't authorized to run mailservers so you don't have problems with unauthorized mailservers you don't know about. Block port 25 inbound AND outbound for your dialup hosts, cable modems, dsl , and other "consumer" links, which shouldn't be running mailservers, and should be using only YOUR mailservers to send email. This will stop direct-to-MX spammers from operating from your network, as well as prevent spammers from using your dialups to abuse open relays.
I've seen many administrators insist that they were not an open relay, only to be shown that they had been used as a relay, and that some very simple method was used to trick the mailserver into relaying the mail.
One example, the relay_local_from option in sendmail (which you SHOULD NOT ever use!).
With this option, the mailserver will relay
any message supposedly originating from a local
email address. So any mail supposedly from postmaster@that.server.com would be blindly relayed. There are at least 15 or so vuenerabilities that I've heard of, which can be used to trick what at first glance appeared
to be a secure mail server into relaying spam.
At one point, these were commonly overlooked by both spammers and sysadmins. These days, the spammers are testing for even the most obscure relaying vunerabilities, as wide open
relays are getting harder to find, they are finding huge numbers of servers that were only secured against the most basic methods of unauthorized mail relay, and therefore, aren't
secure at all. Theres a pretty comprehensive tester on MAPS web site, as well as several standalone testers availible under various licenses. And yes, there are commercial mailservers that *CAN'T* be secured. If you are running one of them, its your responsibility to secure it by denying unauthorized users connectivity to it, either by physically disconnecting it, or by use of firewalls or other technical means to insure that only authorized users can connect to the SMTP port on the mailserver. Even if its not practical to replace one of these mailservers, it *is* practical, and perfectly reasonable to place them behind a firewall, and put a properly secured smarthost outside the firewall
to provide the means for authorized mail to
enter and leave the network. Any of several secure-by-default mailservers can be installed and configured by any competent administrator in less than a day, providing an instant replacement to (or gateway for) an insecure mailserver. As for those administrators that haven't yet found out that their relay is insecure:
Test regularly, especially after any configuration change. Adopt a policy requiring customer mailservers to be tested for relaying periodicly, and deny connectivity to those servers which are found to be open relays until they are fixed. Fully investigate any claim that your mailserver is relaying spam.
Deal with spammers on your network as soon as you learn about them. Consider checking the antispam newsgroups occasionally for evidence of major problems (hint: google makes it very easy to search news.admin.net-abuse.*
And once again, how exactly are the planning to put a value on free software? Comparison to microsloth products?