Sample Blackberry Enterprise Server Policy

January 11, 2009 / / No comments

The policy below provides an example of security measures that should be taken towards protecting a corporate network from the threats presented by mobile devices.

These configurations and options should be “taken with a grain of salt”; as a guideline to what features should be set to mitigate the risk of smart-phone being used as un-metered gateways into the corporate network.

The 5-step process should be put into action to address security issues related to smart-phones.

  1. Identify threats and vulnerabilities.
  2. Measure the risk.
  3. Determine what control should be put in place.
  4. Implement industry best practices and standards.
  5. Develop and communicate policy and awareness.

THE SAMPLE POLICY:

Device-Only Items:

Password Required: True
Allow Peer-to-Peer Messages: False (This can be set to be audited if enabled)
Minimum Password Length: 4
User Can Disable Password: False
Maximum Security Timeout: 5
Maximum Password Age: 180
User Can Change Timeout: False
Password Pattern Checks: (used to enforce complexity in passwords)
Enable Long-Term Timeout: True
Allow SMS: False (These can be set be audited if enabled)
Enable WAP Config: False

Desktop-Only Items:

Show Application Loader: False
Force Load Count: 0
Auto Backup Enabled: True
Auto Backup Include All: True
Do Not Save Sent Messages: False

Common Policy Group:

Lock Owner Info: Lock Information Text
IT Policy Notification:
Set Owner Info: (If found please return to message……)
Disable MMS: True

Password Policy Group:

Set Password Timeout: 20
Set Maximum Password Attempts: 5
Suppress Password Echo: True
Maximum Password History: 3

Security Policy Group:

Disable Untrusted Certificate Use: True
Disabled Revoked Certificate Use: True
Disable Peer-to-Peer Normal Send: True
Disable Key Store Low Security: True
Certificate Status Cache Timeout: 1
Disallow Third Party Application Download: True
Force Lock When Holstered: True
Allow Third Party Apps to Use Serial Port: False
Disable Invalid Certificate Use: True
Disable Weak Certificate Use: True
Disable Key Store Backup: True
Certificate Status Maximum Expiry Time: 4
Disable Stale Status Use: True
Disable Cut/Copy/Paste: True
Disable Radio When Cradled: True
Disable Forwarding Between Services: True
Disabled Unverified CRLs: True
Disable 3DES Transport Crypto: False
Disable Persisted Plain Text: True
Disable Unverified Certificate use: True
Disable IP Modem: True
Allow Smart Card Password Caching: False

SMIME Application Policy Group:

SMIME Minimum Strong RSA Key Length: 1024
SMIME Minimum Strong DH Key Length: 1024
SMIME Minimum Strong ECC Key Length: 163
SMIME Allowed Content Ciphers: AES (256-bit), Triple DES
SMIME Minimum Strong DSA Key Length: 1024

Memory Cleaner Policy Group:

Memory Cleaner Maximum Idle Time: 10
Force Memory Cleaner When Holstered: True

TLS Application Policy Group:

TLS Disable Weak Ciphers: Disable weak ciphers
TLS Disable Untrusted Connection: Disable untrusted connections
TLS Minimum Strong RSA Key Length: 1024
TLS Minimum Strong DH Key Length: 1024
TLS Minimum Strong ECC Key Length: 163
TLS Disable Invalid Connection: Disable invalid connections
TLS Minimum Strong DSA Key Length: 1024
TLS Device Side Only: False

WTLS Application Policy Group:

WTLS Disable Weak Ciphers: Disable weak ciphers
WTLS Disable Untrusted Connection: Disable untrusted connections
WTLS Minimum Strong RSA Key Length: 1024
WTLS Minimum Strong DH Ley Lenth: 1024
WTLS Minimum Strong ECC: 163
WTLS Disable Invalid Connection: Disable invalid connections

Browser Policy Group:

Allow BIS Browser: False

PIM Sync Policy Group:

Disable PIN Messages Wireless Sync: False
Disable SMS Messages Wireless Sync: False

Desktop Policy Group:

Desktop Password Cache Timeout: 10
Desktop Allow Desktop Add-ins: False
Desktop Allow Device Switch: False

Locking Down The Blackberry Network

Auditing SMS and PIN Messages on a BES

[ad]

Category: Security / Tags: , , , , ,

Locking Down The Blackberry Network

January 11, 2009 / / No comments

Early last year India threatened to discontinue Blackberry service if Research In Motion (RIM), the company behind the Blackberry did not allow the Indian Government to monitor the Blackberry network traffic raising serious security concerns. Here are a few articles from PCWorld, InfoWorld, and CNet.

Now president-elect Barack Obama vows to keep his Blackberry despite hacking fears and concerns by the Secret Service.

This will not only be a headache for the Secret Service but its pretty likely that hacking attempts towards the RIM network will increase exponentially.

Generally people just don’t think about the risk that a smart-phone poses, specially if its connected to a Blackberry Enterprise Server. How could my phone be a risk to anyone? Well a smartphone is not just a phone, but rather a miniature computer that is not just capable of making calls but it also an un-metered gateway into the corporate network.

In order to understand what actions to take to protect a smart-phone, in particular the Blackberry you have to understand how it works and how it interacts with the Blackberry Enterprise Server.

Vulnerabilities:

  • Lack of authentication
  • Lack of encryption
  • Lack of mobile code execution controls
  • Difficult to enforce controls
  • Peripheral devices introduce additional vulnerabilities
  • Infrastructure vulnerabilities service specific operating systems, platforms, applications, etc.
  • Small size is prone to theft and loss
  • All devices may not be corporate owned
  • Multiple configurations of the Blackberry Enterprise Server (BES) architecture
  • Limited centralized update mechanisms
  • Limited IT/CIO Control

Sources of Recommended Controls and Security Guidelines:

  • The Vendor (Microsoft, Treo, RIM, etc.)
  • SANS (www.sans.org)
  • NIST has a great publication
  • Other existing guidelines
  • 3rd Party Solutions often fill the gaps

Once the vulnerabilities have been identified we proceed to implement controls and audits.

Controls:

Controls will include policies, standards, practices, procedures, guidelines, awareness, authentication, encryption, and asset management.

Audits:

Once the scope has been defined, allow to review the implementation of policies between the BES, servers, Blackberry devices, and Blackberry desktop agents. Audits also allow the review of configuration and options to ensure that security is not just available but implemented. Additionally configurations pushed down to end devices need to be audited as well.

The infrastructure design and configuration of network components (firewalls, routers, switches, VLANs, etc.) will need to be audited as they play an intricate part of the overall security of the system.

Risk Assessment:

Although this requires additional resources and expertise, its a must in certain environments like corporate or government. A risk assessment will identity security vulnerabilities and provide a 2nd chance to identify all “assets”.

Once this has been completed, validating the risk by performing an “ethical hack” will remove any uncertainty by proving the vulnerabilities identified actually exist.

Conclusion:

Providing documentation on the findings is vital. The documentation required will contain an executive summary, action items and details for system administrators, and a clear and concise report with both the good and the bad findings.

A couple of things that should not fall through the cracks are ensuring that the corrective actions are implementable within the organization and the next audit scheduled.

Sample Policy:

Sample Blackberry Enterprise Server Policy

[ad]

Category: Security / Tags: , , , , , , , , , ,

Checkpoint Firewall-1 and The SIP Protocol

December 30, 2008 / / 7 comments

You have an asterisk based VoIP phone system sitting on an internal network and you are trying to establish connectivity to a SIP-based trunk provider.

You configure a static NAT entry 1-to-1 for the asterisk box and allow the SIP (udp 5060) through the firewall, but SIP registration fails constantly.

While troubleshooting the issue you observe some strange behavior in the NAT. The SIP registration packet (source port 5060, destination port 5060) reaches the firewall, changes the source port at the interior interface and to another high port at the exterior interface, but the answer packet will not be translated correctly.

Fw monitor shows the following:

a.b.c.d is the internal (private) IP address
n.n.n.n is the external (public) IP address
w.x.y.z is the SIP providers IP address

eth1.10:i[502]: a.b.c.d -> w.x.y.z (UDP) len=502 id=0

UDP: 5060 -> 5060

eth1.10:I[502]: a.b.c.d -> w.x.y.z (UDP) len=502 id=0

UDP: 17973 -> 5060

eth0:o[502]: a.b.c.d -> w.x.y.z (UDP) len=502 id=0

UDP: 17973 -> 5060

eth0:O[510]: n.n.n.n -> w.x.y.z (UDP) len=510 id=0

UDP: 40625 -> 5060

eth0:i[404]: w.x.y.z -> n.n.n.n (UDP) len=404 id=5495

UDP: 5060 -> 40625

eth0:I[398]: w.x.y.z -> a.b.c.d (UDP) len=398 id=5495

UDP: 5060 -> 17973

eth1.10:o[398]: w.x.y.z -> a.b.c.d (UDP) len=398 id=5495

UDP: 5060 -> 17973

eth1.10:O[398]: w.x.y.z -> a.b.c.d (UDP) len=398 id=5495

UDP: 5060 -> 17973

As it can be seen the reply does not get translated back as it should to destination port 5060 and thus will not be accepted by the asterisk box.

To understand and be able to solve the current dilemma its imperative that we explore why the Checkpoint Firewall is behaving this way and preventing our Asterisk box from registering the SIP trunk.

The Stateful Inspection Technology implements all the necessary firewall capabilities at the network level. The FireWall-1 Inspection Module accesses and analyzes data derived from all communication layers. The FireWall-1 Security Server enables the system administrator to define a Security Policy on a per-user basis.

The Inspection Module is located between the Data Link (IP-Stack) and Network Layer (Device Driver). Authentication and Content Security are provided by a suite of FireWall-1 Security Servers, running at the application layers.

The Security Servers enforce Content Security and Authentication for a particular service. Defining a protocol type within an associated service invokes specific protocol handlers enabling a higher level of security by parsing the protocol, and a higher level of connectivity by tracking dynamic actions and these checks are mostly overridden by SmartDefense checks.

So to recap. As the data moves up the OSI layers, it can be intercepted by both the Security Servers and SmartDefense. In this particular case the protocol definition which invokes specific protocol handlers are modifying the reply SIP packets during translation using a random port and not the UDP 5060 asterisk is expecting.

Modifying the Protocol Type on the udp-sip service under the “Advance UDP Services Properties” from SIP_UDP to None will solve the issue.

[ad]

Category: Security / Tags: , , , , ,

Anonymizing Web Traffic

December 19, 2008 / / No comments

I recently wrote about Secure Internet Browsing and the need for it. Not too long thereafter I found an instance were you might want to make sure that your traffic is anonymous so I will take a closer look at “Onion Routing” and “Tor”.

Tor is a software project that helps you defend against traffic analysis, a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security. Tor protects you by bouncing your communications around a distributed network of relays run by volunteers all around the world: it prevents somebody watching your Internet connection from learning what sites you visit, and it prevents the sites you visit from learning your physical location. Tor works with many of your existing applications, including web browsers, instant messaging clients, remote login, and other applications based on the TCP protocol.

There are several ports of the “Tor” project out there and after evaluating several of them the better one seems to be the Vidalia-Tor-Privoxy Bundle here.

There are several components in this package that warrant explanation.

The Vidalia application is a GUI program to access Tor.

Then we have Tor which uses cryptography in a layered manner working at the TCP stream level as opposed to using application layer solutions like anonymous proxies. Is important to note that Tor (onion routing) is designed to anonymize traffic and does NOT secure it. Additionally there could be some weaknesses that I will address later on DNS leaks, IP address leakage and cookie leakage.

The next component of the bundle is Privoxy which is a non-caching web proxy with advanced filtering capabilities for enhancing privacy listening on port TCP 8118. Privoxy receives requests from the web browser and then forwards web traffic to through the Tor network for anonymity. Tor sits on your PC listening on port TCP 9050 ready to scrub the traffic clean from traffic analysis.

Finally there is TorButton (add-on) which enables Firefox users to enable/disable the use of Tor by the browser with just one click.

I chose not to select this during the install since it has mixed reviews due to bugs and decided to go with a much better add-on called QuickProxy.

There is little you need to do to the default install. You should see Privoxy running on your “Systray” as a blue “P” icon and next to it you should see a “green onion” icon. Clicking on the “green onion” will bring up the Vidalia Control Panel so you can connect to the Tor network.

The last thing that needs to be done is to configure your browser to point to the local proxy (Privoxy) running on your PC as shown below.

Click on the Image to enlarge.

At the button of your Firefox browser you should see a Green/Red “P” (QuickProxy) which determines if the proxy is selected or not.

Finally to test if your browser is anonymized. Make sure your Firefox status bar shows the Red “P” and go to http://www.ipchicken.com to determine your IP address. Click on the “P” icon and watch it turn to green and then proceed to refresh your browser and your IP address should change to something random.

Now lets look at the weaknesses starting with DNS leaks.

The Problem: When your applications connect to servers on the Internet, they need to resolve hostnames that you can read (like www.torproject.org) into IP addresses that the Internet can use (like 209.237.230.66). To do this, your application sends a request to a DNS server, telling it the hostname it wants to resolve. The DNS server replies by telling your application the IP address.

Clearly, this is a bad idea if you plan to connect to the remote host anonymously: when your application sends the request to the DNS server, the DNS server (and anybody else who might be watching) can see what hostname you are asking for. Even if your application then uses Tor to connect to the IP anonymously, it will be pretty obvious that the user making the anonymous connection is probably the same person who made the DNS request.

Using Tor in concert with Privoxy pretty much takes care of this, since its a socks4a-capable HTTP proxy but if you intend to anonymize other non-SOCKS aware applications (for instant messaging, Jabber, IRC, etc), that are connected directly to Tor using SOCKS 4 of SOCKS 5 you will be prone to DNS leaks and not be as anonymous as you might think.

The Tor project is working to resolve this in their next release by including a DNS resolver that will send queries over the mixed network.

Alternatively you can modify how Firefox performs DNS lookups which is generally done by handing down the request to the operating system.

To force DNS requests into the Tor channel, visit the special URL about:config and find the key network.proxy.socks_remote_dns. Set it to true

Now what about cookie leakages.

Websites are allowed unless specifically told otherwise to store bits of information on your PC, to determine its you the next you visit. This allows for a more fluent and pleasant experience on any site you log into.

Now when you want to disassociate yourself from your identity it presents a problem. When you visit a website that has already placed a cookie on your computer and then you visit it again with your Tor identity, the website can determine that even though the originating IP addresses are different, it is in fact the same person. Making sure you have a second Firefox account or have erased your cookies becomes paramount to maintain your identities separate.

Additionally you have to worry about cross-site cookies which can be solved by allowing cookies for the originating website only, and have them kept only until Firefox is closed as seen below.

Click on the Image to enlarge.

Finally a word on security.

As Tor relies on a network of people around the world serving as relays to the traffic, you can easily see how a particular request to a website sending over a clear channel a username/password combination might be problematic. Someone actually listening (Tor Relay) to the traffic relayed through them will be able to pick up this information.

Even worse scenario would be someone phishing for information at an exit node and pretending to be a website you are visiting.

The most simple solution for this is to only use SSL and forcing Firefox to tell you if you are about to send information to an un-encrypted website.

Turn on warnings for secure and insecure sites. At the Firefox configuration URL about:config, find the keys beginning with security.warn_. Set all of them to true, except for the once ending in .show_once, which should be set to false. Then set security.warn_entering_secure to false — you really don’t need to be alerted to that.

If you visit a site and the browser tells you that the SSL certificate may be invalid, don’t trust it!

[ad]

Sources:

Wikipedia

The Tor Project

Category: Technology / Tags: , , , , , , , , , , , ,
« Older Entries   Recent Entries »
Wordpress Theme by ThemeZee