Acquisition Tools

Title: Forensic Acquisition Utilities Author: George Garner
Description: A collection of Windows tools such as ‘dd.exe’, ‘md5sum.exe’, ‘wipe.exe’, and ‘nc.exe’. The version of ‘dd’ in this package can also image memory contents in addition to disks.
Website: http://users.erols.com/gmgarner/forensics/

Source: http://users.erols.com/gmgarner/forensics/

________________________________________
Title: FTimes Author: Klayton Monroe
Description: FTimes is a system baselining and evidence collection tool. The primary purpose of ftimes is to gather and/or develop information about specified directories and files in a manner conducive to intrusion analysis.
Website: http://ftimes.sourceforge.net/FTimes/index.shtml

Source: http://sourceforge.net/project/showfiles.php?group_id=41134

________________________________________
Title: liveview Author: CERT
Description: Live View is a Java-based graphical forensics tool that creates a VMware virtual machine out of a raw (dd-style) disk image or physical disk. This allows the forensic examiner to “boot up” the image or disk and gain an interactive, user-level perspective of the environment, all without modifying the underlying image or disk. Because
Website: http://liveview.sourceforge.net/

________________________________________
Title: netcat Author: hobbit
Description: Netcat has been dubbed the network swiss army knife. It is a simple Unix utility which reads and writes data across network connections, using TCP or UDP protocol. It can be used on a trusted server to save data from a suspect system and can be used on the suspect system to send the output of tools to the server instead of writing to the suspect disk.
Website: http://www.atstake.com/research/tools/network_utilities/

Source: http://www.atstake.com/research/tools/network_utilities/

________________________________________
Title: pdd Author: Joe Grand
Description: pdd (Palm dd) is a Windows-based tool for memory imaging and forensic acquisition of data from the Palm OS family of PDAs. pdd will preserve the crime scene by obtaining a bit-for-bit image or “snapshot” of the Palm device’s memory contents. Such data can be used by forensic investigators, incident response teams, and criminal and civil prosecutors.
Website: [no longer exists]
Source: [local copy]

________________________________________
Title: ProDiscover DFT Author: Technology Pathways LLC
Description: ProDiscover DFT offers forensics examiners a completely integrated Windows application for the collection, analysis, management and reporting of computer disk evidence at an affordable price.
Website: www.techpathways.com

Source: www.techpathways.com (Requires the purchase of an Enterprise License)

________________________________________
Title: psloggedon Author: Mark Russinovich (sysinternals.com)
Description: PsLoggedOn is an applet that displays both the locally logged on users and users logged on via resources for either the local computer, or a remote one.
Website: http://www.sysinternals.com/ntw2k/freeware/psloggedon.shtml

Source: http://www.sysinternals.com/ntw2k/freeware/psloggedon.shtml

________________________________________
Title: TULP2G Author: Netherlands Forensic Institute (NFI)
Description: TULP2G is a forensic software framework developed to make it easy to extract and decode data from digital devices. Besides the framework, it is distributed along with several plug-ins to read data from digital devices (at this point, mobile phones and SIM cards).
Website: http://sourceforge.net/projects/tulp2g/

Source: http://sourceforge.net/project/showfiles.php?group_id=119389

________________________________________
Title: UnxUtils Author: Karl Syring
Description: Ports of GNU tools, including ‘dd’, that do not need special DLLs.
Website: http://unxutils.sourceforge.net

Source: http://unxutils.sourceforge.net (via CVS)

________________________________________
Title: Webjob Author: Klayton Monroe
Description: WebJob downloads a program over HTTP/HTTPS and executes it in one unified operation. The output, if any, may be directed to stdout/stderr or a Web resource. WebJob may be useful in incident response and intrusion analysis as it provides a mechanism to run known good diagnostic programs on a potentially compromised system.
Website: http://webjob.sourceforge.net/WebJob/index.shtml

Source: http://sourceforge.net/project/showfiles.php?group_id=40788

Media Management Analysis Tools

Title:TestDisk Author: Christophe Grenier
Description: Tool to check and undelete partition. Works with the following partitions: FAT12 FAT16 FAT32, Linux EXT2/EXT3, Linux SWAP (version 1 and 2), NTFS (Windows NT/W2K/XP), BeFS (BeOS), UFS (BSD), Netware, and ReiserFS.
Website: http://www.cgsecurity.org/testdisk.html

Source: http://www.cgsecurity.org/testdisk.html

File System Analysis Tools

Title:Explore2fs Author: John Newbigin
Description: Explore2fs allows you to view the contents of an Ext2FS partition from within Windows.
Website: http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm

Source: http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm

________________________________________
Title: ProDiscover DFT Author: Technology Pathways LLC
Description: ProDiscover DFT offers forensics examiners a completely integrated Windows application for the collection, analysis, management and reporting of computer disk evidence at an affordable price.
Website: www.techpathways.com

Source: www.techpathways.com (Requires the purchase of an Enterprise License)

Application Analysis Tools

Title:Event Log Parser Author:Jamie French
Description: A PHP script to parse through Windows event logs.
Website: http://www.whitehats.ca/main/members/Malik/malik_eventlogs/malik_eventlogs.html

Source: http://www.whitehats.ca/main/members/Malik/malik_eventlogs/malik_eventlogs.html

________________________________________
Title: Galleta Author: Keith Jones
Description: Galleta, the Spanish word meaning “cookie”, was developed to examine the contents of the cookie files. Galleta will parse the information in a Cookie file and output the results in a field delimited manner so that it may be imported into your favorite spreadsheet program. Galleta is built to work on multiple platforms and will execute on Windows (through Cygwin), Mac OS X, Linux, and *BSD platforms.
Website: http://www.foundstone.com/resources/proddesc/galleta.htm

Source: http://sourceforge.net/project/showfiles.php?group_id=78332&release_id=152412

________________________________________
Title: md5deep Author: Jesse Kornblum
Description: md5deep is an MD5 program that can compute recursively, compare hashes with a database, and estimates the time to completion.
Website: http://md5deep.sourceforge.net/

Source: http://md5deep.sourceforge.net/

________________________________________
Title: MD5summer Author: Luke Pascoe
Description: MD5summer is an application for Microsoft Windows 9x, NT, ME, 2000 and XP which generates and verifies md5 checksums. Its output file is compatible with the output of the Linux GNU MD5Sum and it will also read Linux generated files.
Website: http://www.md5summer.org/

Source: http://www.md5summer.org/download.html

________________________________________
Title: Outport Author: chief1ic
Description: Outport provides a means of migrating information from Microsoft Outlook to Ximian Evolution and several standard data formats.
Website: http://outport.sourceforge.net/

Source: http://outport.sourceforge.net/

________________________________________
Title: Pasco Author: Keith Jones
Description: Pasco, the latin word meaning “browse”, was developed to examine the contents of Internet Explorer’s cache files. Pasco will parse the information in an index.dat file and output the results in a field delimited manner so that it may be imported into your favorite spreadsheet program. Pasco is built to work on multiple platforms and will execute on Windows (through Cygwin), Mac OS X, Linux, and *BSD platforms.
Website: http://www.foundstone.com/resources/proddesc/pasco.htm

Source: http://sourceforge.net/project/showfiles.php?group_id=78332&release_id=152387

________________________________________
Title: ProDiscover DFT Author: Technology Pathways LLC
Description: ProDiscover DFT offers forensics examiners a completely integrated Windows application for the collection, analysis, management and reporting of computer disk evidence at an affordable price.
Website: www.techpathways.com

Source: www.techpathways.com (Requires the purchase of an Enterprise License)

________________________________________
Title: Rifiuti Author: Keith Jones
Description: Rifiuti, the Italian word meaning “trash”, was developed to examine the contents of the INFO2 file in the Recycle Bin. Rifiuti will parse the information in an INFO2 file and output the results in a field delimited manner so that it may be imported into your favorite spreadsheet program. Rifiuti is built to work on multiple platforms and will execute on Windows (through Cygwin), Mac OS X, Linux, and *BSD platforms.
Website: http://www.foundstone.com/resources/proddesc/rifiuti.htm

Source: http://sourceforge.net/project/showfiles.php?group_id=78332&release_id=152410

Definition of: DNS

(Domain Name System) A system for converting host names and domain names into IP addresses on the Internet or on local networks that use the TCP/IP protocol. For example, when a Web site address is given to the DNS either by typing a URL in a browser or behind the scenes from one application to another, DNS servers return the IP address of the server associated with that name.

In this hypothetical example, WWW.COMPANY.COM would be converted into the IP address 204.0.8.51. Without DNS, you would have to type the four numbers and dots into your browser to retrieve the Web site, which of course, you can do. Try finding the IP of a favorite Web site and type in the dotted number instead of the domain name!

A Hierarchy
The DNS system is a hierarchy of database servers that start with the root servers for all the top level domains (.com, .net, etc.). The root servers point to authoritative servers residing within ISPs and companies that resolve the host names to complete the name resolution. Using the example WWW.COMPANY.COM, COMPANY.COM is the domain name, and WWW is the host name. The domain name is the organization’s identity on the Web, and the host name is the name of the actual Web server within that domain (see WWW). See DNS records, reverse DNS, DDNS, HOSTS file, mDNS, ping, root server and WINS.

Definition of: DNS records

A DNS server is configured with a “zone file” for each domain that contains “resource records.” There are several types of records, and the most common are described below. See DNS.

DNS and Reverse DNS (A and PTR)
The Address (A) record associates a domain name with an IP address, which is the primary purpose of the DNS system. The Pointer (PTR) record provides data for reverse DNS, which is used for logging the domain name and verification purposes. Also called “inverse DNS,” the PTR record is an option. See reverse DNS.

Aliasing Names (CNAME)
The Canonical Name (CNAME) record is used to create aliases that point to other names. It is commonly used to map WWW, FTP and MAIL subdomains to a domain name; for example, a CNAME record can associate the subdomain FTP.COMPUTERLANGUAGE.COM with COMPUTERLANGUAGE.COM.

DNS Name Servers (NS)
The Name Server (NS) record identifies the authoritative DNS servers for a domain. A second name server is required for redundancy, and two NS records must be in the zone file (one for the primary; one for the secondary). The secondary server queries the primary server for changes.

Mail Servers (MX)
The Mail Exchange (MX) record identifies the server to which e-mail is directed. It also contains a priority field so that mail can be directed to multiple servers in a prescribed order.

Text Record (TXT)
A TXT record can be used for any kind of documentation. It is also used to provide information to the SPF e-mail authentication system. See SPF.

First Record in File (SOA)
Start of Authority (SOA) is the first record in the zone file. It contains the name of the primary DNS server, which must correspond to an NS record in the file, the administrator’s e-mail address and the length of time records can be cached before going back to the authoritative DNS server.

The SOA also includes data for the secondary DNS server such as the date of last update (the “Serial Number”) and time intervals for checking the domain.

COMMON ZONE FILE RESOURCE RECORDS

Associates With
Type Name This This

SOA Start of Authority (1st record)

A IPv4 Address subdomain 32-bit IP
A6 IPv6 Address subdomain 128-bit IP
AAAA** IPv6 Address subdomain 128-bit IP

PTR Pointer IP address subdomain

CNAME Canonical alias name actual name

NS Name Server domain DNS server

MX Mail Exchange mail mail server

TXT Text (up to 255 characters of text)

** = First IPv6 A record, switched to A6

Definition of: reverse DNS

(Reverse Domain Name System) Name resolution that is the opposite of the standard DNS query. Most of the time, the DNS is queried with a domain name to return the host’s IP address. With reverse DNS, also called “inverse DNS,” the DNS system is sent an IP address, and the domain name is returned.

Reverse DNS is used to log incoming traffic by domain name for statistical purposes. It is also used to prevent spam by determining if the e-mail message is coming from the domain name indicated in the message header. Reverse DNS is only an option and not mandatory in a DNS server. See DNS records, DNS and SPF.

Email
Instant Messaging
Viruses/Trojans/Worms
Spam
Phishing

Online Shopping
Online Banking
Personal Finance
Spyware/Adware
Phishing
Viruses/Trojans/Worms
Crimeware

Download Music, Videos and Software
Play Online Games
Post to Blogs and Wikis
Spyware/Adware
Phishing
Viruses/Trojans/Worms
Crimeware

Digital Photography
(upload photos, download free photos and images, etc.)
Spyware/Adware
Phishing
Viruses/Trojans/Worms
Crimeware

Surf the Internet
Research Products and Travel
Get News and Information
Spyware/Adware
Phishing
Viruses/Trojans/Worms
Crimeware

Spam is an unsolicited message received via email or instant messaging, usually sent with the intent of making money for the sender. Lately, to evade detection by spam filters, senders are relying more on images rather than text as the main content of their messages.

Spyware includes various kinds of software that live on your computer without your permission. They watch, log and report on your activities. These programs can record your keystrokes, log events like which websites you visit, or take pictures of your desktop to discover passwords or other sensitive data.

Adware often works in conjunction with spyware to present you with highly targeted ads based on your preferences and habits.

Phishing indicates any attempt to collect your personal information as a way to steal your identity and your funds. Typically, the reader clicks a link in an email that points to a webpage. Both the email and webpage appear authentic, but are really attempts to “impersonate” a reputable institution. Other modes for phishing include phones, instant messages, and faxes.

Pharming is when hackers hijack a legitimate web address and redirect the visitor’s browser to an imposter website that looks like the original. Also known as “spoofing,” the intent is the same as phishing.

Bots are short for “robots.” They are small programs placed onto an unsuspecting user’s PC by way of a Trojan horse program that is typically triggered via phishing. Once seeded onto the user’s machine, bots can recruit other bots to join them on the infected computer. Collections of bots distributed over PCs that are geographically dispersed can be controlled from a central location. See “botnet.”

Botnets are a collection of bots controlled from a remote, central location. Organized criminals use botnets to distribute spam, roll out phishing scams, cripple websites, and extort money.

Virus is a program that can reproduce itself and spread quickly. Some viruses carry damage routines. Some routines may only display messages or images, others may destroy files, reformat your hard drive, or cause other mayhem. Even without a damage routine, a virus can cause trouble by taking up storage space and memory. This will degrade your computer performance.

Worms are self-contained computer programs (or set of programs) that can spread copies of themselves to other computer systems via network connections, email attachments, instant messages, file-sharing applications, and by collaborating with other malware. Some worms may also prevent you from securely accessing websites. They may even steal the licenses of installed games and applications.

Trojan horse programs perform malicious acts but cannot replicate themselves. Trojan horse programs arrive looking harmless, but hidden on the inside are malicious codes. When a Trojan horse program runs, you may experience computer performance problems or lose valuable data.

Crimeware is an overall term for software used to steal funds. Crimeware can spread by way of viruses, Trojan horse programs, worms, spyware, or adware. See bots, botnets.

Malware is a catch-all term for any software program that gets onto users’ computers without their permission, attempts to remain undetected, and performs malicious acts.

Check out these Discounted Security/Privacy Tools
Port # Protocol General Description Info
1 TCP Socks Des Troie Info

2 TCP Death Info

8 ICMP Ping Attack Info

20 TCP Senna Spy Info

21 TCP FTP service, Dolly Trojan Info

22 TCP Shaft Info

23 TCP Fire Hacker Info

25 TCP Trojans & Worms using this port Info

31 TCP Agent 31, Hacker’s Paradise Info

37 TCP Trojans & Worms using this port Info

41 TCP Deep Throat Info

53 TCP Trojans & Worms using this port Info

58 TCP DM Setup Info

69 TCP Trojans & Worms using this port Info

70 TCP W32.Evala.Worm Info

79 TCP Firehotcker Info

80 TCP Trojans & Worms using this port Info

81 TCP Beagle.S Info

85 TCP Common Port for phishing scam sites Info

87 TCP Common Port for phishing scam sites Info

88 TCP pwsteal.likmet.a Info

90 TCP Hidden Port 2.o
99 TCP Common Port for phishing scam sites Info

110 TCP ProMail Trojan Info

113 TCP Trojans & Worms using this port Info

119 TCP Happy99 Info

121 TCP Jammer Killah Info

129 TCP Password Generator Protocol
135 TCP UDP Trojans & Worms using this port Info

137 TCP UDP Netbios name (DoS attacks) Info

138 TCP UDP Netbios datagram Info

139 TCP UDP Netbios session (DoS attacks) Info

146 TCP Infector 1.3 Info

382 TCP W32.Rotor Info

420 TCP W32.kibuv.b Info

421 TCP Tcp Wrappers
443 TCP Trojans & Worms using this port Info

445 TCP Trojans & Worms using this port Info

456 TCP Hacker’s Paradise Info

530 TCP W32.kibuv.worm Info

531 TCP Rasmin Info

555 TCP Stealth Spy, Phaze, 7-11 Trojan Info

559 TCP Trojans & Worms using this port Info

587 TCP Sober worm Variants Info

666 TCP Attack FTP Info

666 UDP N0kN0k Trojan Info

777 TCP BackDoor.Netcrack.B Info

778 TCP BackDoor.Netcrack.B Info

880 TCP Common Port for phishing scam sites Info

901 TCP Backdoor.Devil Info

902 TCP Backdoor.Devil Info

911 TCP Dark Shadow
999 TCP DeepThroat Info

1000 TCP Der Spaeher
1001 TCP Backdoor.Wortbot Info

1011 TCP Doly Trojan
1012 TCP Doly Trojan
1015 TCP Doly Trojan
1024 TCP Backdoor.lingosky Info

1025 TCP Trojans & Worms using this port Info

1025 UDP Maverick’s Matrix 1.2 - 2.0
1033 TCP NetSpy
1034 TCP Trojans & Worms using this port Info

1042 TCP Bla
1045 TCP Rasmin
1080 TCP Trojans & Worms using this port Info

1081 TCP Backdoor.Zagaban Info

1111 TCP Trojans & Worms using this port Info

1218 TCP Backdoor.Sazo Info

1234 TCP Trojans & Worms using this port Info

1243 TCP Sub Seven
1245 TCP VooDoo Doll
12345 TCP Backdoor.Amitis.B Info

1269 TCP Maverick’s Matrix
12631 TCP WhackJob
1349 UDP BackOrifice DLL Comm
1394 TCP GoFriller, Backdoor G-1
1433 TCP w32.spybot.ofn Info

1492 TCP FTP99CMP
1505 TCP UDP FunkProxy Info

1509 TCP Psyber Streaming server
1533 TCP Backdoor.Miffice Info

1534 TCP Bizex.Worm Info

1600 TCP Shivka-Burka
1604 TCP UDP ICA Browser Info

1751 TCP Loxbot.d Info

1772 TCP Backdoor.NetControle Info

1807 TCP SpySender
1863 TCP Trojans & Worms using this port Info

1981 TCP Shockrave
1999 TCP BackDoor.BiFrose Info

2000 TCP UDP BackDoor.Fearic Info

2001 TCP Trojan Cow
2002 TCP TransScout
2003 TCP TransScout
2004 TCP TransScout
2005 TCP TransScout
2023 TCP Ripper
2041 TCP W32.korgo.a Info

2080 TCP Backdoor.TJServ Info

2090 TCP Backdoor.Expjan Info

2115 TCP Bugs
2140 TCP Deep Throat Info

2140 UDP Deep Throat Info

2155 TCP Illusion Mailer
2222 UDP BackDoor.Botex Info

2283 TCP Dumaru.Y Info

2322 TCP backdoor.shellbot Info

2333 TCP backdoor.shellbot Info

2334 TCP Eyeveg.worm.c Info

2335 TCP backdoor.shellbot Info

2414 TCP vbs.shania Info

2565 TCP Striker
2583 TCP WinCrash
2716 TCP The Prayer 1.2 -1.3
2721 TCP Phase Zero
2745 TCP Beagle.J Info

2766 TCP W32.hllw.deadhat.b Info

2801 TCP Phineas Phucker
2989 TCP Backdoor.Brador.A Info

2989 UDP Rat
3024 TCP WinCrash
3028 TCP Backdoor.Wortbot Info

3030 TCP W32.Mytob.cz@mm Info

3067 TCP W32.korgo.a Info

3127 TCP Trojans & Worms using this port Info

3127 - 3198 TCP MyDoom.B@mm Info

3129 TCP Master’s Paradise
3150 TCP Deep Throat Info

3150 UDP Deep Throat Info

3195 TCP Backdoor.IRC.Whisper.b Info

3256 TCP W32.HLLW.Dax Info

3306 TCP Backdoor.Nemog.D Info

3332 TCP Trojans & Worms using this port Info

3385 TCP w32.Mytob.kp@MM Info

3737 TCP Backdoor.helios Info

3410 TCP W32.mockbot.a.worm Info

3456 TCP UDP Backdoor.Fearic Info

3459 TCP Eclipse 2000
3547 TCP Backdoor.Amitis.B Info

3700 TCP Portal of Doom
3791 TCP Eclypse
3801 UDP Eclypse
4000 UDP WityWorm (BlackICE/ISS) Info

4001 TCP Backdoor.OptixPro.13.C Info

4092 TCP WinCrash
4128 TCP Backdoor.rcserv Info

4242 TCP Backdoor.Nemog.D Info

4300 TCP Backdoor.smokodoor Info

4387 TCP Phatbot Info

4444 TCP Trojans & Worms using this port Info

4512 TCP W32.mytob.db Info

4567 TCP File Nail
4590 TCP ICQ Trojan
4646 TCP Backdoor.Nemog.D Info

4661 TCP Backdoor.Nemog.D Info

4751 TCP Beagle.U Info

4820 TCP Backdoor.tuxder Info

4888 TCP W32.Opanki Info

4899 TCP W32.RaHack Info

4903 TCP Common Port for phishing scam sites Info

8080 TCP Trojans & Worms using this port Info

8081 TCP Trojans & Worms using this port Info

9999 TCP The prayer 1.2 -1.3
5000 TCP Trojans & Worms using this port Info

5001 TCP Sokets de Trois v1./Bubbel
5011 TCP Ootlt
5031 TCP Net Metropolitan 1.0
5032 TCP Net Metropolitan 1.04
5152 TCP Backdoor.laphex.client Info

5190 TCP Trojans & Worms using this port Info

5321 TCP Firehotcker
5400 TCP Blade Runner
5401 TCP Blade Runner
5402 TCP Blade Runner
5418 TCP Backdoor.DarkSky.B Info

5419 TCP Backdoor.DarkSky.B Info

5503 UDP Remote Shell Trojan Info

5521 TCP Illusion Mailer
5550 TCP Xtcp
5512 TCP Xtcp
5553 TCP Backdoor.Xlog Info

5554 TCP W32.Sasser.Worm Info

5555 TCP Backdoor.Sysbug Info

5555 TCP Backdoor.OptixPro Info

5556 TCP BO Facil
5557 TCP BO Facil
5558 TCP Backdoor.Easyserv Info

5569 TCP Robo-Hack
5555 TCP W32.MiMail.P Info

5588 TCP Backdoor.EasyServ Info

5637 TCP PC Crasher
5638 TCP PC Crasher
5714 TCP WinCrash
5741 TCP WinCrash
5742 TCP WinCrash
5800 TCP Backdoor.Evivinc Info

5900 TCP Backdoor.Evivinc Info

6000 TCP LovGate.ak Info

6129 TCP W32.mockbot.a.worm Info

6180 TCP Common Port for phishing scam sites Info

6187 TCP Trojan.Tilser Info

6400 TCP The Thing
6565 TCP Backdoor.Nemog.D Info

6631 TCP backdoor.sdbot.ag Info

6667 TCP Trojans & Worms using this port Info

6669 TCP Vampyre
6670 TCP Deep Throat Info

6671 TCP Deep Throat Info

6711 TCP Sub Seven, Backdoor.G
6712 TCP Sub Seven Info

6713 TCP Sub Seven Info

6723 TCP Mstream attack-handler Info

6771 TCP Deep Throat Info

6776 TCP Sub Seven, Backdoor.G Info

6777 TCP W32/Bagle@MM Info

6789 TCP NetSky.U Info

6838 UDP Mstream Agent-handler Info

6912 TCP Sh*t Heap
6939 TCP Indoctrination
6969 TCP Trojans & Worms using this port Info

6970 TCP Gate Crasher
7000 TCP w32.mytob.mx@mm Info

7043 TCP W32.Spybot.ycl Info

7000 TCP Remote Grab
7028 TCP Unknown Trojan
7028 UDP Unknown Trojan
7300 TCP Net Monitor
7301 TCP Net Monitor
7306 TCP Net Monitor
7307 TCP Net Monitor
7308 TCP Net Monitor
7329 TCP Backdoor.netshadow Info

7410 TCP Backdoor.phoenix Info

7597 TCP QaZ (Remote Access Trojan) Info

7614 TCP Backdoor.GRM Info

7740 TCP backdoor.nodelm Info

7741 TCP backdoor.nodelm Info

7742 TCP backdoor.nodelm Info

7743 TCP backdoor.nodelm Info

7744 TCP backdoor.nodelm Info

7745 TCP backdoor.nodelm Info

7746 TCP backdoor.nodelm Info

7747 TCP backdoor.nodelm Info

7748 TCP backdoor.nodelm Info

7749 TCP backdoor.nodelm Info

7789 TCP ICKiller Info

7823 TCP Backdoor.Amitis.B Info

7955 TCP W32.kibuv.b Info

7983 UDP MStream handler-agent Info

7999 TCP w32.mytob.lz@mm Info

8000 TCP w32.mytob.jw@mm
Info

8012 TCP Backdoor.Ptakks.b Info

8076 TCP W32.Spybot.pen Info

8080 TCP Trojans & Worms using this port Info

8090 TCP Backdoor.Asniffer Info

8126 TCP W32.PejayBot Info

8787 TCP UDP BackOrifice 2000
8811 TCP Backdoor.Monator Info

8866 TCP Beagle.B@mm Info

8879 TCP UDP BackOrifice 2000
8888 TCP W32.Axatak Info

8889 TCP W32.Axatak Info

9000 TCP W32.randex.ccf Info

9125 TCP Backdoor.nibu.k Info

9325 UDP MStream Agent-handler Info

9400 TCP InCommand
9604 TCP W32.kibuv.worm Info

9696 TCP Backdoor.gholame Info

9697 TCP Backdoor.gholame Info

9870 TCP BackDoor.RC3.B Info

9872 TCP Portal of Doom
9873 TCP Portal of Doom
9874 TCP Portal of Doom
9875 TCP Portal of Doom
9876 TCP Cyber Attacker
9878 TCP Trans Scout
9898-9999 TCP W32.dabber.a Info

9989 TCP iNi-Killer
9995 TCP W.32.Sasser Worm Info

9999 TCP Trojans & Worms using this port Info

10000 TCP W32.dumaru.ad Info

10001 TCP Backdoor.Zdemon.126 Info

10002 TCP Backdoor.Zdemon.126 Info

10008 TCP Cheese worm Info

10027 TCP w32.mytob.jw@mm
Info

10067 TCP Portal of Doom Info

10067 UDP Portal of Doom Info

10080 TCP Mydoom.B Info

10100 TCP backdoor.ranky.o Info

10102 TCP backdoor.staprew Info

10103 TCP backdoor.tuimer Info

10167 UDP Portal of Doom Info

10498 UDP Mstream handler-agent Info

10520 TCP Acid Shivers
10607 TCP Coma
10666 TCP Ambush
11000 TCP Senna Spy
11050 TCP Host Control
11223 TCP Progenic Trojan
11768 TCP Dipnet / oddBob Trojan Info

11831 TCP Latinus Server Info

12000 TCP Backdoor.Satancrew Info

12065 TCP Backdoor.Berbew.j Info

12076 TCP GJamer
12223 TCP Hack’99, KeyLogger
12345 TCP Netbus, Ultor’s Trojan
12346 TCP Netbus Info

12456 TCP NetBus Info

12361 TCP Whack-a-Mole Info

12362 TCP Whack-a-Mole Info

12631 TCP Whack Job
12701 TCP Eclypse 2000
12754 TCP Mstream attack-handler Info

13000 TCP Senna Spy
13173 TCP Backdoor.Amitis.B Info

13468 TCP W32.Sober.D Info

13700 TCP Kuang2 the Virus Info

14247 TCP Trojan.Mitglieder.h Info

15104 TCP Mstream attack-handler Info

15118 TCP Dipnet / oddBob Trojan Info

15432 TCP Backdoor.Cyn Info

16322 TCP Backdoor.Lastdoor Info

16484 TCP Mosucker Info

16661 TCP Backdoor.Haxdoor.D Info

16959 TCP SubSeven DEFCON8 2.1 Backdoor Info

16969 TCP Priority Info

17300 TCP Kuang2.B Trojan Info

17940 TCP W32.Imav.a Info

18753 UDP Shaft handler to Agent Info

19937 TCP Backdoor.Gaster Info

20000 TCP Millennium
20001 TCP Millennium
20034 TCP NetBus 2 Pro Info

20203 TCP Logged! Info

20331 TCP Bla Trojan Info

20432 TCP Shaft Client to handlers Info

20433 TCP Shaft Agent to handlers Info

20480 TCP Trojan.Adnap Info

20742 TCP Trojan.Mitglieder.E Info

21211 TCP W32.dasher.b Info

21554 TCP UDP GirlFriend Info

22222 TCP Prosiak Info

22311 TCP Backdoor.Simali Info

22784 TCP Backdoor-ADM Info

23005 TCP W32.hllw.nettrash Info

23006 TCP W32.hllw.nettrash Info

23232 TCP backdoor.berbew.j Info

23435 TCP Trojan.Framar Info

23476 TCP Donald Dick Info

23477 TCP Donald Dick Info

23523 TCP w32.mytob.km@mm Info

2556 TCP Beagle.N Info

26274 TCP Delta Source Info

26274 UDP Delta Source Info

27015 UDP linux.plupii.c Info

27374 UDP Sub-7 2.1 Info

27379 TCP Backdoor.optix.04 Info

27444 UDP Trin00/TFN2K Info

27573 UDP Sub-7 2.1 Info

27573 TCP Sub-7 2.1 Info

27665 TCP Trin00 DoS Attack Info

29147 TCP Backdoor.Sdbot.ai Info

29292 TCP Backdoor.NTHack Info

29559 TCP Latinus Server Info

29891 TCP The Unexplained Info

29999 TCP Backdoor.Antilam.20 Info

30029 TCP AOL Trojan Info

30100 TCP NetSphere Info

30101 TCP NetSphere Info

30102 TCP NetSphere Info

30133 TCP NetSphere Final Info

30303 TCP Sockets de Troi
30999 TCP Kuang2 Info

31335 UDP Trin00 DoS Attack Info

31336 TCP BO-Whack Info

31337 UDP Backorifice (BO) Info

31337 TCP Netpatch Info

31338 TCP NetSpy DK Info

31338 UDP Deep BO Info

31339 TCP NetSpy DK Info

31666 TCP BOWhack Info

31785 TCP Hack’a'Tack Info

31787 UDP Hack`a’Tack Info

31789 UDP Hack’a'Tack Info

31790 UDP Hack`a’Tack Info

31791 UDP Hack’a'Tack Info

32121 TCP backdoor.berbew.j Info

32418 TCP Acid Battery Info

32440 TCP Backdoor.Alets.B Info

33270 TCP Trinity Trojan Info

33322 TCP trojan.lodeight.b Info

33333 TCP Prosiak Info

33911 TCP Spirit 2001 a Info

34324 TCP BigGluck, TN
36183 TCP Backdoor.Lifefournow Info

37651 TCP Yet Another Trojan Info

39999 TCP TrojanProxy.Win32.Mitglieder Info

40421 TCP Master’s Paradise Info

40412 TCP The Spy Info

40421 TCP Agent, Master’s of Paradise Info

40422 TCP Master’s Paradise Info

40423 TCP Master’s Paradise Info

40425 TCP Master’s Paradise Info

40426 TCP Master’s Paradise Info

43210 TCP Master’s Paradise Info

44280 TCP Backdoor.Amitis.B Info

44390 TCP Backdoor.Amitis.B Info

47252 TCP Delta Source Info

47262 UDP Delta Source Info

47387 TCP Backdoor.Amitis.B Info

47891 TCP Backdoor.antilam.20 Info

49301 UDP OnLine keyLogger Info

50005 TCP Trojan.Fulamer.25 Info

50505 TCP Sokets de Trois v2.
50776 TCP Fore
51234 TCP Backdoor.Cyn Info

51435 TCP W32.kalel.a@mm Info

53001 TCP Remote Windows Shutdown Info

54320 TCP Back Orifice 2000 Info

54320 UDP Back Orifice Info

54321 TCP School Bus, Back Orifice Info

54321 UDP Back Orifice 2000 Info

56565 TCP Backdoor.Osirdoor Info

57341 UDP NetRaider Trojan Info

57341 TCP NetRaider Trojan Info

58008 TCP BackDoor.Tron Info

58009 TCP BackDoor.Tron Info

58666 TCP BackDoor.Redkod Info

59211 TCP BackDoor.DuckToy Info

60000 TCP Deep Throat Info

60006 TCP Trojan.Fulamer.25 Info

61000 TCP Backdoor.mite Info

61466 TCP Telecommando Info

61348 TCP Bunker-Hill Trojan Info

61603 TCP Bunker-Hill Trojan Info

63485 TCP Bunker-Hill Trojan Info

63808 TCP Phatbot Info

63809 TCP Phatbot Info

63809 TCP W32.hllw.gaobot.dk Info

64429 TCP Backdoor.Amitis.B Info

65000 TCP Trojans & Worms using this port Info

65506 TCP Phatbot Info

65535 TCP Adore Worm/Linux Info

* If there is a trojan port not shown here please mail US

Zombies are computers which have been infected with a program that lets an intruder control the computer. Such control can be the cause for thousands of computers to jointly attack a single computer or network.
What is a trojan? A trojan horse is a malicious program hidden within a seemingly useful program, or a program which is said to be one thing, but in reality performs malicious/destructive activity.

Introduction

Firewall technology ranges from packet filtering to application-layer proxies, to Stateful inspection; each technique gleaning the benefits from its predecessor.

Stateful inspection works at the network layer and does not require a separate proxy for each application. This technology does not suffer from the same degradation in performance as application-level technology (proxies), which involves the extra overhead of transporting data up to the application layer. And on the contrary of packet filters it has the ability to maintain session state and therefore increase the security level of a network transaction.

Checkpoint Firewall-1

Checkpoint FW-1 has been the firewall market leader since shortly after its introduction in 1994/95. Its well-designed GUI interface was, and still is, the best visual interface to any firewall product. This intuitive interface makes FW-1 easy to work with even for those new to firewalls.

FireWall-1 is based upon Stateful Inspection technology, the de facto standard for firewalls. Invented by Check Point, Stateful Inspection provides the highest level of security. FireWall-1’s scalable, modular architecture enables an organization to define and implement a single, centrally managed Security Policy. The enterprise Security Policy is defined on a central management server trough a GUI and downloaded to multiple enforcement points (Inspection Modules) throughout the network.
The FireWall-1 Inspection Module is located in the operating system (NT or UNIX operating systems) kernel at the lowest software level. The Inspection Module analyzes all packets before they reach the gateway operating systems. Packets are not processed by any of the higher protocol layers unless FireWall-1 verifies that they comply with the Inspection Module security policy (it examines communications from any IP protocol or application, including stateless protocols, such as UDP and RPC)

PIX Firewall

Originally designed to be a network address translator, Cisco introduced the Private Internet Exchange (PIX) Firewall series in 1994. The PIX Firewall is a high-performance firewall that uses Stateful packet filtering. The PIX Firewall is essentially a firewall appliance”–it has its own integrated hardware/software solution (Intel hardware / proprietary OS). The PIX Firewall is not UNIX or NT-based, but is based on a secure, real-time embedded system, known as the Adaptive Security Algorithm (ASA), which offers Stateful inspection technology. ASA tracks the source and destination address, TCP sequence numbers, port numbers, and additional TCP flags. All inbound and outbound traffic is controlled by applying the security policy to connection table entries, which house the information. Access is permitted through the PIX Firewall only if a connection has been validated or if it has been explicitly configured.

Comparison

PIX and checkpoint FW-1 are using similar technologies in that both use smart packet filtering technologies (Stateful technology).

There are several key differences: one is that FW1 uses a general-purpose operating system while Cisco’s PIX uses an embedded operating system. Another is that the PIX are essentially a “diode”: you define a security level for an interface, and anything from a higher (internal=100) to a lower (external=0) is allowed while lower (external) to higher (internal) is blocked (with coding for exception); with FW1 there are no native directions, and everything must be coded. (For this reason, FW1 can be found much more flexible)
The license structure on the PIX is per-connection; the license structure on FW1 is per protected host. All other things being equal, maintenance is much easier on the PIX, and performance is higher on the PIX. Cisco has recently released a host-to-LAN encryption solution; FW1 has such a solution for a long time now (SecuRemote for windows boxes). FW1 has extra features such as bandwidth management (floodgate) or content vectoring servers and others (see OPSEC products).

Note that FW1 is developed in a UNIX environment. The UNIX implementation is more efficient, more mature, and more stable. It is wrong to go with NT unless the client swears he can support NT and is afraid of UNIX. Also, comparing FW1 on a switch or on a NOKIA box versus the PIX could be kind of an interesting comparison.

PIX Pros:

1) Minimal configuration if you have few or zero internal devices that needs to be accessed directly from the Internet (i.e. web servers on a protected DMZ) and want to allow everything outbound.

2) Complete hardware/software solution, no additional OS vulnerabilities or boot-time errors to worry about.

3) Cisco support, which is generally very good.

4) Performance, probably the best in the business.

5) No special client side software other than telnet, tftp or serial port terminal software.

6) Lots of detailed documentation.

7) Free upgrades

PIX Cons:

1) Difficult to manage if you have many servers on a protected DMZ (lots and lots of conduit statements) or many firewalls to manage.

2) Routing limitation in complex network architectures (Need to add a router for EACH segment).

3) Command line (IOS style) based. Cisco GUI manager (PIX Firewall Manager) is currently in its early releases and not as functional as FW-1’s.

4) No ability to off-load layer 7 services like: virus scanning, URL filtering, etc. You can filter on outgoing traffic, but the process is not dynamic.

5) Requires a separate syslog server for logging.

6) No source port filtering.

No clear documentation (Cisco’s documentation is often conflicting, fails to explain which version of the PIX OS a certain configuration will or will not work under, and seems to be constantly changing).

FW-1 Pros:

1) Very functional GUI interface.

2) Based on Stateful inspection like PIX, but can off-load layer 7 inspection to other servers if required.

3) Lots of features for complex environments like: large protected DMZ, Windows VPN support, firewall synchronization, bi-directional NAT, etc.

4) Can be used to control bi-directional traffic.

5) Complex logging provided on management station.

FW-1 Cons:

1) Must account for OS vulnerabilities as well as FW-1 vulnerabilities.

2) Performance on NT not as good as on UNIX or the PIX.

3) Support is only through re-sellers, very expensive (Contracts start at 50% of the price of the original software per year) and needed for products upgrades.

4) OS boot-time errors possibilities.

NB: PIX can filter java but no ActiveX or JavaScript filtering yet. (Although FW-1 can)

Conclusion

In the simplest terms, FW-1 can be considered much more functional than the PIX, while the PIX have better performance and support. If your particular environment requires a lot of functionality, the best choice is the FW-1 solution, although you might want to consider running it on a UNIX platform rather than a NT platform. If your environment is pretty simple, PIX is a solid solution with very good performance.

Checkpoint Firewall-1 links

Main site: http://www.checkpoint.com/products/firewall-1/

Public Support: http://www.checkpoint.com/techsupport/

Unofficial FAQ: http://www.phoneboy.com/fw1/ http://www.deathstar.ch/security/fw1/

Unofficial mailing list archive: http://msgs.securepoint.com/fw1/

Cisco PIX firewall links

Main site: http://www.cisco.com/warp/public/cc/pd/fw/sqfw500/

FAQ: http://www.cisco.com/warp/public/110/pixfaq.html

Several useful papers: http://www.cisco.com/warp/public/110/index.shtml#pix

Documentation: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/

Top issues: http://www.cisco.com/warp/public/110/top_issues/pix/pix_index.shtml

Configuring a New Cluster
This chapter explains how to create and configure an IPSO cluster. It includes
information about upgrading from IPSO 3.6 if you have created clusters with
3.6 and also explains how to add nodes to a cluster.
Upgrading IPSO in a Cluster
When upgrading a cluster, make sure that all the nodes run the same versions
of IPSO (and NGX, when appropriate). If you are upgrading both IPSO and
NGX, you should first upgrade IPSO on all the nodes and then upgrade NGX.
This approach provides the best continuity of service during the upgrade
process.
Upgrading from IPSO 3.7 or Later
If you want to upgrade a cluster from IPSO 3.7 to a later version of IPSO,
Nokia recommends that you use Cluster Voyager to upgrade the IPSO image
on all the cluster nodes. See the instructions in “Installing IPSO Images” on
page 51.
The upgraded nodes retain any cluster configuration information that was
created with the earlier version of IPSO.
The hash selection is not used by IPSO 3.9, and NGX and no longer appears
in the Clustering Setup Configuration page. Depending upon how you
upgrade to IPSO 3.9 and NGX, you might temporarily see this option. If you
do you can safely ignore it. Once the upgrade is complete and IPSO has
verified that NGX is running, the option disappears.
Upgrading from IPSO 3.6
Upgrading a cluster from IPSO 3.6 to IPSO 3.9 requires a different process
because IPSO 3.6 does not have cluster management functionality.
If you want to upgrade cluster nodes from IPSO 3.6 to IPSO 3.9, Nokia
recommends that you first upgrade all the nodes to IPSO 3.7 and then upgrade
to 3.9. Following this process allows the cluster to remain in service
throughout the upgrade. The upgraded nodes retain any cluster configuration
information that was created with the earlier version of IPSO.
Note
Make sure that you use a version of NGX that is compatible with the IPSO
version that you upgrade the cluster to. If you are using an incompatible
version of NGX, upgrade to a compatible version after you upgrade to the
later version of IPSO. See the IPSO Release Notes and Getting Started
Guide to find out which versions of NGX are compatible with the version
of IPSO you are installing.
A cluster functions if its master runs IPSO 3.6 and one or more nodes run
IPSO 3.7 or later, but Nokia strongly recommends that you upgrade all the
nodes of your IPSO 3.6 clusters. IPSO supports a 3.6 master with 3.7 or later
members to allow a cluster to remain in service during an upgrade.
To upgrade IPSO on cluster nodes and ensure that there are the minimum
number of master transitions, follow the steps below. This procedure assumes
that you are upgrading a three-node cluster in which node C is the master.
Under this procedure, two cluster nodes are in service at all times.

Note
You should upgrade the master last.
1. Upgrade node A to IPSO 3.9 and restart it.
B and C continue to function as a 3.6 cluster. Node A (running 3.9)
rejoins the cluster as a member.
2. Upgrade node B to IPSO 3.9 and restart it.
Node C continues to function as a 3.6 cluster. Node B (running 3.9)
rejoins the cluster as a member.
3. Make sure that nodes A and B have successfully restarted and rejoined the
cluster.
Note
Performing this steps ensures that there will be no interruption in
service when node C restarts.
4. Upgrade node C to IPSO 3.9 and restart it.
When node C begins to restart, node A or B is selected as the new master
and both nodes continue forwarding traffic. When node C completes the
process of restarting, it joins the new 3.9 cluster.
Enabling Cluster Management
After you complete the upgrade process, the cluster is active but you cannot
use Cluster Voyager or the CCLI until you create a password for the cadmin
user on each of the cluster nodes. After you upgrade IPSO on the cluster
nodes, perform the following procedure to create a password for the cadmin
user on each of the nodes.
1. Click CONFIG on the home page.
2. Click Clustering Setup in the Traffic Management section.
The Clustering Setup Configuration page appears.
3. Click Change cadmin password.
The Cluster Management Configuration page appears.
4. Enter a password for the user cadmin.
Note
You must use the same password on each node that you add to the
cluster. This is also the password that you use to log into Cluster
Voyager or the CCLI.
5. Enter the password for cadmin again (for verification).
6. Click APPLY.
The page displays fields for changing the cadmin password. Use this page
if you want to change this password in the future.
7. Repeat this procedure on each of the other nodes that you upgraded from
IPSO 3.6.
You can now manage the cluster using Cluster Voyager or the CCLI.
Creating and Configuring a 3.9 Cluster
This section provides detailed information about how to create and configure
an IPSO 3.9 cluster.
Overview
To create and configure a cluster, follow these basic steps:
1. Create a cluster on the first node.
2. Select the cluster mode.
3. Configure the cluster interfaces.
4. Enable or disable firewall monitoring, as appropriate:
􀂄 If NGX is running on the node, enable NGX monitoring before you
make the cluster active.
􀂄 If NGX is not running on the node, disable NGX monitoring before
you make the cluster active (so that the cluster can be initialized).
After the cluster is active, enable the monitoring so that the cluster
monitors the firewall and leaves the cluster if the firewall fails on the
node.
5. Deselect any features that should not be cluster sharable.
6. Change the cluster state to UP.
7. Save the cluster configuration to disk.
8. If you disabled firewall monitoring in step 4, reenable it.
9. Create cluster configurations on the other nodes.
10. Join the other nodes to the cluster.
The failure interval and performance rating are set by default on each node
and generally should not be changed. See “Configuring the Failure Interval”
on page 47 and “Configuring the Performance Rating” on page 48 for more
information about these features.
You must also configure the NGX to work with the IPSO cluster. Use the
Check Point client application to add a gateway object for the Nokia
appliance. You also must create a gateway cluster object and add the gateway
object to it. Refer to the Check Point documentation and Chapter 4,
“Configuring NGX for Clustering” for details.
Creating a Cluster
1. Click CONFIG on the home page.
2. Click Clustering Setup in the Traffic Management section. The Clustering
Setup Configuration page appears.
3. Enter a cluster ID (0-65535).
4. Enter a password for the user cadmin.
Note
You must use the same password on each node that you add to the
cluster. This is also the password that you use to log into Cluster
Voyager.
5. Enter the password for cadmin again (for verification).
6. Click APPLY.
7. Click Manually Configure IPSO Cluster.
Configure the cluster as explained in the following sections.
Selecting the Cluster Mode
Select the cluster mode that is appropriate for your scenario:
􀂄 If the routers and switches on either side of the cluster support multicast
MAC addresses, you can use multicast mode or multicast mode with
IGMP. These modes usually offer better throughput because they make
better use of the bandwidth of the production networks.
􀂄 If the routers or switches adjacent to the cluster do not support multicast
MAC addresses, you must use forwarding mode.
Configuring the Work Assignment Method
A cluster initially balances its work load by automatically distributing
incoming traffic between the nodes. Use the work assignment setting to
govern whether the cluster can rebalance the load of active connections by
moving them between nodes.
􀂄 For optimum load balancing, use the dynamic setting. This setting allows
the cluster to periodically rebalance the load by moving active
connections between nodes.
Setting the work assignment to static prevents the cluster from moving
active connections between nodes. Some Check Point applications and
features require “bidirectional stickiness,” which means that all the
packets for a given connection must be processed by the same node. If
you use any of these applications and features, you must also set the work
assignment to static for them to work properly. See Check Point’s
document ClusterXL: NG with Application Intelligence for information
about which applications and features require bidirectional stickiness.
(Floodgate-1 and the Sequence Verifier feature of NGX require this
setting.)
You must use static work assignment if you are using IP pools with non-
Check Point gateways or clients. See “Supporting Non-Check Point
Gateways and Clients” for related information.
If any of the requirements for static work assignment apply to your
cluster, you should use this setting. For example, you should use static
work assignment if your cluster supports both of the following:
􀂄 VPNs with Check Point gateways (static work assignment not
required)
􀂄 VPNs with non-Check Point gateways with IP pools (static work
assignment required)
Configuring an Interface
To activate the cluster protocol, you must select at least two Ethernet
interfaces. One of the two must be an internal or external interface (not a
primary or secondary cluster interface). The other interface must be the
primary interface.

Note
Nokia recommends that you select another interface as a secondary
cluster protocol interface. Remember that the primary and secondary
cluster protocol networks should not carry any production traffic.

The Interfaces Configuration table lists all the Ethernet interfaces on the
system that are configured with IP addresses. The table displays the status and
IP address of each interface. To add Ethernet interfaces to this list or to
activate inactive interfaces, go to the Interface Configuration page.
To include an interface in the cluster:
1. In the Select column, select YES.
2. Enter the cluster IP address.
The address must be in the same network as the IP address of the interface
you are configuring. This is a common IP address that each node will
share.
3. Repeat the above steps for the rest of the interfaces that will participate in
the cluster.
4. For the interface that will serve as the primary cluster protocol interface
for the node, click the YES button in the Primary Interface column.
The primary interfaces of all the cluster nodes must belong to the same
network. This network should not carry any other traffic.
5. For the interface that will serve as the secondary cluster protocol interface
for the node, click the YES button in the Secondary Interface column.
The secondary interfaces of all the cluster nodes must belong to the same
subnet. This subnet should not carry any other traffic unless you use it to
carry firewall synchronization traffic. (See Chapter 4, “Configuring NGX
for Clustering” for information about selecting the firewall
synchronization network.) Secondary interfaces are optional.
6. If you are using multicast with IGMP mode and do not want to use the
default IP multicast group address, enter a new address in the range
239.0.0.0 to 239.255.255.255.
7. Click APPLY.

Configuring Firewall Monitoring
Use the option ENABLE VPN-1/FW-1 MONITORING? in the firewall table to
specify whether IPSO should wait for NGX to start before the system
becomes a node of a cluster—even if it is the only node of the cluster. (This is
particularly relevant if a cluster node is rebooted while it is in service.) This
option also specifies whether IPSO should monitor NGX and remove the
node from the cluster if the firewall stops functioning.
To enable firewall monitoring, click ENABLE next to ENABLE VPN-1/FW-1
MONITORING? in the firewall table.
If NGX is not running at the time you change the cluster state to UP, click
DISABLE next to ENABLE VPN-1/FW-1 MONITORING? If NGX is not
running and you do not disable firewall monitoring, you cannot initialize the
cluster protocol.
Note
Be sure to enable firewall monitoring before you put the cluster into
service (assuming that you are using NGX).
Supporting Non-Check Point Gateways and Clients
If your IPSO cluster will create VPN tunnels with non-Check Point gateways
or clients, Click the option for enabling non-Check Point gateway and client
support on the Clustering Setup Configuration page and then perform the
following procedure:
1. If you want to support non-Check Point clients, click the option for
enabling VPN clients. This is all you have to do.
2. If you want to support non-Check Point gateways, enter the appropriate
tunnel and mask information, as explained in “Configuring VPN
Tunnels.”
3. If you want to support IP pools, follow the instructions in “Configuring IP
Pools In Cluster Voyager.”

Note
If you want to support VPNs with remote non-Check Point gateways, do
not check the “Support non-sticky connections” option for these
connections in Check Point’s Smart Dashboard.
Configuring VPN Tunnels
If you want the cluster to support VPN tunnels in which non-Check Point
gateways participate, you must configure the tunnels in Voyager (on the
Clustering Setup Configuration page) as well as in NGX. Perform the
following procedure:
1. In the NETWORK ADDRESS field under Add New VPN Tunnel, enter the
remote encryption domain IP address in dotted-decimal format (for
example, 192.168.50.0).
2. In the MASK field, enter the mask value as a number of bits. The range is
8 to 32.
3. In the TUNNEL END POINT field, enter the external address of the non-
Check Point gateway.
4. Click APPLY.
The VPN Tunnel Information table appears and displays the information
you configured.
5. If there is more than one network behind the non-Check Point gateway,
repeat these steps for each network. In each case, enter the external
address of the non-Check Point gateway as the tunnel end point. If one of
the networks behind a non-Check Point gateway is not encrypted (for
example, a DMZ), set its end point to 0.0.0.0.

involved
To set up the configuration shown in the previous diagram, you would:
􀂄 Configure the IP pools in NGX.
􀂄 On the internal router:
􀂄 create a default route to the Internet with 192.168.1.1 (the default
gateway) as the gateway address.
􀂄 create static routes to the IP pool networks with the internal cluster IP
address (192.168.1.10) as the gateway address. Do not use the real IP
addresses of the internal cluster interfaces (192.168.1.2 and
192.168.1.3) as gateway addresses. In the example network, the
internal router has the following static routes:
􀂄 route: 10.1.2.0/24, gateway: 192.168.1.10
􀂄 route: 10.1.3.0/24, gateway: 192.168.1.10

Configuring IP Pools In Cluster Voyager
If you want to use IP pools with a VPN in which a non-Check Point gateway
participates, you must configure the pools in IPSO as well as in NGX. You
must configure all the pools on all the nodes, so it is easiest and less error
prone to use Cluster Voyager (or the CCLI) for this task. To configure IP
pools in Cluster Voyager, follow this procedure after you enable support for
non-Check Point gateways:
1. In the NETWORK ADDRESS field under ADD NEW IP POOL, enter the
network that the IP pool addresses will be assigned from.
If you were configuring firewall A in the cluster shown in the previous
diagram, you would enter 10.1.2.0.
Note
To ensure routing symmetry, the IP pool networks must be different
on different cluster nodes.
2. In the MASK field, enter the appropriate subnet mask.
If you were configuring firewall A in the cluster shown in the previous
diagram, you would enter 24.
3. In the MEMBER ADDRESS field, enter the real IP address of the primary
cluster protocol interface.
If you were configuring firewall A in the cluster shown in the previous
diagram, you would enter 192.168.3.1.
Configuring Join-Time Shared Features
You may want to have many configuration settings be identical on each
cluster node. Voyager makes this easy for you by letting you specify which
features will be configured the same on all cluster nodes. The features that are
configured this way are called join-time shared features. Their configurations
are shared when:

A system joins (or rejoins) the cluster. In this case, the joining system
receives the settings of the shared features.
􀂄 A new master is selected. In this case, all the members receive the settings
of the shared features from the master. This occurs in either mode when
the original master leaves the cluster (for example, if it is rebooted). It can
also occur in forwarding mode if you manually adjust the performance
rating or if a system with a higher rating becomes joins the cluster. See
“Configuring the Performance Rating” on page 48 for more information.
In addition to helping you make sure that all cluster nodes are configured
consistently, using this feature makes the configuration process easier and
faster.
The list of shared features should be specified only when you set up a cluster.
Once the cluster is operational, you should avoid changing which features are
cluster sharable. The basic approach to follow is:
1. Configure the first node.
2. Join the other systems to the first node so that they all copy the shared
settings from the same source.
What is Sharable?
Join-time shared features are not directly related to clustering itself. They are
features used on an IPSO system regardless of whether it is part of a cluster.
For example, if you want each cluster node to have the same static routes, you
configure the static routes on the first cluster node and make sure that static
routes are selected as a sharable feature. When other nodes become part of the
cluster, those routes are configured on them also.
If the system that is joining the cluster already has static routes configured,
they are retained. The routes copied as a result of the joining process are
added to the list of static routes.

What if Settings Conflict?
If there is a conflict between configuration settings on the existing node and
the joining system, the settings on the joining system are changed to those of
the master node. For example, assume that you have a cluster with nodes A
(the master) and B in which DNS is a shared feature and the domain name on
node A is company-name.com. If a third node (C) joins the cluster and its
domain name is foobar.com before it joins, foobar.com is replaced by
company-name.com during the joining process.
If you change the domain name on node C back to foobar.com, the domain
name remains foobar.com unless any of the following occurs:
􀂄 node C leaves and rejoins the cluster
􀂄 node B becomes the master
􀂄 a cadmin user changes the domain name (while logged into any node)
In the first two situations, node C will once again copy the settings for all the
join-time shared features, and company-name.com will replace foobar.com as
the domain name. In the third situation, the domain name is changed on all the
nodes.
If you want to be able to easily reset the configuration of node C to what you
had configured manually, simply save the desired configuration on C. If the
active configuration changes because of join-time sharing, you can reload the
desired configuration on C from the saved configuration file. See “Managing
Configuration Sets” on page 72 for information about saving and loading
configuration files.
If node C becomes the master in the previous example, then its settings for
join-time shared features are copied to the other nodes. For example,
foobar.com would replace company-name.com on nodes A and B.

result in configuration issues. The best practice is to avoid conflicts in
the configurations of join-time shared features.
If a feature on a joining system has a setting and the feature is not configured
on the master, the joining system retains its setting. For example, assume that
you have a two node cluster in which DNS is a shared feature but no domain
name is configured on the master. If a third system joins the cluster and its
domain name is foobar.com before it joins, it retains that domain name after it
joins.
Configuring Features for Sharing
Follow these steps to ensure that the appropriate configuration settings are
identical on each cluster node:
1. After you create a cluster configuration on the first node, make sure all
the relevant settings are correct (on the Clustering Setup Configuration
page).
2. Scroll to the bottom of the Clustering Setup Configuration page and click
NO next to any features that should not share settings across the cluster.
Caution
After you click APPLY (the next step), you cannot conveniently make
features sharable again if you make them unshared in this step. Make
sure that the settings are correct before you proceed.
3. Click APPLY.
If you want to make more features unshared after you click APPLY, simply
click NO next to them and click APPLY again. If you change your mind and
want to share features that you previously chose not to share, you must delete
the cluster and create a new one with the desired settings.

Once the cluster is active, you see the following message each time you log
into a cluster node as admin and navigate to a configuration page of a feature
that is cluster sharable:
This feature is associated with cluster id 10.
Any changes made would be local to this cluster node only.
The changes may be overwritten by cluster configuration.
This message alerts you that settings for this feature can be changed by a
cluster administrator.
After You Create a Cluster
Whenever you use Cluster Voyager (or the CCLI), you can remove features
from the list of ones that are cluster sharable. You can do this on any node.
However, Nokia recommends that you avoid doing this. You should set up the
appropriate feature sharing when you create a cluster and then leave it
unchanged.
If a feature is shared and you want to reconfigure it on all the cluster nodes,
use Cluster Voyager or the CCLI. Any changes you make are implemented on
all the nodes automatically.
Making the Cluster Active
Nokia recommends that you configure a firewall and or VPN on the node
before you activate the cluster. For more information, see Check Point FW-1
documentation and Chapter 4, “Configuring NGX for Clustering.”
Note
If you do not configure a firewall on the node before you activate the
cluster, you must click DISABLE next to ENABLE MONITORING OF FW-1/
VPN-1? before you activate the cluster. After the cluster is active,
change this setting to ENABLE. When this is set to ENABLE, the cluster
monitors the firewall. If the firewall fails on a node, that node drops out of
the cluster and stops forwarding traffic.
Before you activate the cluster, click SAVE to store all the cluster
configuration settings in the configuration database on the hard disk.
To make the cluster active, click UP in the CLUSTER STATE field of the
Cluster Status table.
You can make the cluster active only if the node has:
􀂄 No VRRP or router services
􀂄 At least two configured interfaces participating in the cluster, including
one primary interface
You receive error messages if the node does not meet these requirements.
Adding a Node to a Cluster
It is very easy to add Nokia appliances to an existing cluster. There are two
methods you can use:
􀂄 Joining (automatic configuration). This is the recommended method
because:
􀂄 The only tasks you must do on the joining systems are:
􀂄 Configure interfaces with IP addresses in each of the networks the
cluster will connect to
􀂄 Supply an IP address (a real addresses or a cluster IP address) that
is already part of the cluster when joining the cluster
􀂄 Manual configuration. If you use this method, you must supply more
information so that the system can join the cluster. Manually adding
nodes is very similar to the process of creating a cluster configuration on
the first node, and you must make sure to enter the appropriate settings
identically to how you entered them on the first node.
If you add a node manually, do not make any changes under JOIN-TIME
SHARED FEATURE CONFIGURATION.
You might want to add a node manually if both of the following
conditions are true:.

The existing nodes are running NGX and firewall monitoring is
enabled on them.
􀂄 NGX is not running on the system you are adding.
If you try to add the system to the cluster using the join method under
these conditions, it will not join because NGX is not running on it. In this
situation you could manually add the system to the cluster by disabling its
firewall monitoring.
Caution
For security reasons, you should never add a system that is not
running NGX to a cluster that is in service. This should only be done
in a test environment.
Recommended Procedure
Nokia recommends that you follow this general procedure when building a
cluster:
1. Fully configure the first cluster node and make sure that all the
appropriate features are cluster sharable.
2. Make sure that all of the join-time shared features are configured
appropriately on the first node.
Remember that joining nodes inherit the configuration settings for each
cluster sharable feature.
3. Create a cluster on another system.
4. Join the other system to the cluster.
Note
This is the most efficient approach to building a cluster and will configure
all the cluster nodes consistently.

Joining a System to a Cluster
To join a system to a cluster, perform this simple procedure:
1. On the main configuration page, click Interfaces to display the Interface
Configuration page.
2. Configure interfaces with IP addresses in each of the networks used by
the cluster and activate the interfaces.
3. Click TOP.
4. Under Traffic Management Configuration, click Clustering Setup to
display the Clustering Setup Configuration page.
5. Enter the ID of the existing cluster.
6. Enter the password for the user cadmin in both password fields.
Note
This must be the same password that you entered for cadmin when
you created the cluster on the first node.
7. Click APPLY
8. In the CLUSTER NODE ADDRESS field, enter an IP address that meets the
following criteria:
􀂄 You should use an address of an interface on the cluster node that you
configured first.
Note
Using an interface on the first system that you configured for
clustering each time you join another system will make sure that
all nodes are configured appropriately.
􀂄 The interface must be one of the cluster interfaces.
􀂄 You should use the “real” address of the interface—not its cluster IP
address. (If the cluster is in forwarding mode and you supply a cluster

IP address for joining purposes, the joining system will copy
configuration settings from the master node, which might not be the
one you want to copy the settings from.)
9. Click JOIN.
􀂄 If the node successfully joins the cluster, Voyager displays a number of
new fields.
􀂄 If the node does not successfully join the cluster, you see a message
indicating why. Correct the problem and attempt the join again.

(Ref - IP Clustering Configuration Guide for Nokia IPSO 3.9)

IPSO 3.6 and later lets you create firewall/VPN clusters that provide fault tolerance and dynamic load balancing. A cluster is made up of multiple appliances (nodes) that share common IP addresses, and it appears as a single system to the networks connected to it. A cluster continues to function if a node fails or is taken out of service for maintenance purposes. The connections being handled by the failed node are transferred to one of the remaining nodes. IPSO clusters are also scalable with regard to VPN performance—as you add nodes to a cluster, the VPN throughput improves.

IPSO clusters support a variety of Check Point NGX features, including:
􀂄 Synchronizing state information between firewalls
􀂄 Firewall flows
􀂄 Network address translation
􀂄 VPN encryption

Note
All cluster nodes must run the same versions of IPSO and NGX.
Note
The IP2250 appliance does not support IP clustering.

Supported Appliances
You can implement clusters using the following appliances:
􀂄 IP1260
􀂄 IP1220
􀂄 IP740
􀂄 IP710
􀂄 IP650
􀂄 IP530
􀂄 IP440
􀂄 IP380
􀂄 IP350
􀂄 IP330
􀂄 IP265
􀂄 IP130
Base your choice of appliances on your objectives for creating the cluster:

􀂄 To provide fault tolerance for your firewall or VPN, you can use all these
appliances.
􀂄 To get the full benefits of load balancing firewall traffic, use the IP740.
􀂄 To achieve significant VPN performance improvements, use the IP1260,
IP740, IP710, IP530, IP380, and IP350.
􀂄 The IP130 is suitable for clustering for VPNs only.

Example Cluster
The following diagram shows a cluster with two nodes, firewall A and
firewall B. The cluster balances inbound and outbound network traffic
between the nodes. If an internal or external interface on one of the nodes
fails, or if a node itself fails, the existing connections handled by the failed

node are not dropped—the other node processes them. The other node
continues to function and handle all of the traffic for the cluster.
Routers connected to an IPSO cluster must have appropriate static routes to
pass traffic to the cluster. In this example:
􀂄 The external router needs a static route to the internal network
(192.168.1.0) with 192.168.2.10 as the gateway address.
􀂄 The internal router needs a static route to the external network
(192.168.2.0) with 192.168.1.10 as the gateway address.

The IP addresses shown in boldface are cluster IP addresses, addresses shared
by multiple interfaces in the cluster.
IPSO uses the cluster protocol networks shown in the diagram for cluster
synchronization and cluster management traffic. If a primary cluster protocol
interface fails on a node, the node uses its secondary cluster protocol
interface, and service is not interrupted.
Note
Nokia recommends that these networks be dedicated to this purpose (as
shown here). The ideal configuration is to physically separate the cluster
protocol networks from the production networks. This configuration is
preferable to using separate VLANs on one switch to separate them.
IPSO’s cluster management features allow you to configure firewall A and B
as a single virtual device, and IPSO also lets you easily set up automatic
configuration of cluster nodes.
In this and similar diagrams, switches and hubs are not shown for the sake of
simplicity.
Cluster Management
You can manage all the nodes of a cluster simultaneously by using Cluster
Voyager. This is a feature that lets you configure a cluster as a single virtual
device. You can make configuration changes once and have them take effect
on all the cluster nodes. You can also use the Cluster CLI (CCLI) to manage a
cluster, and much of the information in this section applies to the CCLI as
well. See the IPSO CLI Reference Guide for more information about the
CCLI.
The following list explains the difference between Voyager/CLI and Cluster
Voyager/CCLI:
􀂄 Voyager and the CLI manage a single IPSO system.

􀂄 Cluster Voyager and the cluster CLI manage multiple clustered IPSO
systems as if they are a single system.
This diagram illustrates the difference.

Any changes you make in Voyager or Cluster Voyager are immediately
reflected in the CLI and CCLI. The reverse is also true—settings made in the
CLI or CCLI are immediately reflected in Voyager or Cluster Voyager.
Cluster Terminology
This section explains the terms used in IPSO clustering.When applicable, it
references the example cluster.
CCLI: Cluster CLI—A feature that lets you centrally manage all the nodes in
a cluster as a single virtual system using one command-line session.
Cluster administrator: When you log into a Nokia appliance with the user
name cadmin, you log in as a cluster administrator.
􀂄 If you are using a browser, the system displays Cluster Voyager.

􀂄 If you are using the command shell and enter clish, the system starts the
CCLI.
Cluster ID: A user-specified number that uniquely identifies the cluster
within the broadcast domain. Every node shares this ID number. The range is
0 to 65535.
If there is more than one cluster in the same network, each cluster must have a
unique ID. In the example cluster, the ID is 10.
Cluster IP address: A unicast IP address that every node in the cluster
shares. Each interface participating in a cluster must have an associated
cluster IP address.
The example cluster has four cluster IP addresses:
􀂄 192.168.1.10 is the cluster IP address of the internal interfaces.
􀂄 192.168.2.10 is the cluster IP address of the external interfaces.
􀂄 192.168.3.10 is the cluster IP address of the primary cluster interface.
􀂄 192.168.4.10 is the cluster IP address of the secondary cluster interface.
Cluster MAC address: A MAC address that the cluster protocol installs on
all nodes. Only the cluster master responds to ARP requests that routers send
to cluster IP addresses. The cluster MAC address makes the cluster appear as
a single device at the OSI layer two level.
Cluster master: The master node plays a central role in balancing the traffic
among the cluster nodes.The cluster determines which node is the master
according to the following criteria.
􀂄 In forwarding mode the master receives all the incoming packets and may
forward them to the other nodes for processing.
In this mode the master is the active node with the highest performance
rating. If performance ratings are equal on all nodes, the master is the first
node of the cluster.
􀂄 In multicast mode all the nodes receive all the incoming packets. The
master determines which nodes should process each packet and provides
that information to the other nodes. Nodes simply drop packets that they
should not process In this mode, the master is the node that joins the cluster first.
Note
See “Clustering Modes” for more information about this feature.
Cluster member: A cluster node that is not the master.
Cluster node: Any system that is part of a cluster, regardless of whether it is a
member or the master.
Cluster protocol networks/interfaces: The cluster protocol networks are
used for cluster synchronization and cluster management traffic. You create
these networks by connecting cluster protocol interfaces. You must create a
primary cluster protocol network, and Nokia recommends that you also create
a secondary cluster protocol network for redundancy.
You specify which interfaces are cluster protocol interfaces by selecting from
the configured Ethernet interfaces. (Only Ethernet interfaces can participate in
a cluster.)
Note
These interfaces should be internal, and Nokia also recommends that you
use separate networks to carry cluster protocol traffic and production
traffic. The ideal configuration is to physically separate the cluster
protocol networks from the production networks (connect them using
different switches). This configuration is preferable to using separate
VLANs on one switch to separate them and is the configuration shown in
the example cluster.
The cluster protocol interfaces can also be used for NGX synchronization
traffic. For more information about how to configure NGX for clustering, see
Chapter 4, “Configuring NGX for Clustering.”
The following list explains the roles of primary and secondary cluster
interfaces:

􀂄 Primary cluster protocol network/interface: Each node must be
connected to the primary cluster protocol network. The interface a node
uses to connect to this network is its primary cluster protocol interface. In
the example cluster, the primary interface is eth-s3p1.
If you do not use a dedicated network as the primary network—that is, if
the primary network also carries data traffic, see “If You Do Not Use
Dedicated Cluster Protocol Networks” on page 22 and Chapter 4,
“Configuring NGX for Clustering” for configuration information.
If the primary interface fails on a node and you have not configured a
secondary network, the node is removed from the cluster. If it is the
master, one of the remaining nodes becomes the new master.
􀂄 Secondary cluster protocol network/interface: Each node may also be
connected to an (optional) secondary cluster protocol network. The
interface a node uses to connect to this network is its secondary cluster
protocol interface. In the example cluster, the secondary interface is
eth-s4p1.
If a primary interface fails on a member, the cluster synchronization and
management traffic fails over to the secondary interface. In this event, the
other nodes are not affected—they continue to use their primary
interfaces to communicate with the master. If a primary interface fails on
the master, all the other nodes must use the secondary protocol network to
communicate with the master.
If the primary and secondary cluster protocol interface fails on a node, the
node is removed from the cluster. If it is the master, one of the remaining
nodes becomes the new master.
Cluster Voyager: A feature that lets you centrally manage all the nodes in a
cluster as a single virtual system using one browser session.
Joining: When becoming part of a cluster, a system can copy a variety of
configuration settings from another cluster node (so you don’t have to
configure these settings manually). This is called joining. When a system
joins a cluster, it copies the configuration settings of the join-time shared
features. Joining saves you time by allowing you to configure one node and

then have the other nodes copy the appropriate configuration settings when
they join the cluster.
Join-time shared features: You may want to have many configuration
settings be identical on each cluster node. Voyager makes this easy for you by
letting you specify which features will be configured the same on all cluster
nodes. The features that can be configured this way are called join-time
shared features, meaning that their configurations can be shared across cluster
nodes during the joining process.
Clustering Modes
IPSO clusters have three modes of operation. Nokia provides this choice so
that IPSO clusters can work in any network environment:
􀂄 In multicast mode each cluster node receives every packet sent to the
cluster and decides whether to process it based on information it receives
from the master node. If the node decides not to process the packet
(because another node is processing it), it drops the packet.
This mode usually offers better throughput because it uses the bandwidth
of the production networks more efficiently.
Multicast mode uses multicast MAC addresses for each of the nodes. If
you use this mode, routers and servers adjacent to the cluster (either
connected directly or through a switch or hub) must be able to accept
ARP replies that contain a multicast MAC address. Switches connected
directly to the cluster must be able to forward packets destined for a single
(multicast) MAC address out multiple switch ports. See “Considerations
for Clustering” for more information about the requirements for routers
and switches when using multicast mode.
When you use this mode, the cluster MAC addresses are in the form
01:50:5A:xx:xx:xx, in which the last three bytes are the last three bytes of
the appropriate cluster IP address in hexadecimal.
􀂄 Multicast mode with IGMP offers the benefits of multicast mode with an
additional improvement. When you use multicast mode (without IGMP),

the switches connected to the cluster might broadcast the data frames sent
to the multicast MAC addresses of the cluster (depending on their
configuration). This means that any other devices attached to the same
switches as the cluster also receive the traffic that is sent to the cluster. If
the switches perform IGMP snooping (elicit or listen for IGMP
messages), you can prevent this from happening by using multicast mode
with IGMP.
When you use this mode, each cluster interface joins an IP multicast
group, and IPSO bases the cluster multicast MAC addresses on the IP
multicast group addresses. The cluster MAC addresses are in the form
01:00:5E:xx:xx:xx, in which the fourth byte is the cluster ID and the last
two bytes are the last two bytes of the multicast group address.
You can change the default IP multicast group addresses assigned by
IPSO. If you do so, the new addresses must be in the range 239.0.0.0 to
239.255.255.255. (See RFC 2365 for information about this range of
addresses.)
􀂄 In forwarding mode the master cluster node initially receives all the
packets sent to the cluster and decides which node should process the
packet. If it decides that another node should handle the packet, it
forwards the packet to that node. Otherwise, the master processes the
packet itself.
Use forwarding mode if the routers and switches on either side of the
cluster do not support multicast MAC addresses.
Note
All cluster nodes must use the same mode.
Caution
Avoid changing the cluster mode while a cluster is in service. If you
change the cluster mode of a single node, the node leaves the
cluster. If you change the mode on all the nodes (using Cluster
Voyager or the CCLI), the cluster dissolves and reforms and is out of
service temporarily.
Considerations for Clustering

Network Environment
􀂄 You can use static routing, OSPF, BGP, or PIM to forward traffic through
a cluster.
􀂄 If you use static routing, devices that need to send traffic through a
cluster must have a static route that uses the appropriate cluster IP
address (internal or external) for the route’s gateway address. For
example, a router on the internal side of a cluster should use an
internal cluster IP address as the gateway address.
􀂄 You cannot use OSPFv3 in a cluster.
􀂄 If you use OSPF, only the master exchanges OSPF messages with the
external routers.
􀂄 A cluster cannot use OSPF or BGP to forward traffic over VPN
tunnels.
􀂄 If you use PIM, see “PIM Support for IP Clustering” in the PIM
documention for details about how to configure it.
􀂄 The following items apply if you use BGP with a cluster.

􀂄 BGP runs only on the master node. If a failover occurs, BGP stops
running on the failed master and establishes its peering
relationships on the new master.
􀂄 You must configure a cluster IP address as a local address.
􀂄 Nokia recommends that you configure BGP so that peer traffic
does not run on the cluster protocol interfaces.
Caution
Nokia strongly recommends that you not configure a dynamic routing
protocol on the primary or secondary cluster protocol interfaces.
􀂄 If you use a multicast mode, adjacent devices (either connected directly or
through a switch or hub) must be able to accept ARP replies that contain a
multicast MAC address. See “Multicast ARP Replies on Adjacent
Routers” on page 71 for instructions about how to configure a Nokia
appliance to accept these replies.
Note
If there is no router between the cluster and host systems (PCs or
workstations), the hosts must be able to accept ARP replies with
multicast MAC addresses. You can avoid this requirement by adding
a static ARP entry to each host that includes the cluster IP address
and multicast MAC address of the internal cluster interface.
􀂄 If you use a multicast mode, the switches connected to the cluster nodes
must be able to forward packets destined for a single (multicast) MAC
address out multiple switch ports simultaneously. Many switches do this
by default.
􀂄 If you use a two-node cluster, use switches (recommended) or hubs to
connect the cluster protocol networks. This will ensure proper failover in
the event that one of the nodes drops out of the cluster. Do not directly
connect the cluster protocol interfaces using a crossover cable.
􀂄 For performance purposes, Nokia recommends that you do not use hubs
to connect a cluster to user data networks. If possible, use switches for these connections. (If you need to troubleshoot a cluster that uses a
multicast mode, you might want to temporarily replace switches with
hubs to simplify your configuration.)
􀂄 You can create multiple clusters in the same LAN or VLAN (broadcast
domain). The clusters are distinguished by their cluster IDs.
Other Considerations
􀂄 If a cluster will be in service as soon as it is activated, you should
configure and enable NGX on each node before they become part of the
cluster. Add nodes to the Check Point cluster (using Check Point
software) after they have successfully joined the IPSO cluster.
􀂄 Transparent mode is not supported on cluster nodes.
􀂄 Router services are not supported, with the exception of NTP.
􀂄 An IPSO system cannot participate in more than one cluster at one time.
􀂄 IPSO clusters support:
􀂄 Multiple internal and external network connections
􀂄 10/100 mb or gigabit Ethernet LAN connections
􀂄 The primary and secondary cluster protocol networks should have
bandwidth of at least 100 mbps.
􀂄 IPSO clusters do not support network types other than Ethernet.
All of the interfaces on a cluster node do not have to participate in the
cluster. Interfaces that do not participate in the cluster can be network
types other than Ethernet.
􀂄 All the nodes must have the same number of interfaces participating in the
cluster, and the cluster interfaces must be connected to the same networks.
􀂄 If you configure Gigabit Ethernet interfaces on different IP cluster nodes
with different MTU values and also run OSPF in the cluster, OSPF routes
are lost if a failover occurs between the nodes with different MTU
values.To prevent this problem, make sure that the MTU values are the
same on all cluster nodes with Gigabit Ethernet interfaces.

If You Do Not Use Dedicated Cluster Protocol
Networks
If you do not use separate networks for cluster protocol traffic and production
traffic, IPSO’s cluster protocol messages are propagated throughout the
production networks. This happens whenever you use the same physical links
for cluster protocol traffic and production traffic–that is, it occurs even if you
use VLANs (trunking) to segregate the traffic. This is an unproductive use of
bandwidth because cluster protocol messages are used only by IPSO cluster
nodes.
You can prevent the cluster protocol messages from being spread across the
production networks by using multicast mode with IGMP and connecting the
networks with switches that use IGMP snooping. You usually need to enable
IGMP for specific switch ports or VLANS.
IPSO sends out IGMP membership reports for the cluster protocol multicast
group. A switch using IGMP snooping will then forward cluster protocol
messages only to group nodes–that is, the other cluster nodes. It will not
forward the cluster protocol traffic to ports that are not connected to cluster
nodes.
Note
If you enable IGMP snooping on the switch, also enable IGMP queries
and set a query interval of 30 or fewer seconds. If you enable IGMP
snooping but do not enable queries, problems can occur when a system
leaves and rejoins a cluster.
The ideal configuration is to physically separate the production and cluster
protocol networks (connect them using different switches). If you configure a
cluster this way, the cluster protocol messages will not appear on your
production networks even if the switches on the data networks do not support
IGMP snooping. This configuration is preferable to using separate VLANs on
one switch to separate the networks.

(Ref taken by Nokia ipso 3900 series pdf)

1. Acquire the image v5_05.241 (128 bit) in the optimized format (.tar extension).

2. Connect your laptop or PC to Contivity via a cross cable to contivity’s private LAN interface.

3. Make sure that your Laptop’s or PC’s IP address is in the same range as that of Contivity’s Management IP address.

4. Then open the Internet Explorer (Version 6) and using the Mgmt. IP of the Contivity open the web based mgmt. of Contivity.

5. Start the FTP server in your Laptop or PC and configure a user and its password.

6. Give the path of the image file in the FTP server to the folder in which you have stored the optimized (.tar file) image file.

7. Please note that the Optimized image file with .tar extension has one more extension .gz which is hidden.

8. Now in web based mgmt. of Contivity go to Admin  upgrades.

9. In this screen you need to enter the following info:

Host IP  IP address of your Laptop or PC running FTP server.
Path  Just give the image file name with .tar.gz extension.
Version  name of the image but without the .tar.gz extension.
User name and password of the FTP server.

Make sure that in the Internet Explorer POP Up’s are allowed

10. After entering all the info. correctly and after making sure that the FTP server is running, click on the Retrieve button on that page.

11. A small window will open showing the status of the image copied to the Contivity.

12. When in this window there is a display that the transfer completed successfully, you can close this small window.

13. Now that you have dumped the image to the Contivity hard disk, you need to apply this image.

14. In the same path (Admin  Upgrades) there will be a drop down box where you can see the new image that you just transferred to the Contivity.

15. Select that new image version and click Apply.

16. Wait for some time, the new image will be applied and the Contivity will reboot automatically.

17. After the Contivity is booted again access the Contivity via web based and go to Status  System and verify the new image version.