Since the intended (and announced) use of this server is just for DIX
networks, blocking NTP from any other networks should be trivial. That
IP address will still be hit by D-Link devices looking for a suitable
server, but with no response, they'll move onto another device, and
probably never try the DIX address again, at least until they're
rebooted. That alone should kill off 95% of the unwanted traffic
hitting the box, and probably 80% of the traffic even being sent to DIX
in the first place.
It would be nice if it were that simple. However there are an annoyingly
large amount of poorly-written clients whose polling ratios do not
decrease after they get no response from the server. There have even
been some clients whose polling rate *increases* after they get no
response.
One particular piece of crapware of the tucows archive variety would retry
once per second if it hadn't heard a response - but a ICMP Port Unreachable
would trigger an *immediate* query, so it would basically re-query at whatever
the RTT for the path was.
Said software was why instead of leaving NTP disabled on the before-mentioned
box, and hoping that at least *some* people would clue in from the ICMP reply,
I had to basically firewall and drop the packets entirely.
I've said in other forums the only solution for this sort of software is
to return the wrong time (by several months). The owner might actually
notice then and fix the problem.
Just not returning anything means the time still works on the querying
device (especially if it uses multiple servers) and the problem will not
be noticed and it will continue.
I've said in other forums the only solution for this sort of software is
to return the wrong time (by several months). The owner might actually
notice then and fix the problem.
that creates new liability, and isn't realistic in today's litigious world.
Everyone here runs spam filters. Many times a day you tell a remote MTA
you've accepted their email but you delete it instead. Explain the
difference?
I run a NTP server, The only place it is advertised is a list which says
"To be used by people in DK exchange only" . Explain the difference
between my blocking someones packets (which causes them to just resend),
send a KOD ( ntp for "go away") packet (which is ignored) and telling them
the time is "2001-11-11 11:11:11" every time they ask?
People running RBLs change the access policy or return 127.0.0.1 for every
query sometimes. People running public Mail relays or public DNS servers
regularly block access or return bad results.
NTP provides a method to tell people to go away (The KOD packet) , if a
remote client ignores that and keeps flooding your (or your upstream
filters) with many udp packets per-second what exactly is someone
supposed to do? There is no contract between the Server operator and the
abusing client, The client is abusing the access policy and they have
ignored the automatic request to go away.
I've said in other forums the only solution for this sort of software is
to return the wrong time (by several months). The owner might actually
notice then and fix the problem.
that creates new liability, and isn't realistic in today's litigious world.
(Suprise to read that from PV.)
It is DIX resources/equipements... they are not oblige to offer reliable/secure/valide/etc services to anybody outside their clients.
It like saying that blacklist services like spamcop should be liable for mail servers XYZ deleting your email.
Anyway *litigious* is kinda limited our south neighbourgh... DIX is under a different legal system.
Good luck to DLink lawyers trying to bend reality enought the make DLink right... and oblige DIX to offer NTP to DLink customers for free.
Hold on there. What you are describing is evil and bad, and I certainly hope "everyone" does not do that.
When I do not wish to accept a message, I do not accept it, rejecting with an SMTP permanent delivery failure.
Don't mean to go off on a tangent, but accepting and then silently discarding mail is a terrible idea.
matto
--matt@snark.net------------------------------------------<darwin><
Moral indignation is a technique to endow the idiot with dignity.
- Marshall McLuhan
It seems to me, that the only *real* solution is for these manufacturers to
implement a [responsible] strategy of automatic firmware upgrades, as it
pertains to these (simple eu type) devices.
How difficult would it be to have the router test a server periodically,
(say once a month), and in the case of a critical flaw in the software,
silently update the device?
I suspect it is cost/benefit skepticism that is keeping them from doing just
that.
Are you suggesting that we configure our e-mail servers to notify
people upon automatic deletion of spam? Frequently, spam cannot be
properly identified until closure of the SMTP conversation and that
final 200 mMESSAGE ACCEPTED...or do you think that TCP/IP connection
should be held open until the message can be scanned for spam and
viruses just so we can give a 550 MESSAGE REJECTED error instead of
silently dropping it?
Because most spam originates from a bogus or stolen sender address,
notification creates an even bigger problem. What's next: asking for
permission to hang up on telemarketers?
matthew black
network services
california state university, long beach
Everyone here runs spam filters. Many times a day you tell a remote MTA
you've accepted their email but you delete it instead. Explain the
difference?
Hold on there. What you are describing is evil and bad, and I certainly hope "everyone" does not do that.
When I do not wish to accept a message, I do not accept it, rejecting with an SMTP permanent delivery failure.
Don't mean to go off on a tangent, but accepting and then silently discarding mail is a terrible idea.
This is way OT.
Inline rejection -- best
Notification after the fact -- Worst, but sometimes unavoidable
Silent Disacard -- better then blanket notifications
Try to limit the second in preference for the first.
For anything in which your detection mechanism's accuracy is high enough, you can probably perform the last without much worry.
matto
Are you suggesting that we configure our e-mail servers to notify
people upon automatic deletion of spam?
Dont do that. Notify the recpient if anything. Unfortunately they may learn to ignore such notifications, especialy if your system is fairly accurate. I advise against such "quarantine;store;notify;wait;delete" systems precisely because of this.
Frequently, spam cannot be
properly identified until closure of the SMTP conversation and that
final 200 mMESSAGE ACCEPTED...or do you think that TCP/IP connection
should be held open until the message can be scanned for spam and
viruses just so we can give a 550 MESSAGE REJECTED error instead of
silently dropping it?
Yes, a 550 after completion of DATA with <cr><lf>.<cr><lf> is perfectly acceptable and preferable. Legit senders should hang around for the half minute or so to receive 220, and illegits will tend to drop the connection after being told 550.
Because most spam originates from a bogus or stolen sender address,
notification creates an even bigger problem. What's next: asking for
permission to hang up on telemarketers?
I do that all the time with barely a no thanks. My wife complains that I am rude to do so. I think not.
The problem is in the word "most". With regards to anti-virus, "most" becomes "well upwards of 99%", and as such silent discard is more acceptable.
To keep this operational: Operationally the network operator should contact a lawyer before doing something like this.
Purposely and knowingly sending bad data in order to do harm is a counter-attack. As such it might be vigilantism, which is illegal in most countries. Or it might be self-defense, which is not illegal. Might. Contact a lawyer.
It would be a disaster. My (cable modem) ISP does that to my cable
modem/NAT box. A few months ago, a buggy update made the NAT part drop
all connections after 30 minutes. It took me a week or so to get enough
data to nail down the problem precisely. I then had the fun of trying to
get through the phone droids to reach someone who understood what "NAT"
or "TCP" meant. What unusual combination of features will random upgrades
break?
By the way, since we're talking about D-Link, it's instructive to read the
warnings on their firmware update pages.
Do NOT upgrade firmware on any D-Link product over a wireless
connection. Failure of the device may result. Use only hard-wired
network connections.
This firmware is engineered for US products only.
Using this firmware on a device outside of the United States will
void your warranty and may render the device unusable.
Other warnings I've seen include warnings that all configuration options
will be reset, version incompatibilities, and the suggestion that one
should connect to a UPS before doing the upgrade, just in case. (Hmm --
there's a vicious thunderstorm approaching, and the lights are
flickering. And it's time for the monthly autoupgrade!)
It's legal to have broken NTP server in ANY country, and it's legal in most
(by number) countries to send counter-attack (except USA as usual, where
lawyers want to get their money and so do not allow people to self-defence).
So, it can be a GOOD prtactice in reality. But, of course, not in USA.
On Tue, 2006-04-11 at 09:28:14 -0700, Alexei Roudnev proclaimed...
It's legal to have broken NTP server in ANY country, and it's legal in most
(by number) countries to send counter-attack (except USA as usual, where
lawyers want to get their money and so do not allow people to self-defence).
Usually I take my time from more than one server anyway, and discard the
bogus time. You'd think that d-link's crackshot development team would do
this, as well.
As I replied in a comment offline, auto updating firmware is nothing new.. my cellphone updates itself, as does my satellite receiver, and many other devices as well, (the best of which, perform these tasks without our notice or appreciation).
There is of course the potential for a bug causing some unforeseen catastrophy, but much of the risk could be mitigated with a bit of planning and a well designed system, (ex. old image is stored, and boot failure loads that image.. image is first downloaded, test md5, then flashed etc).
Servers have been using these technologies for quite a while now, all tested and true.
Also, one would expect the vendors to release updates only when necessary, with some serious QA before a release, (but if they did that in the first place, we wouldn't be having this discussion ;o)
Just a thought.
Why? It may be the voice of experience. In this country, and in many
others with hypertrophied legal systems, one may sue another for any
reason whatsoever. If the person bringing suit picks the judge
carefully, the suit might even not be recognised as idiotic and thrown
out immediately as without merit.
It is obvious that D-Link should not be doing this to DIX, no matter how
short a skirt DIX may be wearing. [;-)]
However, why should DIX try to turn around and do likewise to innocent
D-Link customers, even given that most of them would not notice it?
Paul is speaking from experience, having dealt with altogether too many people
who *do* believe that services Spamcop should be liable...
Even if it isn't a *legal* liability where you're forced to pay out damages,
having to carry '$100,000 legal fees' on the balance sheet is an accounting
liability, not an asset....