[email protected] wrote:
Zitat von Rob Janssen <[email protected]>:
Mouse wrote:
Have sites complaining that 72.8.140.222 is showing up on command
and control server. [...]
Whether a machine has been infected by malware is not related
directly to whether it is serving good time.
The problem is that some intrusion detection systems or ISP systems
that attempt to detect malware will see that someone is communicating
with an IP that is on a list of command and control servers, without
checking in detail what kind of communication it is.
The NTP pool also is not a mechanism for handholding sites with
incompetent IDS monitoring.
I think the pool should do nothing here. If it's serving good time, I
think it belongs in the pool; if it's not, not. Anyone who freaks out
over port-123 traffic to it because of something unrelated to NTP needs
to learn to check before freaking. It is not a service to keep the
incompetent from suffering the consequences of their incompetence.
But who is incompetent? The one who stamps any traffic to a C&C server as
suspicious,
or the one that does not consider that a botnet might use UDP port 123 on their
C&C
server and even make their C&C packets look a lot like NTP packets?
The baseline is, your IDS is able to give you hints on what might be suspicous,
it's up to you to decide if it is a real danger/unwanted or not.
It looks like you still don't get it.
It is not "my IDS" or the IDS of a user that is causing this problem.
It is the IDS deployed by an ISP or university or whatever supplier of network
bandwidth that
is triggered, and an innocent user that is disconnected "because of malware".
We can protect those innocent users by not supplying the address of C&C systems
via the DNS.
It is, in general, not possible to tell if the NTP service offered by a C&C
system is malicious or not.
Even when it serves correct time, it may still reply to other packet types with
info that the botnet
users need. Like small pieces of instruction (an IP address to attack,
another system to contact
for more elaborate control information, etc).
An IDS is not able to completely screen the protocol and neither is the
observer who traces
the packets. So it is very reasonable to alert when there is any communication
with a C&C server.
W.r.t. your other reply: there you in fact state that something like the NTP
pool is undesirable
and should not be setup the way it is now done (with voluntary participants who
can register
on a website and are joined to a pool after a cursory check of the
functionality of their service)
While I principally agree with that, it is not the position of the pool
administrators and the objective
of the pool. Maybe that should be discussed in more detail?
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
