Performance analysis for Security Gateway R65 / R70 / R71 / R75

There is a nice article in SecureKnowledge which points out how to analyze the system performance. See sk33781 for details.

The article isn’t only about performance, but also gives good troubleshooting hints and explanations about values and possible errors (especially true for the memory section).

Really worth reading. And you should try to understand every part of the sk, if something is unclear, investigate. Knowing this stuff is important.

Tobias Lachmann

PCI Compliance - Disable SSLv2 and Weak Ciphers

According to section 4.1 of the the Payment Card Industry Data Security Standard (PCI-DSS) v1.2, merchants handling credit card data are required to “use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.”

What does this mean? In order to validate your PCI DSS compliance in this area you will need to ensure that your relevant server(s) within your PCI environment are configured to disallow Secure Sockets Layer (SSL) version 2 as well as "weak" cryptography. You are also required to have quarterly PCI security vulnerability scans conducted against your externally facing PCI systems. Without disabling SSLv2 and weak ciphers you are almost guaranteed to fail the scans. In turn this will lead to falling out of compliance along with the associated risks and consequences.

The SSLv2 Conundrum

Does your server support SSLv2?

How to test:

You will need to have OpenSSL installed on the system that you will perform the tests from. Once installed, use the following command to test your web server, assuming port 443 is where you're providing https connections:

# openssl s_client -ssl2 -connect SERVERNAME:443

If the server does not support SSLv2 you should receive an error similar to the following:

# openssl s_client -ssl2 -connect SERVERNAME:443

CONNECTED(00000003)

458:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

How to configure Apache v2 to not accept SSLv2 connections:

You will need to modify the SSLCipherSuite directive in the httpd.conf or ssl.conf file.

An example would be editing the following lines to look similar to:

SSLProtocol -ALL +SSLv3 +TLSv1

Restart the Apache process and ensure that the server is functional. Also retest using OpenSSL to confirm that SSLv2 is no longer accepted.

How to configure Microsoft IIS to not accept SSLv2 connections:

You will need to modify the system’s registry.

Merge the following keys to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]

"Enabled"=dword:00000000

Restart the system and ensure that the server is functional. Also retest using OpenSSL to confirm that SSLv2 is no longer accepted.

Those Pesky Weak SSL Ciphers

Does your server support weak SSL ciphers?

How to test:

You will need to have OpenSSL installed on the system that you will perform the tests from. Once installed, use the following command to test your web server, assuming port 443 is where you're providing https connections:

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP

If the server does not support weak ciphers you should receive an error similar to the following:

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP

CONNECTED(00000003)

461:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:

How to configure Apache v2 to not accept weak SSL ciphers:

You will need to modify the SSLCipherSuite directive in the httpd.conf or ssl.conf file.

An example would be editing the following lines to look similar to:

SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

Restart the Apache process and ensure that the server is functional. Also retest using OpenSSL to confirm that weak SSL ciphers are no longer accepted.

How to configure Microsoft IIS to not accept weak SSL ciphers:

You will need to modify the system’s registry.

Merge the following keys to the Windows registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128]

"Enabled"=dword:0000000

Restart the system and ensure that the server is functional. Also retest using OpenSSL to confirm that weak SSL ciphers are no longer accepted..

At this point have your Approved Scanning Vendor (ASV) scan your external facing PCI environment to validate. Making the above changes should cause the ASV scans to not tag and fail you on the following vulnerabilities:

• SSL Server Supports Weak Encryption
• SSL Server Allows Cleartext Encryption
• SSL Server May Be Forced to Use Weak Encryption
• SSL Server Allows Anonymous Authentication

Steve

DDoS Analysis Process

http://isc.sans.edu/diary/DDoS_Analysis_Process/10408

Remote Captures using Wireshark and rpcapd (by Tony Fortunato)

Befriending Windows Security Log Events

When a call starts off with "I think we've had an incident" or "something isn't right" actual proof of an event or incident has really occurred is a must*. If it's some odd happening on Windows, then it's time to look at the Windows event logs. Windows has three standard event logs: application, system and security. The one most security folks need to keep an eye on is the security event log.

Some questions to ask or ponder about your Windows security logs

• Do you review or monitor them?
• How big are the log files?
• What happens when the log file are full?
• Do you know if security audit policies in place?
• Do you have different audit policies for certain systems?
• Are all your machines using the same time reference?
• Can you recognize the event ID that could mean trouble?

Each company has its own policies and procedures on how their systems are designed built, configured and managed, but as incident responders we should know these basic details about the security event log.

A common stumbling block for security teams is actually viewing the security logs on other computers. Access to the security logs, by default, is only to a user with local admin right on the machine. There is a nifty way to allow security staff to view them, while not give them full admin access to the remote machines and is recommended by Microsoft [1]. This avoids upsetting the Windows admin team - who are by now still deploying the latest Ms patches and thus pretty busy.

Microsoft has produced a number of helpful guides on how to configure and apply polices [2 & 3] and there are a large number of other references out there. Working with the Windows admin team help them identify some of the warning signs that appear in the security logs, such as multiple account lock outs, brute force account guessing attacks and what certain event ID are [4]

Let's say you have all the right audit policies in place and can view the security logs, but you're attempting to piece together an attack over 50 machines. Just viewing that many separate Windows event logs will make you go crazy. Jason Fossen, author of SANS Windows track, has a wonderful script [5] to convert event logs in to CSV files. Use tools, such as trusty old Ms Excel, to parser the data from CSV files and correlate them in to events timelines. This makes spotting trends, events or incidents much easier as you can look at the combined data and even turn it in to graphs.

By having the correct information logged and access to the security logs it should take the guessing out of whether a dozen accounts have been locked out is a co-incidence or an actual security incident.

If you have any other suggestions or advice on using the Windows security logs, please feel free to add a comment.

[1] How to set event log security locally or by using Group Policy in Windows Server 2003 for non-admins to access them:

http://support.microsoft.com/kb/323076

[2] Configuring Audit Policies Windows 2000/2003:

http://technet.microsoft.com/en-us/library/dd277403.aspx

[3] Advanced Security Auditing in Windows 7 and Windows Server 2008 R2:

http://social.technet.microsoft.com/wiki/contents/articles/advanced-security-auditing-in-windows-7-and-windows-server-2008-r2.aspx

[4] My favourite place to find what Security Event ID mean:

http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/Default.aspx

[5] Dump Windows Event Logs to CSV Text Files

http://blogs.sans.org/windows-security/2009/06/30/dump-windows-event-logs-to-csv-text-vbscript/

Recommended Event Logs sizes in windows:

http://support.microsoft.com/kb/957662

How Not to Respond to a Security Incident

Finding out that your organization's computer defenses has been breached is a stressful experience. Many are unprepared to deal with such situations, and some have a false sense of security as the result of impractical incident response plans.

Having read about the recent PlentyofFish.com security incident, as described by its founder and a more measured perspective from Brian Krebs, I was inspired to create this short list of what not to do when responding to a security incident:

• Don't drive the incident response (IR) team to work for several days without sleep. People's ability to conduct cognitive tasks is severely diminished when they are sleep-deprived. You may need to pull a one-nighter initially, but after that, stagger people's response tasks so they can get some rest.
• Don't make rush decisions when deciding upon the initial incident response steps. It is OK to take some time to assess the situation before taking action to avoid making mistakes. Of course, you need to balance this with waiting too long before making decisions regarding the next steps.
• Don't immediately attribute the source of the breach to people, companies or countries without conducting a thorough investigation. In particular, don't assume that the entity who notified you of the breach of a vulnerable condition is the entity responsible for the incident.
• Don't attempt to hire the entity who notified you of the breach to assist with incident response, unless there's truly no one else qualified for the job. They might not be responsible for the breach, but it's best to control the situation where you might accuse them of extortion. Also, there's no reason to encourage ambulance-chasing practices.

For more recommendations on what not to do when someone reports an incident, as well as for tips on what to avoid doing when reporting an incident, see our earlier diary Incident Reporting - Liston's "How-To" Guide.

In addition, here are a few Emergency Incident Response steps from Mandiant, which are a good starting point for responding to a security incident. I also put together a few incident response cheat sheets:

• Initial Security Incident Questionnaire for Responders
• Network DDoS Incident Response Cheat Sheet
• Security Incident Survey Cheat Sheet for Server Administrators
• Critical Log Review Checklist for Security Incidents

-- Lenny Zeltser http://blog.zeltser.com/

Checkpoint- Best practice

Level: - Intermediate
Platform : - checkpoint R61, R62, UTM, VPN-1, Nokia IP60,Nokia IP260,Nokia IP290,Nokia IP390,Nokia IP560,Nokia IP690,Nokia IP1220,Nokia IP1260,Nokia IP1280,Nokia IP2255,Nokia IP2450
Reference : - Checkpoint.com
Author : - Dinesh Aggarwal

Here we are going to discuss some best practices to be followed while creating a rule base in checkpoint firewall. By following these best practices you can expect a better performance and easy management from checkpoint firewall.Let’s start by identifying some of the general best practices that should be followed for creating an powerful rulebase

Best practices for good Rulebase

1) The firewall rulebase should be as simple as possible. The fewer rules you have, the more efficient and less error prone the rulebase will be.
2) Avoid using "Any" in the service field.
3) Use a network object instead of many workstation node objects.
4) Use groups to gather source, destination or services.
5) Anti spoofing should be configured for all the firewall interfaces.
6) Place the most commonly accessed rules on top of the rulebase. This will improve performance and make the firewall more efficient. Firewall-1 searches the rulebase in sequential order. The first rule matching a connection is applied, not the rule that matches best.

This checkpoint best practices rules is surely going to result in better firewall performance. This rule is application to any firewall weather its cisco ASA, PIX, checkpoint, Netscreen or any other firewall.

7) Use good naming conventions to represent network objects (hostname_ip address is a good naming scheme) and services.

8) Implement the "Stealth rule" to block and track connection attempts to the firewall module.

9) Prefer "Reject" to "Drop" for some services. Services such as "ident" should be rejected to allow better application performance.
10) Implement the "Cleanup" rule at the bottom of the rulebase to block and log all traffic. Firewall-1 by default does not log traffic that is dropped. By having the "Cleanup" rule, logging can be turned on for blocked connections.

Note: - When a Drop action is taken, the sender is not notified.

Following table describes what happens when a Reject action is taken.

Difference between Reject and Drop
service	Reject
TCP	The sender is notified.
UDP	Sends an ICMP port unreachable error to the sender.
other	Same as Drop.

11) Do NOT use the domain object in the rulebase. Domain objects may cause performance bottlenecks.
12) To avoid being flooded by logging of broadcast traffic such as bootp and NBT, create a rule to drop the packets without logging. Ident is a service used by SMTP protocol to try to identify the email clients. By "reject" the service but not "drop" it, the SMTP application will gain performance since it doesn't have to wait for the ident connection to timeout.
13) Disable Decrypt on accept property if not using VPN

That’s it, these are the basic rules for managing an effective rulesbase in checkpoint