Linux System Monitoring

1.You need to determine which process is monopolizing or eating the CPUs. Following command will displays the top 10 CPU users on the Linux system.

# ps -eo pcpu,pid,user,args | sort -k 1 -r | head -10
OR
# ps -eo pcpu,pid,user,args | sort -r -k1 | less

2.http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html

Integrating Hydra With Nessus

Tác động lớn của một byte

TCP là một trong những giao thức phổ dụng nhất của mạng máy tính. Mỗi lần ta click vào một trang web mới là có (ít nhất) một kết nối TCP được thiết lập từ trình duyệt đến máy chủ. Vì thế, hiệu suất hoạt động của TCP ảnh hưởng trực tiếp đến toàn bộ mấy tỉ người dùng Internet. Thiết kế một giao thức phổ dụng như TCP quả thật rất khó, vì thế Cerf và Kahn được giải thưởng Turing rất xứng đáng.

Dù có viễn kiến vĩ đại, Cerf và Kahn hiển nhiên không phải là những người duy nhất đóng góp vào TCP. Họ chỉ đặt một cái nền. Còn trong vòng 40 năm nay có biết bao nhiêu người đã đóng góp vào cải thiện nhiều mặt của TCP. Thật ra chỉ cần đến khoảng cuối những năm 80 là “diện mạo” của TCP đã rất khác so với hồi Cerf và Kahn thiết kết nó.

Xem qua quá trình tiến hóa của TCP, một điều hiển hiện là việc giữ cho một giao thức hoạt động đúng như ý mình muốn thật là nan giải. Có hai lý do chính, đều liên quan đến sự đa dạng. Thứ nhất là sự đa dạng của các loại mục tiêu khác nhau mà ta muốn giao thức đạt được: hiệu suất cao, tính bảo mật tốt, dùng ít tài nguyên mạng và tài nguyên tính toán, xử lý cực nhanh với tốc độ ánh sáng, giữ cho phiên bản mới của giao thức tương hợp với phiên bản cũ, vân vân. Thứ hai là sự đa dạng (và đa nguyên) của những nhóm nghiên cứu và các công ty đóng góp vào cải tiến về lý thuyết và lập trình giao thức trên thực tế. Làm thế nào để đảm bảo rằng TCP do Microsoft lập trình chạy tốt với TCP của Linux, của BSD, của SunOS, MacOSX, cùng với cơ man nào là các phiên bản khác nhau của chúng. Khó nữa là chúng ta không có một bộ khung lý thuyết nào khả thi để có thể xác minh xem một thiết kế giao thức cho trước là thiết kế “tốt”: các bộ phận hoạt động đồng bộ với nhau, các phiên bản hoạt động không ngáng giò nhau, vân vân.

Khó thế đấy. Vậy mà, khi ta click vào http://www.procul.org/blog ta thấy ngay cái blog này. Bất kể ta chạy máy gì, hệ điều hành gì. Nó cho thấy sự tráng kiện (robustness) của giao thức TCP và của các giao thức mạng nói chung.

Thế nhưng, có khi các bộ phận của TCP thật sự không hoạt động đồng bộ với nhau, thậm chí chỉ vì một byte dữ liệu. Khi điều này xảy ra, nếu không hiểu rõ TCP và các ngóc ngách của nó thì không thể hiểu tại sao lại có những hiện tượng “ma quái” như vậy. Câu chuyện sau đây chỉ là một vị dụ.

Chuyện như sau. Một nhóm kỹ sư muốn thử nghiệm hiệu suất hoạt động của một hệ thống Wifi. Họ viết một chương trình nhỏ để gửi dữ liệu giữa hai máy dùng hệ thống Wifi nọ. Chương trình thiết lập một kết nối TCP giữa hai máy, xong rồi bên gửi gửi đi 100KB, bên nhận gửi lại một gói ký nhận nhỏ, rồi bên gửi lại gửi đi 100KB kế tiếp, vân vân. Mục tiêu là thực hiện gửi nhận như vậy liên tục một thời gian xem tốc độ truyền là bào nhiêu.

Kết quả: hệ thống Wifi này trên Windows XP đạt được tốc độ 3.5Mbps, còn trên MacOSX chỉ đạt được 2.7Mbps. Trong ngữ cảnh của họ thì 3.5Mbps là tốt. 2.7Mbps không tốt.

Vậy Windows XP có bộ TCP tốt hơn MacOSX? (Giả sử thẻ mạng và các thứ khác tương tự nhau.)

Không. Sau vài lần nghịch với các tham số. Họ giảm 100KB xuống còn 99,912 bytes (để gửi một đợt trước khi nhận gói xác minh). Về nguyên tắc, thay vì 100KB một vòng, ta thử 99KB một vòng thì tốc độ không nên có thay đổi gì dáng kể. Thế mà tốc độ của MacOSX tự nhiên tăng lên đến 5.2Mbps: hơn Windows và gần gấp đôi tốt độ cũ. Thú vị hơn nữa, nếu thay 99,912 bytes bằng 99,913 bytes một đợt thì tốc độ của MacOSX lại giảm xuống 2.7Mbps như xưa.

1 byte mà có thể tăng tốc TCP của Mac gấp đôi? Chuyện gì xảy ra?

Số là, trong mấy trăm cái mẹo cải thiện hiệu suất được đưa vào TCP trong 40 năm qua, có 4 cái mẹo tương tác với nhau rất độc đáo tạo ra hiện tượng trên.

Để mô tả 4 cái mẹo này, trước hết chúng ta lược qua xem TCP làm việc thế nào. Đại khái, TCP là một giao thức cung cấp dịnh vụ tin cậy cho “khách hàng” là các ứng dụng (như web browser, server, Media player, và rất nhiều các ứng dụng mạng khác). Để tạo ra dịch vụ tin cậy, TCP gửi dữ liệu giữa hai đầu gửi-nhận và bắt bên nhận gửi lại các mẩu xác minh là đã nhận (acknowledgements, viết tắt là ACK). Các mẩu dữ liệu của TCP tiếng Anh gọi là segments. Các mẩu dữ liệu được nhét vào các “gói dữ liệu”, như là các phong bì mà bên trong chứa dữ liệu còn bên ngoài chứa thông tin điều khiển và địa chỉ gửi nhận. Bao bì tốn khoảng 20 bytes, cộng thêm 20 bytes bao bì của mạng nữa là khoảng 40 bytes cho mỗi gói dữ liệu.

Mẹo 1: kích thước từng mẩu dữ liệu. Một phong bì do TCP gửi không thể chứa nhiều dữ liệu quá. Tại vì các gói dữ liệu đi qua nhiều loại mạng khác nhau. Mỗi loại mạng có kích thước gói tối đa khác nhau. Ví dụ mang Ethernet có kích thước tối đa là 1500 bytes, mạng X25 có kích thước gói tối đa là 576 bytes, vân vân. Một trong các lý do mà các mạng giới hạn kích thước gói dữ liệu là vì nếu kích thước gói lớn quá thì mỗi lần đường truyền bị lỗi gì ta phải gửi lại toàn bộ gói. Gói càng lớn thì xác suất nó bị lỗi càng cao, mà gửi lại gói to thì tốn tài nguyên hơn gửi lại gói nhỏ. Thế cho nên, nếu TCP gửi một cái phong bì khổng lồ thì đến mạng có giới hạn kích thước phong bì nó sẽ bị băm nhỏ ra thành nhiều gói nhỏ. Mỗi gói nhỏ tốn một phong bì riêng. Và như thế thì rất tốn. Túm lại, TCP có một biến số gọi là MSS để lưu trữ kích thước mẩu lớn nhất (của một kết nối). Có các thuật toán để xác định MSS nên là bao nhiêu cho mỗi kết nối. Nếu không chạy thuật toán thì trị mặc định là 576 – 40 = 536, trong đó 576 là do X25, còn 40 là kích thước bao bì của TCP/IP như đã nói ở trên. Nếu chỉ truyền trên Ethernet thì MSS nên là 1500-40 = 1460.

Mẹo 2: thuật toán Nagle. Thử tưởng tượng một khách hàng của TCP cứ thích đưa mỗi lần vài bytes cho TCP để gửi qua bên nhận. Các ứng dụng như telnet, ssh, rlogin lấy inputs từ chúng ta. Chúng ta gõ bàn phím rất chậm (tính theo tốc độ máy). Người gõ nhanh nhất thế giới cũng chỉ gõ được khoảng 150 từ một phút, vị chi là khoảng vài chục đến vài trăm mili-giây một ký tự. Do đó, hoàn toàn có khả năng là ứng dụng sẽ “đưa cho” TCP từng ký tự một, cứ khoảng 100-mili giây một ký tự. Mỗi lần tải một mẩu dữ liệu 1 ký tự, TCP phải tốn ít nhất 40 bytes bao bì cho nội dung thư. Tỉ lệ phí hoài là 40/41, gần bằng tỉ lệ phí hoàn cho Vinashin. Rất tốn băng thông! Do đó, hồi 1984 John Nagle đề nghị là TCP nên tích lũy một ít “hàng họ” (nghĩa là, ký tự) trước khi gửi. Ít nhất, nếu có một phong bì gửi trước đó mà chưa có hồi âm thì khoan hẵng gửi phong bì ít hàng hiện tại. Chờ hồi âm của phong bì trước, xong rồi hẵng gửi phong bì mới. Lý do là, trong thời gian chờ hồi âm, nhỡ đâu chú khách hàng lại tuồn thêm cho vài ký tự để đóng chung vào một gói thì đỡ tốn phí vận chuyển. Còn trong trường hợp phong bì đã đầy (MSS) thì gửi luôn không cần chờ.

(Mấy bác chuyên môn đánh áo phông bàn chải bên Đông Âu hồi xưa chắc chắn đã hiểu rõ bài toán đóng hàng này.)

Mẹo 3: hồi âm muộn (Delayed ACK). Ở phía bên nhận, để tiết kiệm phí vận chuyển thì TCP thường cố gắng đóng gói cả hồi âm lẫn dữ liệu chiều ngược (gọi là piggy-backing) gửi chung vào một gói. Ví dụ như sau khi nhận một thư từ browser, web-server đọc lên một file nào đó (index.html chẳng hạn) và gửi lại cho browser. Nếu TCP đừng hồi âm ngay, chờ một xíu cho chú server đọc đĩa, thì có luôn cả index.html mang cùng với hồi âm về. Do đó, chuẩn TCP có cái mẹo hồi âm muộn, bắt bên nhận chờ khoảng 200ms đến 500ms trước khi hồi âm một mẩu dữ liệu từ bên kia. Nhưng nếu trong thời gian chờ mà nhận thêm được một thư nữa thì hồi âm cả hai ngay. (Nếu không, bên kia tưởng thư mất gửi lại mất công lắm.) Đây là luật hồi âm kép.

Mẹo 4: nhãn thời gian (timestamp option). Để đảm bảo độ tin cậy, TCP cần biết xem thư gửi đi đã nhận được chưa. Nếu thư bị mất, hoặc hồi âm bị mất thì không nhận được hồi âm. Do đó, TCP cần có một cái đồng hồ báo mất. Khi đồng hồ reng leng keng thì gửi thư lại. Nếu thời khoảng gửi lại quá bé thì không tốt: tại vì có thể hồi âm đang trên đường về, chưa chi đã gửi lại. Nếu thời khoảng gửi lại quá dài thì cũng không tốt: thư đã mất mà không gửi lại luôn còn chờ gì nữa? Do đó, TCP cần một cơ chế để ước lượng thời gian khứ hồi là bao nhiêu, xong rồi đặt thời khoảng cho đồng hồ gửi lại cỡ chừng thời gian khứ hồi cộng với một khoảng đệm cho chắc. (Thuật toán ước lượng thời khoảng khứ hồi phức tạp hơn một chút, nhưng đại khái là thế.) Làm thế nào để đo thời gian khứ hồi? Cách thứ nhất là gửi thư, rồi khi nhận được hồi âm thì xem đó là thời gian khứ hồi. Nhưng mà nếu thư bị mất, phải gửi lại, rồi nhận được hồi âm, thì mình không biết là hồi âm cho thư cũ hay thư mới. Ngoài ra, nếu bên nhận lại dùng mẹo hồi âm muộn thì ước lượng thời gian khứ hồi của mình bị sai đi. Còn nữa, TCP thường gửi nhiều thư cùng một lúc, và nếu dùng một đồng hồ cho mỗi thư thì rất phức tạp và tốn tài nguyên. Cách thứ hai là mỗi lần gửi thư đi thì dán tem chứa thời điểm hiện tại vào đó. Bên nhận, trước khi hồi âm, lấy tem của thư bỏ vào hồi âm. Khi nhận được hồi âm thì bên gửi chỉ cần lấy thời điểm hiện tại trừ đi giá trị tem là biết thời khoảng khứ hồi. Cách đo thời khoảng khứ hồi dùng nhãn thời gian này tốt hơn, nhưng như thế thì ta lại tốn thêm 12 bytes để làm nhãn và vì thế trên Ethernet thì MSS chỉ còn tối đa là 1500 – 52 = 1448 bytes thay vì 1460 bytes như trước.

Tương tác giữa 4 cái mẹo. Quay lại với câu chuyện thử hiệu xuất giữa Windows và MacOSX trên Ethernet. Khác biệt thứ nhất là Windows XP không dùng nhãn thời gian, cho nên MSS = 1460, còn MacOSX dùng nhãn thời gian cho nên MSS = 1448 (trong môi trường thử nghiệm). Do đó, 100000 bytes được

• TCP của Windows XP băm ra thành 68 mẩu, mỗi mẩu 1460 bytes, cộng với một mẩu 720 bytes.
• TCP của Mac OSX băm ra thành 69 mẩu, mỗi mẩu 1448 bytes, cộng với một mẩu 88 bytes.

Khi Windows XP truyền thì:

• Bên gửi gửi đi 68 mẩu (đầy MSS nên gửi ngay), và giữ lại mẩu cuối (720 bytes) chờ hồi âm của mẩu 68.
• Bên nhận dùng luật hồi âm kép nên sẽ hồi âm cho các mẩu 2, 4, …, 68 ngay lập tức, và cuối cùng khi bên gửi nhận được hồi âm của mẩu 68 sẽ gửi ngay mẩu lẻ cuối cùng.

Khi Mac OSX truyền thì:

• Bên gửi gửi đi 69 mẩu (đầy MSS nên gửi ngay), và giữ lại mẩu cuối (88 bytes) chờ hồi âm mẩu 69.
• Bên nhận theo luật hồi âm kép, nên sẽ hồi âm cho các mẩu 2, 4, …, 68 ngay lập tức, nhưng giữ lại không hồi âm mẩu 69 ngay (trừ phi có thêm hàng họ của khách hàng gửi kèm hồi âm mang về)
• Nhưng hàng họ chỉ có sau 100KB, mà bây giờ bên nhân mới nhận được 100000-88 bytes thôi nên chưa có hàng.
• Bên gửi thì dùng thuật toán Nagle, giữ lại 88 bytes chờ khi mẩu 69 có hồi âm.
• Kết quả là hai bên phải chờ thêm từ 200ms đến 500ms nữa, tùy theo người lập trình TCP chọn giá trị hồi âm muộn là bao nhiêu.
• Kết quả cuối cùng là cứ 100KB thì MacOSX bị chậm lại 200ms!

200ms là một thời khoảng rất lớn. Trên Gigabit Ethernet, với tốc độ 1Gbps thì trong 200ms ta truyền được 200Mb vị chi là 25MB.

http://www.procul.org/blog/2010/10/13/1-byte/#more-2363

Adding Checkpoint and Netscreen devices into Firemon

Adding a Checkpoint firewall into Firemon.

In Smart Dashboard:

First create an OPSEC object. Select LEA and CPM.

Select NEW next to the host box, and create a host with the IP address of Firemon.

If your vendor appliance is not listed, select Undetermined (as long as LEA and CPM are selected, everything will work).

Initiate SIC and enter a SIC password.

Additionally the firemon server needs to be added to the GUI client (Cpconfig or via the Provider).

In Firemon:

New> Device> Checkpoint

Select Smartcenter Environment Wizard.

Enter the Smartcenter IP and provide credentials for a user with atleast Read Only access.

Click Connect and enter the SIC password when prompted.

If a separate log server (MLM) is used, it will automatically be added along with all devices managed by that Smartcenter server.

If a separate log server is used, go into the properties of that log server and change the authentication method to clear.

Adding a Netscreen to firemon

Point your syslog stream to Firemon

ssg1-> set syslog config "10.16.179.70"

ssg1-> set syslog config "10.16.70" facilities local0 local0

ssg1-> set syslog config "10.16.179.70" log traffic

In Firemon:

Right click on the device group and select New Device

Select ScreenOS

Provide the name, ip and credentials

Re-establishing SIC (Secure Internal Communication) with Firewall gateway from Smartcenter server

How do i reset SIC ?

• Go into the CLI of the Firewall and type cpconfig then choose Secure Internal Communication. You will then be prompted to enter a passcode. Enter anything it doesnt matter. Then exit cpconfig using option 10.

cpfw[admin]# cpconfig
This program will let you re-configure
your Check Point products configuration.

Configuration Options:
----------------------
(1) Licenses and contracts
(2) SNMP Extension
(3) Group Permissions
(4) PKCS#11 Token
(5) Random Pool
(6) Secure Internal Communication
(7) Disable cluster membership for this gateway
(8) Disable Check Point SecureXL
(9) Automatic start of Check Point Products

(10) Exit

Enter your choice (1-10) : 6

• Go into the Smart Dashboard and go into the Check Point Object > General Properties > Communication.
• Select "reset"
  
• Enter the passcode you previously entered within cpconfig.
• Select "Initalize"
• The Trust State should now say "Trust established".
• Re-push the policy.
  

Additional Notes

• After you have entered a new passcode into cpconfig and exited, the gateway will perform a cprestart.
• After the cprestart it will install the Inital Policy onto the gateway. The Inital Policy is set to deny all traffic.
• Beware of this as this can cause you issues if you go through your firewalls to get to you manager, as this will block your access to your manager, and in turn prevent you from being able to push a new policy.
• In this case you will need to have console access to your gatewayand action a fw unloadlocal

How to download backup from R62 SmartCenter using SCP?

SFTP didn't worked on R62, and I decided to try SCP. I had to check CPUG in order to get this done :-)

Basically this is what you need to do:

1. Download PSCP

2. Edit /etc/scpusers file, adding your username into the file, 1 user per line

3. Change the shell to /bin/bash for your user in /etc/passwd

4. Restart ssh deamon: "service sshd restart"

5. Use command similar to:

C:\Documents and Settings\USER\Desktop>pscp -scp
user@10.100.2.20:/var/CPbackup/backups/backup_hostname.domain.com_2_2_2010_10_47.tgz
F:\Provider\backup\backup_hostname.domain.com_2_2_2010_10_47.tgz
user@10.100.2.20's password:
backup_hostname.domain.com_2 | 236672 kB | 9466.9 kB/s | ETA: 00:02:15 | 15%

That's all!

P.S. Don't forget to check md5 checksum after you got that file transferred ;-)

Capacity Optimization in Checkpoint firewall

Because one of my customers run recently in this problem, maybe it’s a good idea to mention this again.

The firewall has a limit for it’s maximum concurrent connections. This is necessary to limit the amount of memory allocated.

But if you reach the limit, the firewall stops to accept new connections. You may experience this as a partial loss of connectivity.

To check the number of actual connections and the peak value, run fw tab -t connections -s on the command line

[Expert@fw1]# fw tab -t connections -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost connections 8158 108437 166360 378754

The memory allocation and use of connections can also be shown with fw ctl pstat.

[Expert@fw1]# fw ctl pstat

Machine Capacity Summary:
Memory used: 12% (203MB out of 1604MB) - below low watermark
Concurrent Connections: 15% (79242 out of 499900) - below low watermark
Aggressive Aging is not active

If your concurrent connections are near the limit, you can increase the number using the SmartDashboard. Just edit the properties of the gateway object under capacity optimization and set a higher value. Please note that the memory allocation will also increase when you change something here, so make sure you’ve got enough free memory.

Tobias Lachmann

How to check drop log in command line / cli in Checkpoint firewall?

Do you know how to troubleshoot connection issues the easy way? Instead of looking into SmartView Tracker for the reason of a connection drop, just enter the shell. Then issue fw ctl zdebug drop and you'll see the dropped packet in realtime with the reason for the drop. This is an undocumented command, which is actually a shortcut for a couple of debugging commands. A developer from Check Point was to tired of typing the needed debug lines again and again and so he introduced the zdebug command. His first name began with the letter Z, so this is why the command is zdebug.

The output is very nice, shows the reason for the drop and can easily be filtered with the grep command for IP addresses:

fw_log_drop: Packet proto=17 10.255.253.21:20031 -> 10.255.253.255:20031 dropped by fw_antispoof_log Reason: Address spoofing

fw_log_drop: Packet proto=17 192.243.100.205:58999 -> 224.0.0.1:9996 dropped by fw_handle_first_packet Reason: Rulebase drop - rule 243

fw_log_drop: Packet proto=1 10.68.111.2:1281 -> 10.68.111.5:1669 dropped by fw_icmp_stateless_checks Reason: ICMP redirect packets are not allowed

fw_log_drop: Packet proto=6 192.243.119.238:80 -> 91.96.46.174:49543 dropped by fw_first_packet_state_checks Reason: First packet isn't SYN

Since this is realtime debug output, you need to have live traffic through the firewall to see if a packet is dropped. When you try to investigate the reason for a drop of an older connection, you have to go the SmartView Tracker.

How to check rule hit count / statistics in checkpoint?

As I mentioned before once you export firewall logs into human-readable format you can do lots of interesting things – for example script that gives statistics of how many times each Security rule was hit .
Be aware that this counts explicit Security rules only – i.e. the ones you see in Security tab of the Smartdashboard. No other rules you usually see in Smartview Tracker are counted – e.g. SmartDefense,Web Filtering etc. Also afterwards I sort it by number of hits to see what rules are used most:

awk -F\; ' {match($0,/rule: +([0-9]+)/,rules);rule_count[rules[1]]++} END {for (rule_number in rule_count) print " Rule number: " rule_number " Hits: " rule_count[rule_number]}' ./fw.log.txt | sort -n -k5

Rule number:  Hits: 1197330  Ignore this line as it counts 

Checkpoint : How to change Date and time in Secureplatform from CLI??

Login to Linux box as root and enter root's password:
[me@mybox me]$ su
password:

Check the current date and time of the Linux box by entering:
[root@mybox me]# date
Linux yields the current settings:

[root@mybox me]# Wed Apr 7 12:03:45 EDT 2004
Change the current time and date of the Linux box by entering:
[root@mybox me]# date 040713032004
would change the time and yield:
[root@mybox me]$ Wed Apr 7 13:03:00 EDT 2004

====================================================


One more option:

Linux Set Date

Use the following syntax to set new data and time:date set="STRING"

For example, set new data to 2 Oct 2006 18:00:00, type the following command as
root user:# date -s "2 OCT 2006 18:00:00"

Checkpoint Logging Issue / no logs are coming to smart center server from firewall gateway

The following article is a list of steps one should go through when troubleshooting logging related issues in a distributed setup.

1. Ensure that you have not run out of disk space on the hard disk that the logs are being sent to. If this is the case, delete or move the logs to an external storage device.

2. Is there communication between the MS and the Module? Test using ping to the MS from the module and then from the Module to the MS (your rules must allow for this). If this fails, and your rules allow for this, then it is most likely a routing issue.

3. Check to see if the fw.log file is growing on the module. It should be if the logs are not going to the MS. From the console run these commands:

cd $FWDIR/log

ls -la

ls -la

Verify that the fw.log file is increasing. If it is increasing then the modules are logging locally instead of forwarding the traffic to the MS. This could be a connectivity issue, or it could be the way the logging is setup. Check the FW object to ensure it is setup to send logs to the MS.


4. Can you fetch a policy? Verify that you can fetch using the hostname and IP address. If this fails then you probably have a SIC issue. To test this run the following commands:

fw fetch hostname_of_MS

fw fetch IP_Addr_of_MS (fetch by IP address also to ensure it is not a DNS issue)

5. Check the masters file. The hostname or IP address of the management station should be listed in there. To check this run the following commands:

cd $FWDIR/conf

cat masters

It should be look like this:

[Policy]

hostname_of_MS

[Log]

hostname_of_MS

[Alert]

hostname_of_MS

6. Run tcpdumps on the module, listening for port 257 on the interface facing the MS, to see if it is attempting to send logs. To check this run the following command:

tcpdump -i eth-facing-MS port 257 (use the Ctrl+C to break out of the dump)

You should see traffic leaving the FW and heading to the IP address of the MS.

You should also see traffic coming back from the MS.


7. The log file may have gotten corrupt. Run a log switch on the MS and reboot the MS to create a new log file. If logswitch does not work, move all contents of the log directory (do not move the directory itself) to a temp folder outside of the log directory. Reboot and see if the logs start again.

8. Delete the $FWDIR/log files and $FWDIR/state directory files on the module; reboot the module.

Reboot and see if the logs start again.

9. Look to see if there is a listening port for logging. Run the following command on the MS and the module:

netstat -na

You should see the *.257 LISTEN for logging connections. You should also see the IP address of the MS :257 associated with the IP address of each module, and showing an ESTABLISHED connection.

10. Check the log settings for the FW object and make sure the 'Log Server' is set to the MS that should be receiving the logs. This is usually done by default, but may have been changed by a user.


If after going through these steps you are still experiencing logging issues, please open a ticket with Corresponding TAC for further troubleshooting and ofcoz try your way with help of our all time Gaint Mr. Google.. :-)

Nokia : How to check MAC address on Nokia IP / IPSO??

I was thinking how to get the cluster mac address of Nokia IP Cluster with out logging into switches/router after my firewall.. More over I wanted to implement my new decision to Reduce Dependency..


So the command is simple,

######################################

ifconfig -a | grep -i mac

######################################

ofcoz you have to try in master box which configured in forwarding mode..

You will find the cluster mac address just after clustermac

One more thing you might have noticed, "grep -i", Take it as a home work!!! :)))

Check Point FW Monitor White Papers

FW Monitor is Check Point’s packet capture tool. It is similiar to other packet sniffers like TCPDump or Snoop. On of its unique abilities is to capture insertion points. I think the best of the 3 papers is the Nokia one. Enjoy.

Check Point Whitepaper on How to use FW Monitor

Nokia Whitepaper on Check Point FW Monitor

CPUG White Paper FW Monitor

Steve Jobs' 2005 Stanford Commencement Address

Think Different

Here's to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently.

They're not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them.

But the only thing you can't do is ignore them. Because they change things. They push the human race forward.

And while some see them as the crazy ones, we see genius.

Because the people who are crazy enough to think they can change the world, are the ones who do.

Họ điên khùng. Không phù hợp. Nổi loạn. Chuyên gây rắc rối. Họ giống như nồi tròn vung méo. Họ nhìn mọi thứ khác với lẽ thông thường.

Họ không ưa các nguyên tắc. Họ làm đảo lộn hiện trạng. Bạn có thể bất đồng với họ, vinh danh hay đả kich họ.

Nhưng bạn không thể không chú ý tới họ. Bởi họ thay đổi thế giới và đưa nhân loại tiến lên phía trước.

Và trong khi họ bị coi là những kẻ điên khùng, chúng tôi lại thấy ở đó phẩm chất của những thiên tài. Bởi những người đủ điên để nghĩ bản thân có thể thay đổi thế giới sẽ chính là những người thực sự làm được điều đó.

RAID 0, RAID 1, RAID 5, RAID 10 Explained with Diagrams

RAID stands for Redundant Array of Inexpensive (Independent) Disks.

On most situations you will be using one of the following four levels of RAIDs.

• RAID 0
• RAID 1
• RAID 5
• RAID 10 (also known as RAID 1+0)

This article explains the main difference between these raid levels along with an easy to understand diagram.

In all the diagrams mentioned below:

• A, B, C, D, E and F – represents blocks
• p1, p2, and p3 – represents parity

RAID LEVEL 0

Following are the key points to remember for RAID level 0.

• Minimum 2 disks.
• Excellent performance ( as blocks are striped ).
• No redundancy ( no mirror, no parity ).
• Don’t use this for any critical system.

RAID LEVEL 1

Following are the key points to remember for RAID level 1.

• Minimum 2 disks.
• Good performance ( no striping. no parity ).
• Excellent redundancy ( as blocks are mirrored ).

RAID LEVEL 5

Following are the key points to remember for RAID level 5.

• Minimum 3 disks.
• Good performance ( as blocks are striped ).
• Good redundancy ( distributed parity ).
• Best cost effective option providing both performance and redundancy. Use this for DB that is heavily read oriented. Write operations will be slow.
  

RAID LEVEL 10

• Minimum 4 disks.
• Excellent performance ( as blocks are striped )
• Excellent redundancy ( as blocks are mirrored )
• If you can afford the dollar, this is the BEST option for any mission critical applications (especially databases).
  

http://www.acnc.com/04_01_00.html

Practical TCP Series

In the 5 part series we will cover:

1. The TCP Connection
   
2. TCP Flags
3. The TCP Window
4. Sequence and Acknowledgement Numbers
5. Connection Teardown (Expected and Unexpected)