Begin <1134580174.531992.9180@f14g2000cwb.googlegroups.co m>
On 2005-12-14, Moregum wrote:
> I've a problem with a strange connection permantenly open in two
> openbsd machines, one version 3.0 and the other 3.4.
>
> Tcpdump shows this packet persistenly:
>
> 17:59:52.275195 [ip address in my network provider range but not
> mine].33374 > 232.0.0.3.1234: udp 1316 (DF) [ttl 1]
> 4500 0540 59ed 4000 0111 1443 3e51 e028
> e800 0003 825e 04d2 052c 94c7 4700 4419
> 172b 54a6 0fc0 8fb3 487d 7b07 80a4 6618
> 0803 e54a cb87 aa94 828a 0334 0593 113d
> 35aa d555 5705 d331 8d20 1dd5 ded9 38e7
> 21e1
>
> ntop shows a huge send transfer in this connection, but only in send
> column, tcp, udp and icmp are 0.

UDP is a stateless protocol so this by definition isn't a connection.
Going forward, notice the destination address: it's in the 224.0.0.0/4
range, meaning that it's multicast.

A quick google doesn't reveal clues on what it may be. If the network
is switched you really shouldn't be seeing any of those packets, but
apparently it is not. If you are worried you might contact the network
administration and ask them about it.


> I've tried to disable udp at PF, but this connection stills flowing,
> after I've used an utility called pftop to view the network activity
> but doesn't know about this connection, I don't what's happening my ISP
> told me about a virus, (virus in OpenBSD???)

Your ISP's helpdesk likely assumed you were running windows. You likely
didn't tell them you were dealing with multicast and even if you did
they might not even understand what multicast means.


> netstat on udp shows nothing too!

That would be because no service locally is listening to it.

I don't see consequences other than taking up some part of the available
bandwidth. The packet appears fairly large but if it appears only once
an hour it still is a negligible amount of data.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

On 14/12/2005 12:09 PM, Moregum wrote:
> Hi all,
>
> I've a problem with a strange connection permantenly open in two
> openbsd machines, one version 3.0 and the other 3.4.
>
> Tcpdump shows this packet persistenly:
>
> 17:59:52.275195 [ip address in my network provider range but not
> mine].33374 > 232.0.0.3.1234: udp 1316 (DF) [ttl 1]
> 4500 0540 59ed 4000 0111 1443 3e51 e028
> e800 0003 825e 04d2 052c 94c7 4700 4419
> 172b 54a6 0fc0 8fb3 487d 7b07 80a4 6618
> 0803 e54a cb87 aa94 828a 0334 0593 113d
> 35aa d555 5705 d331 8d20 1dd5 ded9 38e7
> 21e1
>
> ntop shows a huge send transfer in this connection, but only in send
> column, tcp, udp and icmp are 0.
>
As mentioned elsewhere, this is a multicast address. Sometimes things
like wireless access points issue these regularly. It might be someone
has an access point or natting router that is trying to do something silly.

At URL: http://www.iana.org/assignments/multicast-addresses we see for
232.0.0.0

232.000.000.000-232.255.255.255 Source Specific Multicast
[RFC-ietf-ssm-arch-07.txt]

Googling for SSM, I landed at URL:

http://www.ietf.org/internet-drafts/...sm-arch-07.txt

IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
currently designated as source-specific multicast (SSM) destination
addresses and are reserved for use by source-specific applications and
protocols [IANA-ALLOCATION].

Port 1234:
search-agent 1234/tcp #Infoseek Search Agent
search-agent 1234/udp #Infoseek Search Agent
hotline 1234/tcp #HotLine
SubSevenJavaclient 1234/tcp #[trojan] SubSeven Java client
UltorsTrojan 1234/tcp #[trojan] Ultors Trojan

port 1316:
exbit-escp 1316/tcp #Exbit-ESCP
exbit-escp 1316/udp #Exbit-ESCP

(Source: http://www.eunet.at/support/toolbox/services.php).

Perhaps sniffing the traffic (www.ethereal.com) will give you more
clues as to what is going on. Who (which IP host) is registering to
this multicast address, and why.

Goodluck.

At URL: http://www.iana.org/assignments/multicast-addresses we see for
232.0.0.0

232.000.000.000-232.255.255.255 Source Specific Multicast
[RFC-ietf-ssm-arch-07.txt]

Googling for SSM, I landed at URL:

http://www.ietf.org/internet-drafts/...sm-arch-07.txt

IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
currently designated as source-specific multicast (SSM) destination
addresses and are reserved for use by source-specific applications and
protocols [IANA-ALLOCATION].

Port 1234:
search-agent 1234/tcp #Infoseek Search Agent
search-agent 1234/udp #Infoseek Search Agent
hotline 1234/tcp #HotLine
SubSevenJavaclient 1234/tcp #[trojan] SubSeven Java client
UltorsTrojan 1234/tcp #[trojan] Ultors Trojan

port 1316:
exbit-escp 1316/tcp #Exbit-ESCP
exbit-escp 1316/udp #Exbit-ESCP

(Source: http://www.eunet.at/support/toolbox/services.php).

Perhaps sniffing the traffic (www.ethereal.com) will give you more
clues as to what is going on. Who (which IP host) is registering to
this multicast address, and why.

Goodluck.

At URL: http://www.iana.org/assignments/multicast-addresses we see for
232.0.0.0

232.000.000.000-232.255.255.255 Source Specific Multicast
[RFC-ietf-ssm-arch-07.txt]

Googling for SSM, I landed at URL:

http://www.ietf.org/internet-drafts/...sm-arch-07.txt

IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
currently designated as source-specific multicast (SSM) destination
addresses and are reserved for use by source-specific applications and
protocols [IANA-ALLOCATION].

Port 1234:
search-agent 1234/tcp #Infoseek Search Agent
search-agent 1234/udp #Infoseek Search Agent
hotline 1234/tcp #HotLine
SubSevenJavaclient 1234/tcp #[trojan] SubSeven Java client
UltorsTrojan 1234/tcp #[trojan] Ultors Trojan

port 1316:
exbit-escp 1316/tcp #Exbit-ESCP
exbit-escp 1316/udp #Exbit-ESCP

(Source: http://www.eunet.at/support/toolbox/services.php).

Perhaps sniffing the traffic (www.ethereal.com) will give you more
clues as to what is going on. Who (which IP host) is registering to
this multicast address, and why.

Goodluck.

Lot of thanks for your answers, you guys put me on the right way to
warn my ISP on the real problem. (Virus in OpenBSD hahahaa... :-)) )

I've must admit that I wasn't very familiarised (no familiarised at
all) with the multicast/broadcast udp transmisions, the problem was in
another machine in their subnet (my servers are on a housing service)
that was irradiating udp packets with a huge broadcasting (collapsing
my 1 Mb/s "reserved" band), the probe, at the moment that they started
to filter those packets my avg traffic out passed from 957.8 kb/s to
30.7 kb/s in the most busied server...

One question more, anyone know if there is a way to stop that
(broadcast) traffic inside a OpenBSD box? I've checked all udp options
at sysctl, but with no success, and attending to murphy's law and my
ISP's operators skills, this is going to happen me again... Sure there
is a way... (recompiling?)