Smokeping Configuration in Ubuntu

Smokeping is a latency measurement tool. It sends test packets out to the net and measures the amount of time they need to travel from one place to the other and back. For every round of measurement smokeping sends several packets.

Prerequisite 

This installation will require web service to be installed, for me am going to use Apache,but also it will need mail service for sending the email am going to use sendmail, run the following command to install web and mail service

$ sudo apt-get update
$ sudo apt-get install apache2
$ sudo apt-get install sendmail

Install Smokeping

$ sudo -s
#
# apt-get install smokeping

For Ubuntu 14.04: you need to install a symlink to the apache2 config

# ln -s /etc/smokeping/apache2.conf /etc/apache2/conf-available/smokeping.conf
# a2enconf smokeping

Also, the CGI module needs to be enabled in Apache:

# a2enmod cgi

Finally, reload the Apache configuration:

# service apache2 reload

Then point your web browser at

http://X.X.X.X/smokeping/smokeping.cgi

where X.X.X.X is your server IP

Initial Configuration

# cd /etc/smokeping/config.d
# ls -l
Output:
total 40K
drwxr-xr-x 2 root root 4.0K Oct  1 13:12 .
drwxr-xr-x 3 root root 4.0K Oct  1 13:12 ..
-rw-r--r-- 1 root root  177 Jan 28  2014 Alerts
-rw-r--r-- 1 root root  237 Jan 28  2014 Database
-rw-r--r-- 1 root root  489 Jan 28  2014 General
-rw-r--r-- 1 root root  225 Jan 28  2014 pathnames
-rw-r--r-- 1 root root  876 Jan 28  2014 Presentation
-rw-r--r-- 1 root root   50 Jan 28  2014 Probes
-rw-r--r-- 1 root root  147 Jan 28  2014 Slaves
-rw-r--r-- 1 root root  380 Jan 28  2014 Targets

The files that you'll need to change, at a minimum, are:
-Alerts
-General
-Probes
-Targets

Now open the General file with your favoirite editor 

# vi General

Change the following lines;

owner    = NOC
contact  = sysadmin@localhost
mailhost = localhost
cgiurl   = http://localhost/smokeping.cgi
# specify this to get syslog logging
syslogfacility = local5

Save the file and exit. Now let's restart the Smokeping service to verify that no mistakes have been made before going any further:

# service smokeping restart

Now open the Alerts file 

# vi Alerts

 
Change the following lines:

to = root@localhost
from = smokeping-alert@localhost

Save the file and exit. Restart Smokeping:

# service smokeping reload

Note: When you do some changes there is not need of restarting smokeping, just reload it for it to see configuration.

  Configuring monitoring of devices

For device configuration, most of configuration is done on
/etc/smokeping/config.d/Targets file.


As an example am going to configure some few devices where am going to have two groups Local devices and Public Servers,

# vi /etc/smokeping/config.d/Targets

Add the following to creates two groups:

+ LocalDevices
menu = LocalDevices
title = Local Network Devices

+ InternetServers
menu = InternetServers
title = InternetServers

Then add devices on those two groups :

+ LocalDevices
menu = LocalDevices
title = Local Network Devices

++MyRouter
menu = Router
title = Router
host = 100.100.100.100

++DC
menu = DC
title = Domain Controller
host = 172.16.0.1

+ InternetServers
menu = InternetServers
title = InterentServers

++Google
menu = Google
title = Google
host = google.com

++Yahoo
menu = Yahoo
title = Yahoo
host = yahoo.com

++Facebook
menu = Facebook
title = Facebook
host = facebook.com

 

OK. Let's see if we can get Smokeping to stop and start with the changes we have made, so far. Save and exit from the Targets file. Now try doing:

# service smokeping reload

If you see error messages, then read them closely and try to correct the problem in the Targets file. In addition, Smokeping is now sending log message to the file /var/log/syslog. You can view what Smokeping is saying by typing:

# tail /var/log/syslog

If you want to see all smokeping related messages in the file /var/log/syslog you can do this:

# grep smokeping /var/log/syslog

If there are no errors you can view the results of your changes by going to:

http://X.X.X.X/smokeping/smokeping.cgi

where X.X.X.X is your server IP

That's It.

 

How to enable/Activate Checkpoint SmartLog in R76 and above

1. Open your SmartDashboard, double click on Management Server Object.
2. Make sure in General Properties  Logging & Status should be checked.

3. Go to Log and Check Enable SmartLog option.

4. Go to Storage and Set the number of days to keep Indexing.

5. Then click on OK and Install the Policy on all the Security Gateways which are supposed to send logs to this Log Server.

Configuring the Start date/time for logs indexing

1.  Login to your management server CLI console with expert level permission.
2.  Run the command:
[Expert@HostName]# cp $SMARTLOGDIR/smartlog_settings.txt $SMARTLOGDIR/smartlog_settings.txt_ORIGINAL

3.  Run the command:
[Expert@HostName]# vi $SMARTLOGDIR/smartlog_settings.txt

4.  Delete these lines:
time_restriction_for_fetch_all (<existing_data>)
time_restriction_for_fetch_all_disp (<existing_data>)

5.  Save and exit from VI editor
6.  Backup and edit $SMARTLOGDIR/conf/smartlog_settings.conf and change the number of days of logs to re-index:
[Expert@HostName]# cp $SMARTLOGDIR/conf/smartlog_settings.conf $SMARTLOGDIR/conf/smartlog_settings.conf_ORIGINAL
[Expert@HostName]# vi $SMARTLOGDIR/conf/smartlog_settings.conf

:num_days_restriction_for_fetch_all_integrated (<days>)

<days> is the last number of days of logs to be indexed by the SmartLog server. For example, to re-index logs from the last 365 days of logs, give a value of 365.

Note: - To reduce the performance impact while re-indexing, Checkpoint recommend that you only the number of days of logs that you need.

7.  Backup and remve $SMARTLOGDIR/data/FetchedFiles
[Expert@HostName]# cp $SMARTLOGDIR/data/FetchedFiles $SMARTLOGDIR/data/FetchedFiles_ORIGINAL
[Expert@HostName]# rm -i $SMARTLOGDIR/data/FetchedFiles

8.  Restart SmartLog services:
[Expert@HostName]# smartlogstop
[Expert@HostName]# smartlogstart

9.  Verify smartlog_settings.txt shows the earliest date of re-index
[Expert@HostName]# grep restriction $SMARTLOGDIR/smartlog_settings.txt

10. Login to SmartLog and check the logs there.

(Note: It is possible when you first time open the SmartLog you will not be able to see all the past days logs, it is due to Indexing time. Indexing takes time depending on the number days and volume of logs in each log file need to be indexed).

11. If you wish to check which file has been already indexed during indexing, use this command:
[Expert@HostName]# cat /var/log/opt/CPSmartLog-RXX/data/FetchedFiles

(Note: in CPSmartLog-RXX, RXX is version of Checkpoint e.g. R77)

12. That's it.

How to Factory Restore Stonegate Firewall

To reset to factory settings

1. Connect to the engine command line.
2. (Re)start the appliance:
• If the appliance is powered on, press Enter, log in as the user root with the password you have set for the appliance, and issue the command reboot.
3. Wait until a list of partitions is shown. The currently active partition is highlighted. Press Enter. A list of available commands opens.
4. Select System Restore Options and press Enter.
5. Type 1 and press Enter to clear the settings. A confirmation prompt is shown.
6. Type YES and press Enter to perform the reset. If you decide to cancel the operation, type NO and press Enter.

Symmetric Encryption, Asymmetric Encryption, and Hashing

A fundamental topic of IT security that often gives people difficulty is understanding the difference between symmetric, asymmetric encryption, and hashing. While each has specific uses, a robust communications encryption solution will typically implement all three.

Symmetric Encryption

Symmetric encryption may also be referred to as shared key or shared secret encryption. In symmetric encryption, a single key is used both to encrypt and decrypt traffic. 

Common symmetric encryption algorithms include DES, 3DES, AES, and RC4. 3DES and AES are commonly used in IPsec and other types of VPNs. RC4 has seen wide deployment on wireless networks as the base encryption used by WEP and WPA version 1.

Symmetric encryption algorithms can be extremely fast, and their relatively low complexity allows for easy implementation in hardware. However, they require that all hosts participating in the encryption have already been configured with the secret key through some external means.

Asymmetric Encryption

Asymmetric encryption is also known as public-key cryptography. Asymmetric encryption differs from symmetric encryption primarily in that two keys are used: one for encryption and one for decryption. The most common asymmetric encryption algorithm is RSA.

Compared to symmetric encryption, asymmetric encryption imposes a high computational burden, and tends to be much slower. Thus, it isn't typically employed to protect payload data. Instead, its major strength is its ability to establish a secure channel over a nonsecure medium (for example, the Internet). This is accomplished by the exchange of public keys, which can only be used to encrypt data. The complementary private key, which is never shared, is used to decrypt.

Robust encryption solutions such as IPsec implement the strengths of both symmetric and asymmetric encryption. First, two endpoints exchange public keys, which allows for the setup of a slow but secure channel. Then the two hosts decide on and exchange shared symmetric encryption keys to construct much faster symmetric encryption channels for data.

Hashing

Finally, hashing is a form of cryptographic security which differs from encryption. Whereas encryption is a two step process used to first encrypt and then decrypt a message, hashing condenses a message into an irreversible fixed-length value, or hash. Two of the most common hashing algorithms seen in networking are MD5 and SHA-1.

Hashing is used only to verify data; the original message cannot be retrieved from a hash. When used to authenticate secure communications, a hash is typically the result of the original message plus a secret key. Hashing algorithms are also commonly used without a secret key simply for error checking. You can use the md5sum and sha1sum utilities on a Linux or Unix machine to experiment with hashing.

$ echo -n This is a secret message. | md5sum
39de572a4d05b1ad6552dcfee90f4d20  -
$ echo -n This is a secret message. | sha1sum
e35c5046b5fe69488ce0ab14c5761d785995ee79  -

Another example of MD5 hashing can be seen in IOS' secret passwords, which implement a random salt to avoid duplicate hashes should two users by chance select the same password.

(Note: Thanks to Packetlife.net or Jeremy Stretch for such a useful post.)

How to reset IPCop root password

Follow the below steps: -

1. At the boot menu, press <TAB> to drop into edit mode
2. At the end of the line add: init=/bin/bash
3. Press <ENTER> to continue boot
4. When booting has finised enter: mount -o remount rw /
5. Enter: passwd
6. eEter the new password
7. Repeat the new password
8. Restart IPCop (ipcopreboot does not work and we neither have init nor reboot ...) Use Clt+Alt+Del
9. That's it.

How to add Proxy ARP in Checkpoint local.arp file?

The best way to add a proxy arp is as follows:

1) Login to the gateway(s) that requires the proxy arp.
2) Use the following command to add an arp to the local.arp file. This will append new arps for you without having to use Vi.

echo “192.168.1.2 AA:BB:CC:DD:EE” >> $FWDIR/conf/local.arp

Make sure that the mac address you use is from the physical gateway. For instance in a HA Active/Standy cluster xl setup you will need to use the MAC from each clusters’ interface respectively.

Push the policy after you add the arps.

You only need a route for the NAT address if you dont have “translate destination on client side enabled”

Command Line Syntax for Secure Copy (scp)

Copy the file "foobar.txt" from a remote host to the local host

$ scp your_username@remotehost.edu:foobar.txt /some/local/directory

Copy the file "foobar.txt" from the local host to a remote host

$ scp foobar.txt your_username@remotehost.edu:/some/remote/directory

Copy the directory "foo" from the local host to a remote host's directory "bar"

$ scp -r foo your_username@remotehost.edu:/some/remote/directory/bar

Copy the file "foobar.txt" from remote host "rh1.edu" to remote host "rh2.edu"

$ scp your_username@rh1.edu:/some/remote/directory/foobar.txt \
your_username@rh2.edu:/some/remote/directory/

Copying the files "foo.txt" and "bar.txt" from the local host to your home directory on the remote host

$ scp foo.txt bar.txt your_username@remotehost.edu:~

Copy the file "foobar.txt" from the local host to a remote host using port 2264

$ scp -P 2264 foobar.txt your_username@remotehost.edu:/some/remote/directory

Copy multiple files from the remote host to your current directory on the local host

$ scp your_username@remotehost.edu:/some/remote/directory/\{a,b,c\} .
$ scp your_username@remotehost.edu:~/\{foo.txt,bar.txt\} .

scp Performance

By default scp uses the Triple-DES cipher to encrypt the data being sent. Using the Blowfish cipher has been shown to increase speed. This can be done by using option -c blowfish in the command line.

$ scp -c blowfish some_file your_username@remotehost.edu:~

It is often suggested that the -C option for compression should also be used to increase speed. The effect of compression, however, will only significantly increase speed if your connection is very slow. Otherwise it may just be adding extra burden to the CPU. An example of using blowfish and compression:

$ scp -c blowfish -C local_file your_username@remotehost.edu:~

How to change the Keyboard-layout in Checkpoint running on SPLAT

edit the /etc/sysconfig/keyboard file, for standard US keyboard, it should look like this:

KEYBOARDTYPE="pc"
KEYTABLE="us"

Note: If the file doesn't exist it can be created

Palo Alto, Accredited Configuration Engineer (ACE)

The Accredited Configuration Engineer (ACE) exam tests your knowledge of the core features and functions of Palo Alto Networks next-generation firewalls. The ACE exam is web-based and consists of 50 multiple-choice questions. The exam is not timed, and you can retake it as many times as necessary to earn a passing score. For more Information you can click here

Ports needed by ePO 4.x and ePO 5.x for communication through a firewall

The following tables display the ports needed by ePO for communication through a firewall:

Bi-directional means that a connection can be initiated from either direction
Inbound means the connection is initiated by a remote system
Outbound means the connection can be initiated by the local system

ePO 4.6.x and 5.x

Port	Default	Description	Traffic Direction
Agent-server communication port	80	TCP port used by the ePO Server service to receive requests from agents.	Inbound connection to the Agent Handler and the ePO server from the McAfee Agent. Inbound connection to the ePO server from the remote Agent Handler.
Agent-server communication secure port (4.5 and later agents only) Software Manager	443	TCP port used by the ePO Server service to receive requests from agents and remote Agent Handlers. TCP port used by the ePO server's Software Manager to connect to McAfee.	Inbound connection to the Agent Handler and the ePO server from the McAfee Agent. Inbound connection to the ePO server from the remote Agent Handler.
Agent wake-up communication port SuperAgent repository port	8081	TCP port used by agents to receive agent wakeup requests from the ePO server or Agent Handler. TCP port used by SuperAgents configured as repositories to receive content from the ePO server during repository replication, and to serve content to client machines.	Inbound connection from the ePO server/Agent Handler to the McAfee Agent. Inbound connection from client machines to SuperAgents configured as repositories.
Agent broadcast communication port	8082	UDP port used by SuperAgents to forward messages from the ePO server/Agent Handler.	Outbound connection from the SuperAgents to other McAfee Agents.
Console-to-application server communication port	8443	TCP port used by the ePO Application Server service to allow web browser UI access.	Inbound connection to the ePO server from ePO Console.
Client-to-server authenticated communication port	8444	Used by the Agent Handler to talk to the ePO server to get required information (like LDAP servers).	Outbound connection from remote Agent Handlers to the ePO server.
SQL server TCP port	1433	TCP port used to communicate with the SQL server. This port is specified or determined automatically during the setup process.	Outbound connection from the ePO server/Agent Handler to the SQL server.
SQL server UDP port	1434	UDP port used to request the TCP port that the SQL instance hosting the ePO database is using.	Outbound connection from the ePO server/Agent Handler to the SQL server.
LDAP server port	389	TCP port used to retrieve LDAP information from Active Directory servers.	Outbound connection from the ePO server/Agent Handler to an LDAP server.
SSL LDAP server port	636	TCP port used to retrieve LDAP information from Active Directory servers.	Outbound connection from the ePO server/Agent Handler to an LDAP server.

ePO (Ports/Traffic Quick Reference)

ePO Server

Default	Protocol	Traffic Direction
80	TCP	Inbound connection to the ePO server
389	TCP	Outbound connection from the ePO server
443	TCP	Inbound/Outbound connection to/from the ePO server
636	TCP	Outbound connection from the ePO server
1433	TCP	Outbound connection from the ePO server
1434	UDP	Outbound connection from the ePO server
8081	TCP	Outbound connection from the ePO server
8443	TCP	Inbound connection to the ePO server
8444	TCP	Inbound connection to the ePO server

Remote Agent Handler(s)

Default Port	Protocol	Traffic Direction
80	TCP	Inbound/Outbound connection to/from the Agent Handler
389	TCP	Outbound connection from the ePO server
443	TCP	Inbound/Outbound connection to/from the Agent Handler
636	TCP	Outbound connection from the ePO server
1433	TCP	Outbound connection from the ePO server
1434	UDP	Outbound connection from the ePO server
8081	TCP	Outbound connection from the ePO server
8443	TCP	Outbound connection from the ePO server
8444	TCP	Outbound connection from the ePO server

McAfee Agent

Default Port	Protocol	Traffic Direction
80	TCP	Outbound connection to the ePO server/Agent Handler
443	TCP	Outbound connection to the ePO server/Agent Handler
8081	TCP	Inbound connection from the ePO server/Agent Handler. If the agent is a SuperAgent repository then inbound connection from other McAfee Agents.
8082	TCP	Inbound connection to Agents. Inbound/Outbound connection from/to SuperAgents

SQL Server

Default Port	Protocol	Traffic Direction
1433	TCP	Inbound connection from the ePO server/Agent Handler
1434	UDP	Inbound connection from the ePO server/Agent Handler