Open Ports on Fremantle/N900

[Wonko]

Hi,

i don't know if i am kinda paranoid but i like to keep my machines as closed as possible.
"Closed" meaning that i do not want any ports being open (i.e. having services listening on them) on (at least) public interfaces which are not necessarily needed.
I.e. for a usual browsing/internet machine i'd like to see no open ports at all.

On the N900 there are at least some UDP ports open (for completeness i post the complete outputs below):

~# netstat -tunla
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 192.168.0.125:22 192.168.0.168:59860 ESTABLISHED
tcp 0 144 192.168.0.125:22 192.168.0.168:36305 ESTABLISHED
netstat: no kernel support for AF INET6 (tcp)
udp 0 0 0.0.0.0:2948 0.0.0.0:*
udp 0 0 127.0.0.1:51365 127.0.0.1:3002 ESTABLISHED
udp 0 0 127.0.0.1:53 0.0.0.0:*
udp 0 0 127.0.0.1:3001 0.0.0.0:*
udp 0 0 127.0.0.1:3002 0.0.0.0:*
udp 0 0 127.0.0.1:60484 127.0.0.1:3001 ESTABLISHED
udp 0 0 0.0.0.0:49751 0.0.0.0:*
udp 0 0 0.0.0.0:57439 0.0.0.0:*
udp 0 0 0.0.0.0:1900 0.0.0.0:*
netstat: no kernel support for AF INET6 (udp)


~# lsof -i4
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
ohmd 719 root 7u IPv4 3647 UDP Nokia-N900-42-11:3002
ohmd 719 root 36u IPv4 3741 UDP Nokia-N900-42-11:3001
wappushd 725 root 5u IPv4 3373 UDP *:2948
dnsmasq 1067 nobody 4u IPv4 5408 TCP Nokia-N900-42-11:domain (LISTEN)
dnsmasq 1067 nobody 5u IPv4 5409 UDP Nokia-N900-42-11:domain
app-detec 1092 root 3u IPv4 5680 UDP Nokia-N900-42-11:60484->Nokia-N900-42-11:3001
app-detec 1092 root 4u IPv4 5681 UDP Nokia-N900-42-11:51365->Nokia-N900-42-11:3002
mafw-dbus 1251 user 8u IPv4 10311 UDP *:49751
mafw-dbus 1251 user 9u IPv4 10312 UDP *:1900
browser 1474 user 11u IPv4 9102 UDP *:57439
sshd 1644 root 3u IPv4 11074 TCP *:ssh (LISTEN)
sshd 1647 root 3r IPv4 11090 TCP 192.168.0.125:ssh->192.168.0.168:59860 (ESTABLISHED)
sshd 1665 root 3r IPv4 13579 TCP 192.168.0.125:ssh->192.168.0.168:36305 (ESTABLISHED)

Port 22 is open because i am currently accessing the device via ssh in my private network (usually sshd is shut down of course).
Second it is not really nice to have that many things listening on the local address but this is not my main concern.
The point which i do not like is that some services listen on all interfaces / the wildcard address.

I played around a little bit and could shutdown wappushd (by removing it from the runlevels) and mafw-dbus (by messing with its start script in /usr/bin/mafw.sh).
The problem with mafw-dbus is, is that it seems to be needed for the media player to work correctly.
As of shutting down wappushd i did not notice a negative side effect yet.

Is there any sane way to shut these services down or at least reconfigure these services to only listen on the loopback interface?


Best regards,

Wonko

[jebba]

I scanned the ports you had open to the outside on my system to see the difference:

# nmap -sU -p 2948,49751,57439,1900 10.0.0.4

Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-29 18:58 ART
Interesting ports on burger (10.0.0.4):
PORT STATE SERVICE
1900/udp open|filtered upnp
2948/udp open|filtered wap-push
49751/udp closed unknown
57439/udp closed unknown
MAC Address: 34:7E:39:42:BB:C3 (Unknown)

So only 1900 and 2948 were remotely "open".

Here's my output of your netstat command for comparison:

# netstat -tunla
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:53651 0.0.0.0:* LISTEN
tcp 0 0 10.0.0.4:53651 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 10.0.0.4:62906 74.125.45.109:993 ESTABLISHED
tcp 0 0 10.0.0.4:61239 208.68.163.220:5222 ESTABLISHED
tcp 0 0 172.26.233.37:52385 130.237.188.200:6667 ESTABLISHED
tcp 0 0 10.0.0.4:54306 209.85.163.125:5222 ESTABLISHED
tcp 0 1232 10.0.0.4:22 10.0.0.3:41447 ESTABLISHED
netstat: no kernel support for AF INET6 (tcp)
udp 0 0 0.0.0.0:2948 0.0.0.0:*
udp 0 0 127.0.0.1:51855 127.0.0.1:53 ESTABLISHED
udp 0 0 127.0.0.1:64786 127.0.0.1:3002 ESTABLISHED
udp 0 0 127.0.0.1:53651 0.0.0.0:*
udp 0 0 10.0.0.4:53651 0.0.0.0:*
udp 0 0 0.0.0.0:61464 0.0.0.0:*
udp 0 0 127.0.0.1:53 0.0.0.0:*
udp 0 0 127.0.0.1:63801 127.0.0.1:3001 ESTABLISHED
udp 0 0 127.0.0.1:3001 0.0.0.0:*
udp 0 0 127.0.0.1:3002 0.0.0.0:*
udp 0 0 127.0.0.1:60104 127.0.0.1:53 ESTABLISHED
udp 0 0 0.0.0.0:51687 0.0.0.0:*
udp 0 0 0.0.0.0:1900 0.0.0.0:*

And the list of open files:

# lsof -i4
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sshd 671 root 3u IPv4 3055 TCP *:ssh (LISTEN)
ohmd 751 root 7u IPv4 3745 UDP Nokia-N900-42-11:3002
ohmd 751 root 36u IPv4 3836 UDP Nokia-N900-42-11:3001
wappushd 757 root 6u IPv4 3473 UDP *:2948
dnsmasq 1068 nobody 4u IPv4 5341 TCP Nokia-N900-42-11:domain (LISTEN)
dnsmasq 1068 nobody 5u IPv4 5342 UDP Nokia-N900-42-11:domain
app-detec 1084 root 3u IPv4 5770 UDP Nokia-N900-42-11:63801->Nokia-N900-42-11:3001
app-detec 1084 root 4u IPv4 5771 UDP Nokia-N900-42-11:64786->Nokia-N900-42-11:3002
mafw-dbus 1264 user 8u IPv4 46014 UDP *:61464
mafw-dbus 1264 user 9u IPv4 46015 UDP *:1900
telepathy 1564 user 12u IPv4 46143 UDP 10.0.0.4:53651
telepathy 1564 user 14u IPv4 46144 TCP 10.0.0.4:53651 (LISTEN)
telepathy 1564 user 15u IPv4 46145 UDP Nokia-N900-42-11:53651
telepathy 1564 user 16u IPv4 46146 TCP Nokia-N900-42-11:53651 (LISTEN)
telepathy 1564 user 17u IPv4 46147 UDP Nokia-N900-42-11:51855->Nokia-N900-42-11:domain
telepathy 1564 user 18u IPv4 46149 UDP Nokia-N900-42-11:60104->Nokia-N900-42-11:domain
telepathy 1566 user 9u IPv4 65374 TCP 10.0.0.4:54306->el-in-f125.1e100.net:xmpp-client (ESTABLISHED)
telepathy 1566 user 10u IPv4 46135 TCP 10.0.0.4:61239->hermes.jabber.org:xmpp-client (ESTABLISHED)
xchat 1709 user 14u IPv4 33839 TCP 172.26.233.37:52385->lindbohm.it.su.se:ircd (ESTABLISHED)
browser 1770 user 11u IPv4 34758 UDP *:51687
sshd 2081 root 3u IPv4 46070 TCP 10.0.0.4:ssh->10.0.0.3:41447 (ESTABLISHED)
sshd 2089 user 3u IPv4 46070 TCP 10.0.0.4:ssh->10.0.0.3:41447 (ESTABLISHED)
modest 2171 user 21u IPv4 63970 TCP 10.0.0.4:62906->yx-in-f109.1e100.net:imaps (ESTABLISHED)

It does seem odd to have some of those ports open to the outside. Perhaps a bug report should be filed for ones that aren't absolutely necessary to have open.

[jiiv]

WTB iptables ;)

[Wonko]

So only 1900 and 2948 were remotely "open".

Thanks for your answer!

I made similar observations:
"wappushd" listens on UDP:2948
"mafw-dbus" listens on UDP:1900

Additionally "mafw-dbus" and "browser" each listen on a random unpriviledged UDP port (Edit: this port seems to be randomly assigned at boot up).

In my case:
mafw-dbus - UDP *:49751
browser - UDP *:57439

In your case:
mafw-dbus - UDP *:61464
browser - UDP *:51687


It does seem odd to have some of those ports open to the outside. Perhaps a bug report should be filed for ones that aren't absolutely necessary to have open.
Agreed, its kinda strange to have the device listening to the outside by default. At least there should be an option to alter this behavior. I'll try to dig a little bit deeper into this before filing a bug report.

[Wonko]

WTB iptables ;)
Thanks for your answer as well! ;)
I didn't find a place where to get iptables for Fremantle/N900 yet. As far as i can tell i would have to manually compile the stuff as there seems no package yet.

Also iptables would be some kind of intermediate solution imho. This may be some kind of philosophic question but i think its "nicer" to have the services on a machine properly configured (i.e. only having them listen on the desired interfaces for example) then "fixing" strangely configured services afterwards by e.g. denying access via iptables.

Anyway, this solution would also work as a temporary fix.

[jiiv]

Agreed, having stuff only listen where necessary is the most elegant solution.
There are some iptables binaries around but I'm not sure whether they're functional (I know the kernel is missing nat support and such). These are totally unsupported and such, but there's an iptables .deb here (https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/blobs/?root=mobilehotspot) if you're willing to risk it.

[Wonko]

Alright i think i found some tweaks to get rid of at least some of the offending services.
Of course whenever changing or deleting something i assume you do have backups. ;)

wappushd:

update-rc.d -f wappushd remove
rm /etc/event.d/wappushd


mafw-dbus stuff:

mv /usr/lib/mafw-plugin/mafw-upnp-source.so backup/usr/lib/mafw-plugin/

Edit: Add a little bit more explanation:
This approach is kinda "safe" because of the way the mafw plugins are loaded via "/etc/X11/Xsession.post/32mafw". This script simply iterates over all *.so files found in "/usr/lib/mafw-plugin" and loads these.

browser:
First i thought i had this one eliminated as well but it appears to just start very late after a reboot. So this is still left for now.

Side effects:
For now i couldn't notice any negative side effects so far. We'll see how this keeps going (i'll let you know as soon as i encounter strange behavior which can be tracked down to the above changes).


Happy New Year all! :)

[TA-t3]

Does anyone know what 'wappushd' does? It's got a suspicious name.. I would like to know if I want to get rid of it too.

[Wonko]

Suspicious yeah .. wap and push this basically gives an idea of what it is supposed to do ;)
But don't ask me what this daemon is really for. ;)

In "/etc/dbus-1/system.d/wappushd_policy.conf" there is some dbus config stuff with respect to wappushd but i didn't touch dbus for quite a long time so i'm kinda rusted in that topic.

[Wonko]

Well finally i also found at least some solution for the browser issue.

The solution is to simply install a different webbrowser (i choose midori for now) and use browser switchboard to set it as the default browser. After a reboot there is no browser process listening on random sockets.

Some more notes:
"browser" not only listens on UDP but after some webbrowsing also had other ports open, even on TCP. Here again i'm not talking about the browser opening connections to the "outside" but the browser process itself opening a socket and actively listening for "incoming" connections. Also the browser process is running in the background and kept the ports open even after closing the "browser window".

As far as i can tell this behavior is related to the way Fremantle is handling the built in browser. I.e. it has split up the browser in some "daemon" part which is running in the background and handles the actual browsing etc. and some "frontend" which displays the actual GUI window. Still it feels kind of strange to see my web browser opening/listening on sockets.

The browser process is a child process of "maemo-launcher" which also takes care of restarting the process if browser is killed manually. According to the documentation maemo-launcher is used to speed up loading of applications (http://maemomm.garage.maemo.org/docs/tutorial/html/ch07.html). In fact you should be very careful when messing with maemo-launcher and especially the statrtup script in "/etc/X11/Xsession.d/02maemo-launcher" as you can easily "brick" your device and need to reflash it to fix it (guess why i know this ;)).


So far...

Best regards,

Wonko

[Graham Cobb]

It might be worth logging these as bugs (against each application separately). If there is a good reason to have the ports open it will probably be closed as WONTFIX but if it is an oversight (and they should really only be listening on the loopback interface) then they sound like bugs which should be fixed.

If you log the bugs, list them here so anyone else who cares can go and vote for them.

Graham

[Wonko]

Thanks for the hint, i added the according bug reports:
https://bugs.maemo.org/show_bug.cgi?id=7619
https://bugs.maemo.org/show_bug.cgi?id=7620
https://bugs.maemo.org/show_bug.cgi?id=7621

Best regards

Wonko

[jebba]

Thanks for the hint, i added the according bug reports:
https://bugs.maemo.org/show_bug.cgi?id=7619
https://bugs.maemo.org/show_bug.cgi?id=7620
https://bugs.maemo.org/show_bug.cgi?id=7621

Cool, thx for opening these bug reports. Will be interesting to see if this was an oversight or if they are open for remote for some legit reason. I'm guessing they should just be listening on localhost only.

[TA-t3]

I was reading up about WAP PUSH. I wonder why there should be support for that at all on this device. It accesses the real internet after all, not that old WAP rubbish.

[pycage]

WAP push is not WAP. It's a means for e.g. software installation by your carrier. E.g. T-Online's mobile banking client installs per WAP push (but not on the N900 since it's Java). There's a daemon listening because the N900 is a phone.

The 1900 UDP port is for listening to SSDP broadcast messages used by UPnP. If you close this port, your N900 won't be able to find UPnP devices on the network anymore, provided you have some.

[TA-t3]

OK. But I don't see how the carrier can push software installations to random phone devices, they're all having different operating systems. My carrier has (in the past) pushed stuff which has been loaded into the SIM card though. Is that through the same mechanism? It sounds a bit unlikely because this used to happen to my very old phone which was before WAP was even invented.

[pycage]

Java MIDlets usually work on many phones. The carrier won't push without your permission or request usually, though.