Active Topics
-
Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 17 hrs, 34 mins ago -
Handbook (2)
to Maemo 7 / Leste by teroyk - 1 day, 16 hrs ago - more...
|
2009-12-29
, 22:04
|
|
Posts: 355 |
Thanked: 566 times |
Joined on Nov 2009
@ Redstone Canyon, Colorado
|
#2
|
I scanned the ports you had open to the outside on my system to see the difference:
So only 1900 and 2948 were remotely "open".
Here's my output of your netstat command for comparison:
And the list of open files:
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.
Code:
# 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)
Here's my output of your netstat command for comparison:
Code:
# 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:*
Code:
# 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)
| The Following User Says Thank You to jebba For This Useful Post: | ||
 |
|
2009-12-30
, 06:05
|
|
Posts: 124 |
Thanked: 47 times |
Joined on Aug 2008
@ Northern DFW
|
#3
|
WTB iptables 
__________________
Useful links for newcomers: New members say hello, New users start here, Community subforum, Beginners' wiki page, Maemo5 101, Frequently Asked Questions (FAQ)
NOTE: Most users should avoid the extras-testing and extras-devel app repositories.
I'm not really a Maemo/smartphone expert, but I can usually find my way around a *nix system. If I somehow manage to help you out, thanks are appreciated.
Useful links for newcomers: New members say hello, New users start here, Community subforum, Beginners' wiki page, Maemo5 101, Frequently Asked Questions (FAQ)
NOTE: Most users should avoid the extras-testing and extras-devel app repositories.
I'm not really a Maemo/smartphone expert, but I can usually find my way around a *nix system. If I somehow manage to help you out, thanks are appreciated.
| The Following User Says Thank You to jiiv For This Useful Post: | ||
|
|
2009-12-30
, 11:36
|
|
Posts: 456 |
Thanked: 1,580 times |
Joined on Dec 2009
|
#4
|
Originally Posted by jebba
Thanks for your answer!
So only 1900 and 2948 were remotely "open".
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
Originally Posted by jebba
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.
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.
Last edited by Wonko; 2009-12-30 at 11:45.
| The Following User Says Thank You to Wonko For This Useful Post: | ||
|
|
2009-12-30
, 11:43
|
|
Posts: 456 |
Thanked: 1,580 times |
Joined on Dec 2009
|
#5
|
Originally Posted by jiiv
Thanks for your answer as well!
WTB iptables
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.
|
|
2009-12-30
, 17:40
|
|
Posts: 124 |
Thanked: 47 times |
Joined on Aug 2008
@ Northern DFW
|
#6
|
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 if you're willing to risk it.
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 if you're willing to risk it.
__________________
Useful links for newcomers: New members say hello, New users start here, Community subforum, Beginners' wiki page, Maemo5 101, Frequently Asked Questions (FAQ)
NOTE: Most users should avoid the extras-testing and extras-devel app repositories.
I'm not really a Maemo/smartphone expert, but I can usually find my way around a *nix system. If I somehow manage to help you out, thanks are appreciated.
Useful links for newcomers: New members say hello, New users start here, Community subforum, Beginners' wiki page, Maemo5 101, Frequently Asked Questions (FAQ)
NOTE: Most users should avoid the extras-testing and extras-devel app repositories.
I'm not really a Maemo/smartphone expert, but I can usually find my way around a *nix system. If I somehow manage to help you out, thanks are appreciated.
|
|
2009-12-31
, 10:04
|
|
Posts: 456 |
Thanked: 1,580 times |
Joined on Dec 2009
|
#7
|
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:
mafw-dbus stuff:
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!
Last edited by Wonko; 2009-12-31 at 20:05.
Of course whenever changing or deleting something i assume you do have backups.
wappushd:
Code:
update-rc.d -f wappushd remove rm /etc/event.d/wappushd
Code:
mv /usr/lib/mafw-plugin/mafw-upnp-source.so backup/usr/lib/mafw-plugin/
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!
Last edited by Wonko; 2009-12-31 at 20:05.
| The Following User Says Thank You to Wonko For This Useful Post: | ||
|
|
2009-12-31
, 14:46
|
|
Posts: 3,841 |
Thanked: 1,079 times |
Joined on Nov 2006
|
#8
|
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.
__________________
N800/OS2007|N900/Maemo5
-- Metalayer-crawler delenda est.
-- Current state: Fed up with everything MeeGo.
N800/OS2007|N900/Maemo5
-- Metalayer-crawler delenda est.
-- Current state: Fed up with everything MeeGo.
|
|
2009-12-31
, 20:11
|
|
Posts: 456 |
Thanked: 1,580 times |
Joined on Dec 2009
|
#9
|
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.
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.
| The Following User Says Thank You to Wonko For This Useful Post: | ||
|
|
2010-01-02
, 11:29
|
|
Posts: 456 |
Thanked: 1,580 times |
Joined on Dec 2009
|
#10
|
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...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
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...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
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):
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