[SOLVED] Rds_tcp_port 16385

[bschnzl]

So …

I'm looking over my system like any good netizen. You know, checking the processes that run after everything is up, looking thru the logs to see if there is anything strange, checking the open ports...

~ # netstat -tanup
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:16385 0.0.0.0:* LISTEN -

Curious... that looks suspiciously like a root kit gone bad. I mean, any rootkit worth its l33tn355 would hide better than that, no? I really don't have time for this... Let's just poke around and see if there is something odd running.

~ # ps ax f
(showed nothing of interest: pid 3690)

I run XFCE on a Xen Dom0. Agetty is the most noticeable after the LONG string of kernel proc's goes by. Looking a little closer showed nothing that I do not remember installing. When did this show up anyhow?

I generally look over things about once a week. It would not do to plug into someones network if you had errant ports listening. The last thing I installed was Kernel 3.6.11. Why would the kernel open a port? Don't be silly, the Kernel doesn't open ports!

To be honest I had to run at this point. I run the IDS at work, and I have the same facility at home. I'll just run a search for that port on a daily basis. I did... nothing. Whew!

How do I find a LISTENING port on a linux box if it has no PID or executable name? Grep thru /proc? That gave me a copy of netstat for every running process. Helpful >:(

Finally, I started turning off processes and rebooting! I even created a new user, and put /bin/sh as the default shell. I removed the cruft from /etc/skel too. Nope, still there!

I sit there with a machine that starts syslog-ng - only! Syslog would open udp port 514. If it was opening 16385/t that would be something. I start gearing up for some mind splitting tracing of an exploit! There is nothing left...

~ # grep 16385 /usr/src/linux/.config
~ # grep -r 16385 /usr/src/linux/*
/usr/src/linux/System.map:ffffffff816385d0 t do_ipt_get_ctl
/usr/src/linux/drivers/staging/tidspbridge/dynload/reloc_table_c6000.c: 16385,
/usr/src/linux/lib/zlib_inflate/inffixed.h: {21,5,65},{29,5,16385},{16,5,3},{24,5,513},{20,5,33},{28,5,8193},
/usr/src/linux/lib/zlib_inflate/inftrees.c: 8193, 12289, 16385, 24577, 0, 0};
/usr/src/linux/lib/inflate.c: 8193, 12289, 16385, 24577};
/usr/src/linux/net/rds/tcp.h:#define RDS_TCP_PORT 16385
/usr/src/linux/sound/soc/codecs/wm5100.h: * R16385 (0x4001) - DSP1 DM 1
/usr/src/linux/sound/soc/codecs/wm8962.c: { 16385, 0x0000 }, /* R16385 - RETUNEADC_SHARED_COEFF_0 */
/usr/src/linux/sound/soc/codecs/wm8962.h: * R16385 (0x4001) – RETUNEADC_SHARED_COEFF_0

HELLO!
/usr/src/linux/net/rds/tcp.h:#define RDS_TCP_PORT 16385

Wait:
lrwxrwxrwx 1 root root 19 Jan 5 20:01 linux -> linux-3.6.11-gentoo

~ # uname -a
Linux zzzzz 3.6.11-zzzz #1 SMP Sat Jan 5 19:10:27 EST 2013 x86_64 Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz GenuineIntel GNU/Linux

~ # grep -i RDS …/DOM0/.config
CONFIG_RDS = y
CONFIG_RDS_TCP = y

Look at that!

~ # cd /usr/src/linux
~ # make O=.../DOM0/ menuconfig
- > Networking support
- > Networking options
Clear RDS over TCP
Clear The RDS Protocol (EXPERIMENTAL)
exit … save …

~ # make O=.../DOM0/

Install fresh kernel
~ # uname -a
Linux zzzzzz 3.6.11-zzzz #2 SMP Wed Jan 30 21:02:04 EST 2013 x86_64 Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz GenuineIntel GNU/Linux

no more port 16385!

Leave it to Oracle to open a port in the kernel.

Once I had a trove of data, I went back to find what I had missed... sure enuf:
http://www.generation-nt.com/reponses/retrouver-nom-daemon-entraide-3848461.html

I am lost in French, I took German! But there is a translate link in Google! This is from way back in 2010! I guess pitching a fit would be a little over the top!

I just wanted to save other conscientious operators a little time. Pretty soon, all of the norms will be broken, and newb's will really have a bad time tracing their systems! Rules are there to be broken by anyone who think it will make them a buck! Now... try to do that on a mass-produced-cookie-cutter-can't-turn-a-service-off-or-it-will-void-your-warrantee box!

So much for the end-user being the one to secure a network! At a minimum, each network service should have it's own user account. Never ever ever let the kernel listen directly to the network. Show me a service without a network exploitable history, and I will show you a newb! Thanks Oracle! (If you are an Oracle Dev, tell Oracle to trash RDS! Someone give Linus a "probie" whack. What is this, Windows???)

Fair Use! Go Gentoo!
</rant>
_________________
Persistance Pays