All About Symbian - News from the Symbian Ecosystem...

Once and for all, you don't need a firewall!

Published by Steve Litchfield at 12:36 UTC, April 21st 2006

In an attempt to flesh out my dismissal of the need for a separate third party firewall  utility for Symbian OS, I thought a little testing was in order. I grabbed the nearest S60 phone (a Nokia 6630) at random, pointed at the Internet's leading port tester/prober and sat back and watched. How did Symbian OS do? Updated: also tested Nokia 9500 over W-LAN.

As expected, and confirming my similar tests from a few years ago using Series 80 on the Nokia 9210i, Symbian OS is 100.00000% inherently stealthy when online. Look at the screenshots below, taken when online on the latest version of Shields Up! Symbian OS (in this S60 2nd edition, OS 8 guise) achieved a perfect score, with all 1056 tested TCP/IP ports resisting all attempts at unwanted communication from the outside world. The column of green squares goes upwards for all 1056 ports by the way, and it's green all the way up to square/port 1.

Symbian OS firewall testing screenshot Symbian OS firewall testing screenshot Symbian OS firewall testing screenshot Symbian OS firewall testing screenshot

If you want to try the experiment for yourself, just head over to http://grc.com/ and click on Shields Up!, then choose to 'Probe all Service Ports'. The test will take a couple of minutes max. The longest wait is for your mobile web browser to render a page with 1056 little graphic squares 8-)

Update: after comments about some of the stealthiness being because I was connecting over GPRS, with my network provider's systems acting as a firewall, I tried my Nokia 9500, online over W-LAN, on the same Shields Up! test. As you can see below, the ports all check out perfectly again, with no weaknesses, although the Shields Up! test did report that the 9500 was responding to Ping requests. Not a security problem in itself though.

On the 9500 over Wi-Fi

On the 9500 over Wi-Fi 

So, I repeat. Symbian OS doesn't seem to have any need whatsoever of a firewall. Security firms, please take note and stop trying to scare us (and make money in the process) again. This has been a public service announcement.

Steve Litchfield, for AAS and 3-Lib

 

Share This (Digg, del.icio.us, Facebook, etc.)

Categories: Industry, Editorial Thoughts
Platforms: Series 60, Series 80, General, N-Gage

News Discussion

Rafe
I'm not so 100% convinced. I just did the same test with Windows Xp with the Firewall turned off and it gave it the all clear... I'm fairly sure using a Firewall with Windows XP is recommended.

I thought part of the point of Firewalls was to control out going applications. i.e. control which applciations can have Internet access.

I'm no expert on such things, but would the same not apply to a Symbian phone?
jrmt
How did you test access to your phone? If you're using GPRS or 3G, chances are you're allocated an IPv6 address, and this is likely behind a NAT IPv6->IPv4 device. This effectively is an "incoming" firewall. It would have been better to "nmap" your phone's IP address, as this will also fingerprint the device to see if it really is SymbianOS answering nmap TCP, UDP or ICMP packets and not a NAT device in the middle.

In reply to Rafe's comment:
> I thought part of the point of Firewalls was to control out going applications. i.e. control which applciations can have Internet access.

Not traditionally (i.e. in the UNIX world where firewalls were first invented). They are used for incoming access mainly, although these days in universities and elsewhere often outgoing port 25 (smtp) is firewalled off to stop viruses sending spam. PlatSec capabilities in v9.x or one-shot granting of capabilities is really the outgoing "firewall" for Symbian. If your application doesn't have the "NetworkServices" capability when signed, or the user doesn't allow access to the network via the GUI, then you won't be able to use the network from that particular application. ("This capability controls access to ... all IP transport protocols", PlatSec book page 223)
stuclark
Surely most of the point here is that a phone isn't an IP based device, and doesn't have the same 65000 IP ports available to be hacked.

You can't telnet into a phone on port 23, you can't SMTP into it on port 25, you can't even try accessing it on port 80 UDP (an internet Ping) - how is a traditional firewall even worthwhile on a phone?
jrmt
Stu says:
> Surely most of the point here is that a phone isn't an IP based device, and doesn't have the same 65000 IP ports available to be hacked.

Absolutely it is. All 65535 ports are valid in SymbianOS, same as for any TCP/IP connected device. By default, I wouldn't expect anything to be listen()ing on any of them, so a SYN packet would get reset ("connection refused") by default.

> You can't telnet into a phone on port 23, you can't SMTP into it on port 25, you can't even try accessing it on port 80 UDP

There's no reason why you couldn't run a (small) webserver on port 80 on your phone. But whether you would have incoming network access to it via 3G/GPRS (e.g. because of NAT) is debatable. But SymbianOS supports running servers listening to the network, and is fully IP capable (both IPv6 and IPv4). No reason why a phone couldn't be part of a p2p network in future, if the data tariffs were low enough.

> 80 UDP (an internet Ping)

ping is ICMP, not UDP, and doesn't have port numbers associated with it. HTTP usually uses TCP port 80
Rafe
Ah thanks for the cinformation jrmt (and the scary network related TLAs!).

I can see Symbian 9 is good thing from another security view point then... (although I guess this stuff has been around for a while for J2ME apps). So can anyone tell me if there would ever be a need for a Firewall?

With WiFi devices it is presumably possible to have a device that is connected a lot of the time? e.g. the Eseries connecting over WiFi to a VOIP PBX or similar. That said I've never quite understood why windows was insecure and needed a firewall (I mean why would you be accepting anything incoming unless you explcitly needed to?). I do understand the need for it on some servers... although even then I would have thought it should be possible to secure things (i.e. limit which ports were accepting things / limit where thing are coming from).
FRiC
Quote:
Originally Posted by Rafe
That said I've never quite understood why windows was insecure and needed a firewall (I mean why would you be accepting anything incoming unless you explcitly needed to?). I do understand the need for it on some servers... although even then I would have thought it should be possible to secure things (i.e. limit which ports were accepting things / limit where thing are coming from).
Windows doesn't automatically allow all incoming connections. The problem is when it gets attacked and your PC gets infected without your knowing. Having a firewall and a virus scanner in place will reduce the problem.

There are also different types of firewalls. The type that most people on their home computers are personal firewalls and can filter either by ports or by application. To keep this on topic, an application that filters out unwanted calls or SMS can be called a firewall.

I work in a very large company with a lot of computers and smart phones, and I can tell you all you want about virus infections, on both computers and phones...
slitchfield
{I just did the same test with Windows Xp with the Firewall turned off and it gave it the all clear...}

Err... in that case you've got another security system in place. And if you really had turned your firewall off for a few minutes on an unprotected Windows system you'd now have half a dozen nasty worms sitting on your hard disk.

People, never EVER turn your Windows firewall off for any reason whatsoever. A typical online PC (or any other net device, including a smartphone) gets hit tens of thousands of times a day.

In response to the point that my GPRS smartphone might have been (unwittingly) behind a firewall within my network, that's true I guess, but the end result is the same - a firewall simply isn't needed on the mobile device.

Steve Litchfield
stuclark
Quote:
Originally Posted by jrmt
Absolutely it is. All 65535 ports are valid in SymbianOS, same as for any TCP/IP connected device. By default, I wouldn't expect anything to be listen()ing on any of them, so a SYN packet would get reset ("connection refused") by default.
Sorry, it was late, and my comment didn't come accross as I meant it to. What I was alluding to is that *by default* a phone won't be set to listen on it's IP ports - not unless you've got some form of server software installed. (be that web server, smtp, telnet etc)

The point that in OS9 it is much harder to install an application without the user realising what it is, and even then, it will have to be symbian signed to be able to access any of the network fucntionality within the phone, almost renders a firewall obselete before you even start to think about threars.

Quote:
Originally Posted by jrmt
ping is ICMP, not UDP, and doesn't have port numbers associated with it. HTTP usually uses TCP port 80
My bad, I meant ICMP :dontknow:
CJackel492
Quote:
Originally Posted by slitchfield
I grabbed the nearest S60 phone (a Nokia 6630) at random,
Why test a S60 phone and post the information on the S80 news forum?

Carl,
puterman
Quote:
Originally Posted by stuclark
The point that in OS9 it is much harder to install an application without the user realising what it is, and even then, it will have to be symbian signed to be able to access any of the network fucntionality within the phone, almost renders a firewall obselete before you even start to think about threars.
No, an app doesn't have to be Symbian Signed to be able to access network functionality. The user will get a warning when installing a self-signed app which uses network functionality, but that's it. I'm sure some network functionality requires Symbian Signing, but not all of it.
slitchfield
{Why test a S60 phone and post the information on the S80 news forum?}

Because this discussion is, of course, totally relevant to the 9300 and 9500 as well.

Steve
Masamune
If you think the scare-mongering is bad now for GPRS & 3G connections, wait until the WiFi enchanced phones start to become available.
Rafe
FYI: The reason I was safe when turning off the Windows Firewall was because I wa sitting behind a router that I think has NAT functioanlity / built in firewall.

Interesting that filtering SMS / calls might be considered a firewall. Clearly that might be useful for some people.

I suppose it is the same issue with anti-virus for Symbian OS 9 - peace of mind to have a complete system and not under estimate users ability to much things up!
jrmt
So can anyone tell me if there would ever be a need for a Firewall?

It's unlikely you'd need one, since a phone usually wouldn't be running listening servers, and your telco will probably NAT/firewall all 3G-derived IP addresses.

With WiFi devices it is presumably possible to have a device that is connected a lot of the time? e.g. the Eseries connecting over WiFi to a VOIP PBX or similar.

With WiFi it's more of a risk. It would be quite fun to have an ssh process and mini-shell running on your phone (perhaps written in Python first, and C++ later?). Or an rsync-daemon, then you could sync files to/from your laptop over WiFi to your phone. Or how about a mini web-server running on your phone? That would be quite cool. It should be quite easy to write. There are lots of potential uses.

That said I've never quite understood why windows was insecure and needed a firewall (I mean why would you be accepting anything incoming unless you explcitly needed to?).

It's a combination of things. Firstly, Microsoft left too many servers running in the default install in Win2k. (I think WinXP SP2 turns off all servers unless configured). So you have Windows listening on ports 137, 138, 139 for SMB for sharing, and various RPC ports, etc. Secondly, if any of these have potential for buffer overflows (due to programmer error), then you can compromise the machine, and if running as admin, you own the machine. Microsoft is gradually learning that servers should be run with the least privilege possible. They also didn't audit the code sufficiently before release to spot potential buffer overflows, nor did they use safer C++ string classes for input which are bounds-checked.

It is possible to run machines safely without firewalls but you really only want to run one or two listening servers (e.g. just ssh and maybe Apache) and then keep the machine patched and updated reguarly, etc.
fig7
Quote:
They also didn't audit the code sufficiently before release to spot potential buffer overflows, nor did they use safer C++ string classes for input which are bounds-checked
Symbian strings and buffers include bounds checking. A buffer overflow will kill an application instantly so buffer overflows are much less of a problem on Symbian OS.
deadkenny
Relying on grc.com for a measure of security is risky anyway. Try real security sites and applications that are industry recognised. Self proclaimed expert Mr. Gibson can lul you into a false sense of security and/or spread unecessary fear and panic.
dchky
There is one reason I would love to see a firewall with user customizable rules, simply the ability to filter outbound connections. If an application wants to phone home each time there is an active network connection, I don't want it. Bad enough having to pay huge prices for gprs, let alone applications sending a couple hundred kilobytes of who knows what back to its maker. Profimail, you listening?!

If an app wants to use the network without full disclosure, it's spyware in my book.
Unregistered
dchky hits the nail square on the head there.

I want a firewall on my phone, with configurable rules for outgoing connections, for exactly the same reasons. And exactly the same application, as it happens.

Bad Profimail! Go and stand in the corner until you've learned to behave!

Full thread: 18 Comments / Post New Comment

Close
  • Social Web
  • About

You can use this widget to send bookmarks or notes for this page to your favourite sharing / bookmarking service. You will need an account at mnay of these services and may need to log in to use them.

Copyright Notes || Contact Us || Privacy Policy