| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| Could someone please clarify the upgrade question. actualtest says question 17 the answer is A, where as unicert say its B. I also think that question 40 - loadsharing the answer should be E. load sharing based on IP address and port. Could someone post all the corrected answers, the would save time for everyone. Thanks Last edited by chipone; 2007-11-03 at 04:28. |
| |||
| Hiya, I certainly think the answer is A (according to the CheckPoint pdf) Upgrade the Management High Availability Servers 1. Synchronize the Standby SmartCenter Servers (SCSs) with the Active SCS by selecting Synchronize in the Policy > Management High Availability window. 2. Upgrade all the SCSs in the organization. 3. Login to SmartDashboard via the Active SCS. For each Standby SCS, change the software version in Check Point Products listbox of its network objects window. 4. Synchronize the Standby SCSs with the Active SCS. The synchronization status is expected to be collision. This occurs on account of the Upgrade operation. 5. Make sure that you select the Active SCS as the dominant SCS, in order that all the Standby SCSs will be overwritten. Once again, synchronize the remaining Standby SCSs to the Active SCS. I hope this helps. |
| |||
| Thanks for clarifying the question. I will start reading the PDF's in more detail now, just been using the student handbook and test questions. Has anyone taken the exam in the last month. |
| |||
| Maybe someone can clarify this question You receive an alert indicating a suspicious FTP connection is trying to connect to one of your internal hosts. How do you block the connection in real time and verify the connection is successfully blocked? A - Highlight the suspicious connection in SmartView Tracker > Active mode. Block the connection using the Tools > Block intruder menu. Use the Active mode to confirm that the suspicious connection does not reappear. C - Highlight the suspicious connection in SmartView Tracker > Active mode. Block the connection using Tools > Block intruder menu. Use Active mode to confirm that the suspicious connection is dropped. Obviously one of these is correct, because this can only be done in Active mode - but how can you verify that the connection has been successfully dropped? They say A, but the answers aren't very clear and I've also seen the answer set as C. I would have thought that when you block a connection, it disappears from the Active Log view - so A and C could be correct. |
| |||
| I would have thought the answer would be A. When you came to block the connection you could have set the block for a period of time,i.e. one minute. As it only displays active connections the connection this could be re-established after one minute or you may find the hacker trying on another source address which you would want see. Like alot of checkpoint answers the questions aren't cut and dry. |
| |||
| You're so right there - some answers can be obvoius, but others could be a lucky guess.... While we're on a role, how about this one..... Q. Regarding a SMTP resource - mail seems to be slow and delivered late - what should be done to improve throughput performance. A- Configuring the SMTP resource to bypass the CVP resource B- increasing the Maximum number of mail messages in the Gateway's spool directory C - Configuring the Content Vector Protocol (CVP) resource to forward the mail to the internal SMTP server, without waiting for a response from the Security Gateway D- Configuring the CVP resource to return the mail to the Gateway They say C - but I didn't know this was possible. |
| |||
| All the configuration options I can find for the SMTP resource using CVP is Return data after content is approved means that the CVP server sends the file back security server after checking the whole file. Return data before content is approved means that the CVP server sends packets to the security server as soon as it checks them. (Return data before content is approved gives better response times to users, but may mean that the CVP server sends virus infected files to the security server) |
| |||
| I would say that the answer would be C. The only thing i have found so far is from the help facility, although i'm looking for a PDF. The CVP Server checks the file one packet at a time. After the CVP Server has inspected the whole file, it sends a Validation Result message to the Security Server. If the Validation Result is that the file is approved, the Security Server sends the file back to the Inspection Module, which sends the file on to the client. Return data after content is approved means that the CVP Server sends the file back Security Server after checking the whole file. Return data before content is approved means that the CVP server sends packets to the Security Server as soon as it checks them. Return data before content is approved gives better response times to users, but may mean that the CVP server sends virus infected files to the Security Server. |
| |||
| another one of those badly worded answers C - Configuring the Content Vector Protocol (CVP) resource to forward the mail to the internal SMTP server, without waiting for a response from the Security Gateway because it says that the data is forward straight to the internal SMTP server, rather than the security server first - from the pdf the correct action is to pass it to the security server firstly even though the packets have not been checked and then on to the SMTP server. Thanks again for your help. |
| |||
| I agree with you about the input - be nice to get some other ideas - here's my one for today - I hope you can shed some light! Q. IKE DoS protection - need to minimize the performance impact of implementing this new protection. Which of the following configuraions is MOST appropriate? A- Set Support IKE DoS protection from identified source to "Puzzles", and Support IKE DoS protection from unidentified source to "Stateless". B- Set Support IKE DoS Protection from identified source, and Support IKE DoS protection from unidentified source to "Puzzles". C- Set Support IKE DoS protection from identified source to "Stateless," and Support IKE DoS protection from unidentified source to "Puzzles". D- Set "Support IKE DoS protection" from identified source, and "Support IKE DoS protection" from unidentified source to "Stateless". E- Set Support IKE DoS protection from identified source to "Stateless", and Support IKE DoS protection from unidentified source to "None". I've seen every solution say answer D. I know the proper way to set this up is to set Stateless for identified sources (gateways) and Puzzles for unidentified (remote clients) - but the question does say to 'minimize performance' - so I guess that's why they've just gone for Stateless on unidentified sources (as puzzles take a lot of comutational processing). But the question doesn't say set identified to 'none' it seems incomplete. What's your thoughts on this? Thanks |
| |||
| I think the answer is also 'D' you want to limit performance impact on unkown sources, puzzles is very peformance intensive, stateless is less and you wouldn't want to have no protection. Stateless is also the default setting for identified and puzzles for unidentified. I think this question was on the CCSA exam so i'm not expecting it again, unless someone else knows better. I have attached a section from the pdf regarding this for everyone else, like most people here i sometime struggle to find where to setup this, is it an object setting or global properties setting. If in doubt check global properties setting first IKE DoS Attacks The IKE protocol requires that the receiving Gateway allocates memory for the first IKE Phase 1 request packet that it receives. The Gateway replies, and receives another packet, which it then processes using the information gathered from the first packet. An attacker can send many IKE first packets, while forging a different source IP address for each. The receiving Gateway is obliged to reply to each, and assign memory for each. This can consume all CPU resources, thereby preventing connections from legitimate users. The attacker sending IKE packets can pretend to a machine that is allowed to initiate IKE negotiations, such as a VPN-1 Pro Gateway. This is known as an identified source. The attacker can also pretend to have an IP address that the receiving Gateway does not know about, such as a SecuRemote/SecureClient, or a VPN-1 Pro Gateway with a dynamic IP address. This is known as an unidentified source. Defense Against IKE DoS Attacks When the number of IKE negotiations handled simultaneously exceeds a threshold above the capacity, it concludes that it is either under load or experiencing a Denial of Service attack. In such a case, VPN-1 Pro can filter out peers that are the probable source of a potential Denial of Service attack. There are two kinds of protection: Stateless Protection Against IKE DoS Attacks VPN-1 Pro prevents IKE DoS Attacks by delaying allocation of Gateway resources until the peer proves itself to be legitimate. The following process is called stateless protection: 1 If the Gateway concludes that it is either under load or experiencing a Denial of Service attack, and it receives an IKE request, it replies to the alleged source with a packet that contains a number that only the Gateway can generate. The Gateway then “forgets” about the IKE request. In other words, it does not need to store the IKE request in its memory (which is why the protection is called “Stateless”). 2 The machine that receives the packet is required to reinitiate the IKE request by sending an IKE request that includes this number. IKE DOS Protection 34 3 If the Gateway receives an IKE request that contains this number, the Gateway will recognize the number as being one that only it can generate, and will only then continue with the IKE negotiation, despite being under load. If the VPN-1 Pro Gateway receives IKE requests from many IP addresses, each address is sent a different unique number, and each address is required to reinitiate the IKE negotiation with a packet that includes that number. If the peer does not reside at these IP addresses, this unique number will never reach the peer. This will thwart an attacker who is pretending to send IKE requests from many IP addresses. IKE DoS attack protection is not available for third party Gateways. Under heavy load, third party gateways and clients (such as Microsoft IPSec/L2TP clients) may be unable to connect. Using Puzzles to Protect Against IKE DoS Attacks Stateless protection is appropriate where the IKE packet appears to come from an identified source, that is, a machine that is allowed to initiate IKE negotiations, such as a VPN-1 Pro Gateway. An unidentified source is an IP address that the receiving Gateway does not recognize, such as a SecuRemote/SecureClient, or a VPN-1 Pro Gateway with a dynamic IP address. An attacker may well have control of many unidentified IP addresses, and may be able to reply to stateless packets from all these addresses. Therefore, if an attack comes from an unidentified source, another approach is required. The Gateway can require that the source of the IKE request solves a computationally intensive puzzle. Most computers can solve only a very few of these puzzles per second, so that an attacker would only be able to send very few IKE packets per second. This renders a DoS attack ineffective. IKE DoS attack protection is not available for Third party Gateways. Under heavy load, they may be unable to connect. SmartDashboard IKE Dos Attack Protection Settings To protect against IKE Dos attacks, edit the SmartDashboard IKE Denial of Service Protection settings, in the VPN >Advanced page of the Global Properties. • Support IKE DoS protection from identified source — The default setting for identified sources is Stateless. If the Gateway is under load, this setting requires the peer to respond to an IKE notification in a way that proves that the IP address of the peer is not spoofed. If the peer cannot prove this, VPN-1 Pro will not begin the IKE negotiation. If the source is identified, protecting using Puzzles is over cautious, and may affect performance. A third possible setting is None, which means no DoS protection. Advanced IKE Dos Attack Protection Settings Chapter 2 IPSEC & IKE 35 • Support IKE DoS protection from unidentified source — The default setting for unidentified sources is Puzzles. If the Gateway is under load, this setting requires the peer to solve a mathematical puzzle. Solving this puzzle consumes peer CPU resources in a way that makes it difficult to initiate multiple IKE negotiations simultaneously. For unidentified sources, Stateless protection may not be sufficient because an attacker may well control all the IP addresses from which the IKE requests appear to be sent. A third possible setting is None, which means no DoS protection. Last edited by chipone; 2007-11-10 at 00:58. |
| |||
| I would say 'C'. There is a VPN White paper in the Checkpoint site. You can refer that. You may mail me at jaya.prakash.ccsp@gmail.com for copy of that whitepaper. Thanks. |
| |||
| Yes, I would have said answer C every time for IKE DOS protection, but the question mentions not impacting on performance and puzzles is very intensive and that's when I had to think - it does seem odd though not to have any protection on identified sources and only stateless on uniditified - but the question has that twist on performance - if it was simply IKE DOS protection then I would go for stateless and puzzles. |
| |||
| I think the question could be a trick on words. Set "Support IKE DoS protection" from identified source. By default when enable IKE DOS its stateless when enabled. The question is also asking for performance issues which you would want to change from the default which is puzzles to stateless which is a recommendation. |
| |||
| How about this one - I'll let you know what I think after someone has had a go - once again, I can't believe any solution is 100% correct. Your current stand-alone VPN-1 NG with Application intelligence (Al) R55 installation is running on SecurePlafform. You plan to implement VPN-1 NGX in a distributed environment, where the existing machine will be the VPN-1 Pro Gateway. An additional machine will serve as the SmartCenter Server. The new machine runs on a Windows Server 2003. You need to upgrade the NG with Al R55 SmartCenter Server configuration to VPN-1 NGX. How do you upgrade to VPN-1 NGX? A - insert the NGX CD in the existing NG with Al R55 SecurePlafform machine, and answer yes to backup the configuration. Copy the backup file to the Windows Server 2003. Continue the upgrade process. Reboot after upgrade is finished. After SecurePlafform NGX reboots, run sysconfig, select VPN-1 Pro Gateway, and finish the sysconfig process. Reboot again. Use the NGX CD to install the primary SmartCenter on the Windows Server 2003. Import the backup file. B - Run the backup command in the existing SecurePlafform machine, to create a backup file. Copy the file to the Windows Server 2003. Uninstall all Check Point products on SecurePlafform by running rpm CPsuite-R55 command. Reboot. Install new VPN-1 NGX on the existing SecurePlafform machine. Run sysconfig, select VPN-1 Pro Gateway, and reboot. Use VPN-1 NGX CD to install primary SmartCenter Server on the Windows Server 2003. Import the backup file. C - Copy the $FWDIR~conf and $FWDIR~lib files from the existing SecurePlafform machine. Create a tar.gz file, and copy it to the Windows Server 2003. Use VPN-1 NGX CD on the existing SecurePlafform machine to do a new installation. Reboot. Run sysconfig and select VPN-1 Pro Gateway. Reboot. Use the NGX CD to install the primary SmartCenter Server on the Windows Server 2003. On the Windows Server 2003, run upgrade_import command to import $FWDIR~conf and $FWDIR~lib from the SecurePlafform machine. D - Run backup command on the existing SecurePlafform machine to create a backup file. Copy the file to the Windows Server 2003. Uninstall the primary SmartCenter Server package from NG with Al R55 SecurePlafform using sysconfig. Reboot. Install the NGX primary SmartCenter Server and import the backup file. Open the NGX SmartUpdate, and select "upgrade all packages" on the NG with Al R55 Security Gateway. |
| |||
| prakashccsp - Congratulation on passing,as you have just passed today are we studying the correct material. i.e. testking, actualtest, unicert (pass4sure) and the PDF's, is there anything you would suggest to read. Last edited by chipone; 2007-11-12 at 08:08. |
![]() |
| Thread Tools | |
| Display Modes | |
| |