Zimbra – Pop before smtp authentication howto

http://www.mnxsolutions.com/blog/linux/zimbra-pop-before-smtp-authentication-howto.html

450 Client host rejected: cannot find your hostname

- Turn off reject_unknown_client; which rejects the request when the client IP address has no PTR (address to name), or when the PTR record does not have a matching A record (name to address).
- Turn off reject_unknown_hostname; which rejects the request when the hostname in the client HELO (EHLO) command has no DNS A or MX record.

AH và ESP

- AH có khả năng cung cấp cơ chế xác thực và bảo đảm tính toàn vẹn (integrity) của dữ liệu là vì AH Header chứa một "chữ ký số" được gọi là giá trị kiểm tra tính toàn vẹn (Integrity Check Value-ICV). Thực chất nó là một giá trị băm được dùng để kiểm tra xem liệu gói tin có bị thay đổi trên đường truyền hay không. Vì AH sử dụng IP header để tính toán ICV nên chúng ta có thể chắc chắn rằng địa chỉ nguồn của gói tin là xác thực và gói tin này xuất phát từ đúng nơi gửi.

Hơn nữa, AH cũng sử dụng các giá trị sequence number hỗ trợ việc chống lại kiểu tấn công phát lại (replay attack). Vì các thiết bị truyền thông sử dụng giá trị này để theo dõi dòng dữ liệu trao đổi, một kẻ tấn công với ý định chiếm quyền truy cập vào VPN không thể gửi lại gói tin mà hắn "bắt" được.

Ngoài ra, một vấn đề cần lưu tâm ở đây, đó là AH xác thực gói tin dựa vào thông tin IP header. Do vậy, nó sẽ không tương thích với các thay đổi do cơ chế NAT mang lại. Vì giá trị ICV của AH đã được tính toán trước NAT nên khi gói tin được gửi tới đích, việc kiểm tra tính toàn vẹn sẽ thất bại(!)

Mặt khác, vì AH không hỗ trợ bảo vệ tính mật (confidentiality) của dữ liệu trong các gói tin, nên nó sẽ không phải thực hiện tính toán nhiều để mã hoá các gói tin, do đó công việc xử lý và đóng gói các gói tin sẽ dễ dàng và nhanh chóng hơn. Đây là những đặc điểm góp phần làm cho AH trở thành một giải pháp hợp lý cho những nơi chỉ cần bảo toàn và xác thực thông tin địa chỉ IP và cần hiệu năng cao

- Cách thức hoạt động của ESP có khác biệt đôi chút phụ thuộc vào chế độ làm việc của IPSec. Trong chế độ Transport, ESP chỉ đơn thuần thêm phần header của bản thân nó vào sau phần IP header và mã hoá toàn bộ phần còn lại của gói tin từ tầng 4 trở lên. Nếu trong quá trình thương lượng khởi tạo một IPSec connection có chỉ định sử dụng dịch vụ xác thực của ESP, khi đó ESP sẽ thêm một phần (trailer) chứa thông tin ICV để đảm bảo tính toàn vẹn và tính xác thực. Không giống với AH, ESP ICV không tính toán dựa trên các thông tin về IP header.

ESP là giải pháp cho phép IPSec chạy trên hệ thống có xảy ra quá trình NAT với điều kiện IPSEC được thiết lập ở chế độ tunnel . Tuy nhiên trong chế độ transport, ESP và NAT không tương thích với nhau vì các thông tin của phần header của gói tin đã bị NAT thay đổi. Khi NAT thực hiện thay đổi phần thông tin về IP, nó cũng sẽ tính lại giá trị checksum trong TCP header. Và bởi vì TCP checksum được tính toán không chỉ dựa vào TCP header, mà nó còn dựa vào các thông tin từ IP header, như địa chỉ nguồn/đích của gói tin nên NAT đã phá vỡ tính toàn vẹn của gói tin. Trong chế độ Transport ESP, toàn bộ TCP header đã được mã hoá, NAT box sẽ không thể tính toán lại TCP checksum. (Vấn đề tương tự đối với UDP packets khi UDP checksum được tính đến). Kết quả là trước khi giải mã, gói tin sẽ bị hủy vì không bảo đảm tính toàn vẹn. Vấn đề này có thể được giải quyết nếu như không đụng đến TCP checksum trong mọi trường hợp.

Trong chế độ Tunnel ESP, NAT hoàn toàn được tương thích vì toàn bộ gói tin nguồn bao gồm các thông tin về IP và thông tin ở tầng 4 được đóng gói và do đó không bị xử lý bởi NAT. Vì thông tin về IP, TCP header, TCP checksum không bị thay đổi trong chế độ Tunnel ESP nên gói tin sẽ được giải mã và thoả mãn tính toàn vẹn. Tuy nhiên, mặc dù ESP traffic trong chế độ Tunnel có thể tương thích với NAT, bạn sẽ gặp phải các vấn đề liên quan đến NAT khi thương lượng các tham số cho IPSec connection. Chẳng hạn, one-to-many NAT (thường được hiểu là PAT) sẽ sửa đổi tham số cổng nguồn của một outbound IKE packet, dẫn đến giá trị cổng UDP 500 dành cho IKE bị thay đổi, từ đó dẫn đến việc thất bại khi phân phối khoá cho các tham số của IPSec session.

Một vấn đề còn đang tranh cãi nữa là khả năng xác thực của ESP. Như ta đã biết, ESP có khả năng cung cấp cơ chế xác thực, nhưng giá trị băm mà nó sử dụng được sinh ra dựa trên toàn bộ gói tin ngoại trừ phần IP header và phần authentication trailer. Điều này giúp cho ESP authentication tương thích với NAT, nhưng việc thiếu xác thực của IP header sẽ không đảm bảo được nguồn gốc của gói tin. May thay, trong hầu hết các cài đặt, việc kiểm tra tính xác thực cho phần IP payload cũng đủ để nói lên nguồn gốc của gói tin này!

Mail Header

Thường các Mail client đều có chức năng cho phép xem nội dung chi tiết của mail header.

Sau đây là một ví dụ:

X-Apparently-To: someone@yahoo.com via 206.190.58.160; Wed, 21 Mar 2007 20:52:21 -0700
X-Originating-IP: [216.82.250.163]
Return-Path:
Authentication-Results: mta419.mail.re4.yahoo.com from=mymachine.somecompany.com; domainkeys=neutral (no sig)
Received: from 216.82.250.163 (HELO mail130.messagelabs.com) (216.82.250.163) by mta419.mail.re4.yahoo.com with SMTP; Wed, 21 Mar 2007 20:52:21 -0700
X-VirusChecked: Checked
X-Env-Sender: me@mymachine.somecompany.com
X-Msg-Ref: server-12.tower-130.messagelabs.com!1174535539!4933233!1
X-StarScan-Version: 5.5.10.7.1; banners=.,-,-
X-Originating-IP: [123.123.123.123]
Received: (qmail 18448 invoked from network); 22 Mar 2007 03:52:19 -0000
Received: from externalmail.somecompany.com (HELO genericgateway.somecompany.com) (123.123.123.123) by server-12.tower-130.messagelabs.com with SMTP; 22 Mar 2007 03:52:19 -0000
Received: from internalmail.somecompany.com ([10.20.30.40]) by genericgateway.somecompany.com (Mailer xyz) with ESMTP id 2007032214521793-200256 ; Thu, 22 Mar 2007 14:52:17 +1100
Received: from mymachine.somecompany.com ([192.193.194.195]) by internalmail.somecompany.com (Mailer xyz) with ESMTP id 2007032214521636-372052 ; Thu, 22 Mar 2007 14:52:16 +1100
Received: (from me@localhost) by mymachine.somecompany.com (AIX5.2/8.11.6p2/8.11.0) id l2M3qBm2412594 for someone@yahoo.com; Thu, 22 Mar 2007 14:52:12 +1100
Date: Thu, 22 Mar 2007 14:52:12 +1100
From: me@mymachine.somecompany.com Add to Address BookAdd to Address Book Add Mobile Alert
Message-Id: <200703220352.l2m3qbm2412594@mymachine.somecompany.com>
To: someone@yahoo.com
Subject: Test to conmale

216.82.250.163: là IP của message lab mà yahoo dùng.
123.123.123.123: là public IP của nguồn mail gởi đi.
10.20.30.40: là private IP của mail server nằm trong nội mạng (hoặc DMZ).
192.193.194.195: là private IP của máy dùng để gởi mail đi --> IP bồ muốn biết )

Có những mail server (SMTP) có quy định lột bỏ hết các mail header entries thuộc bên trong nội mạng nên việc xác định private IP có thể không được.

Thân mến.

Netstat

Cột đầu tiên chỉ Protocol. Là TCP hay UDP

Cột thứ hai chỉ local port. Nghĩa là xem port nào đang mở.
o Nếu cột này có dạng: x.y.z.t PORT có nghĩa là máy đang có một service lắng nghe cổng là PORT, IP là x.y.z.t Nếu có một host khác muốn connect đến máy này, nhưng không kết nối với NIC có IP x.y.z.t thì sẽ không thể connect đến PORT được.
o Nếu cột này có dạng: 0.0.0.0 PORT có nghĩa là máy có service lắng nghe trên cổng là PORT. Tất cả các host nếu có route đến đều có thể connect.

Cột tiếp theo (số 3) là foreign port.
o Nếu status là ESTABLISHED thì cột này chỉ IP PORT của remote host
o Nếu status là listENING thì cột này chỉ các IP PORT mà service đó chập nhận. Thường cột này sẽ có dạng 0.0.0.0:* hoặc *:* chỉ đầu kia của socket có thể có IP bất kỳ và port bất kỳ. Vì đa phần các client khi connect sẽ dùng các empherical port (các port lớn hơn 1024, không phải dành cho các service thông dụng)

DNS - PXMMRF

Quá trình phân giải một tên miền thành một public IP giúp ta có thể kết nối với một server muc tiêu, thí du một webserver, theo các bứoc cơ bản sau:

1- Đánh tên miền, thí dụ www.hvaonline.net, trên thanh đia chỉ của trình duyệt hay đánh tên miền vào một vị trí qui định trong một tiện ích với DNS-enabled.

2- DNS client (hay còn gọi là DNS lookup client) trong HDH sẽ đựoc kích hoạt. DNS client trong Windows được kích hoạt với sự giúp đỡ của một file Dynamic loaded library (DLL). DNS client sẽ kích hoạt Library Function của DLL và sau đó DLL sẽ tiến hành quá trình kết nối với một DNS server. (Còn trong Linux quá trình có khác một chút: application liên quan (thí dụ trình duyệt web) sẽ chuyển Domain name đến DNS client và chờ nó trả lời).

Các DNS client của Microsoft đều có tính năng Local caching (lưu trữ một bảng phân giài tên miền có sẵn trong máy), tính năng này gọi là DNS client service (hay còn gọi là DNSCACHE).
Từ Windows prompt đánh lệnh ipconfig/displaydns, chúng ta sẽ thấy một bảng phân giải tên miền khá dài, kẻm theo các thông số liên quan như: Record type, TTL, Data Length, A record.. (Hãy thử xem các bạn! Xem xem có những tên miền độc hại, hay tên miền XXX đang bị lưu trữ, ngoài mong muốn của ta hay không ? Hề hề)
Bảng phân giải tên miền trong DNSCACHE này đựoc DNS client lưu lại sau các lần ta thừong xuyên truy cập đến các website quen thuộc. Nếu ta lại truy cập lần sau đến các website này, thì DNS client sẽ sử dụng các dữ liệu lưu trữ và chuyển đến application (trình duyệt), mà không cần kết nối với một DNS server bên ngoải, nếu như TTL chưa expired.

3-DNS client bắt đầu gửi các truy vấn (request) đến DNS server. Nhưng ta cần nhớ điều này: DNS client sẽ gửi request đến một DNS server "gần" nhất. Đó chính là DNS server đựoc lắp đặt trên local network của user (của ta), thửong là các DNS server của ISP. [Cũng chú ý là DNS client của Windows 2K SP4 và Windows mới hơn đã đựoc cấu hình để trứoc hết gửi request đến ISP Primary DNS server, nếu tại đây tên miền không đựoc phân giải thì nó mới gửi request tiếp đến Secondary DNS server ( hay Slave DNS server)]
Các ISP DNS server chính là recursive DNS server, chúng còn đựoc gọi là các "non-authoritative DNS server", hay là Resolver, mặc dù tôi không thích gọi chúng là Resolver, vì có thể nhầm với một trình Resolver trong HDH.

Nếu tính năng Recursion (Recursion- là hỏi DNS server khác hộ cho ta về việc phân giải tên miền) trên recursive DNS server không bị disabled (một vài Admin. quá cẩn thận làm việc kỳ như vậy đấy) thì nó sẽ tiêp nhận các request từ DNS client và bắt đầu phân giải tên miền. Nếu tên miền cần phân giải đã có trong CACHE của DNS server thì nó sẽ lấy dữ liệu trả lời ngay cho DNS client. DNS client tiếp nhân thông tin trả lởi và chuyển (convert) thông tin từ ngôn ngữ mà DNS server hiểu sang ngôn ngữ mà application (trình duyệt) có thể hiểu đựoc, cho application này. Nếu trong CACHE không có sẵn thì recursive DNS server bắt đầu quá trình hỏi các DNS khác, các DNS bên ngoài (trong RFC 1035-1987, mục 2: Common configuration, ngừoi ta gọi các DNS server bên ngoài này là "Foreign name server"). Vậy chúng thưc sư là các DNS server gì?

4- Recursive DNS server lúc này phải tìm trên mạng các DNSserver chịu trách nhiệm quản lý các hậu tố DNS của tên miền cần phân giải, là .com, .net..., trong thí dụ của ta tên miền cần phân giải là www.hvaonline.net thì recursive DNS server phải tìm ra các DNS server quản lý .net.
Nhưng làm thế nào mà tìm ra đựoc những DNS server quản lý .net trong hàng triệu DNS server trên mạng?
Cũng có cách đấy, recursive DNS server sẽ phải hỏi 13 Root DNS server xem những DNS server nào quản lý .net. Nhưng các Root DNS server ở đâu? Danh sách 13 Root DNS server này, kèm public IP đựoc lưu trữ trong chínhDNS server (phần mềm quàn lý DNS cài trong hệ thống- như Windows DNS, BIND...). Ai đã từng thiết lâp một DNS server sẽ tìm thấy chúng, nếu mở lần lựot các thẻ trên các giao diện của phần mềm. Ngoài ra cũng có thể thấy nó trong 1 file có tên là cache.dns tai thư mục \winnt\system32\dns hay windows\system32\dns.
Recursive DNS server, căn cứ danh sách 13 root DNS server và IP của chúng sẽ gửi các truy vấn đến các root DNS server này.

5- Tiếp nhận các request từ recursive DNS server, một hay một vài root DNS server sẽ trả lởi (respond) vả gửi dữ liệu đến recursive DNS server. Căn cứ thông tin cung cấp từ root DNS server, recursive DNS server sẽ gửi các request đến tất cả DNS server quản lý .net, vì nó không biết rõ trong các DNS server thì cái nào lưu trữ trong cache tên miền hvaonline.net. Môt hay một vài DNS server quản lý hvaonline.net sẽ trả lời recursive DNS server.
Tiếp nhân thông tin phân giải tên miền hvaonline.net từ DNS server nói trên, recursive DNS server sẽ chuyển thông tin phân giải tên miền về cho DNS client của máy ta và DNS client sẽ chuyển tiếp thông tin này cho application (trình duyệt). Chú ý là các DNS server quản lý tên miền hvaonline.net này mới chính là các Authoritative DNS server của tên miền hvaonline.net.

Hơi dài dòng nhỉ phải không các bạn. Nhưng phân tích kỹ quá trình phân giải tên miền chúng ta sẽ thấy rõ những yếu tố làm tiền đề cho các cuộc tấn công "DNS cache poisoning" như kiểu tấn công "Birthday Paradox" hay có thể kiểu tấn công mà Dan Kaminsky đề cập (nói có thể vì cho đến nay anh ta- Dan Kaminsky còn khá trẻ-chưa nói bất cứ chi tiết cụ thể nào về cơ chế tấn công). Anh ta hứa là sẽ chỉ nói vào ngày 6.8.08 tại diễn đàn Black Hat.

Các yếu tố làm tiền đề cho cuôc tấn công "DNS cache poisoning" là:

1- Muc tiêu của cuôc tấn công chủ yếu là các ISP recursive DNS server, không phải là các Foreign name server (hay Authoritative DNS server) vì thừong các user (hay hacker) không "liên hệ" trưc tiếp với chúng.

2- Tên miền gửi kèm theo request gửi từ hacker không có trong recursive DNS server cache.

3- Recursive DNS server phải enable option recursion (nhưng thừong như vậy)

4- Các gói tin trả lời giả mạo gửi từ máy hacker đến Victim recursive DNS server phải hiểu là giả mạo trả lời cùa, từ Authoritative DNS servers (hay gọi là Foreign name servers).

5- Khi hacker gửi các gói tin trả lời giả mạo đến recursive DNS server thì đồng thời các Authoritative DNS cũng gửi các gói tin trả lời thật (hợp lệ) đến recursive DNS server này. Có một sự "cạnh tranh" giữa 2 dòng thông tin. Các Authoritative DNS server thừong khá mạnh, hay rất mạnh. Do vậy muốn thành công hacker có thể phải tìm cách làm chúng "chạy chậm" lại, bằng cách DoS vào các Authoritative DNS server chẳng hạn.

6- Vì các recursive DNS server (hay chính xác hơn là các phần mềm quản lý DNS trong hệ thống) lại đồng thời gửi nhiều request đến tất cả các Authoritative DNS server nên tạo điều kiện thuân lơi khá lớn cho hacker gửi gói tin trả lởi giả mạo có transaction ID (hay còn gọi là requestID) trùng với transaction ID mà recursive DNS server tạo ra một cách xác xuất. Vì vậy gói tin trả lời giả mạo của hacker có thuân lợi hơn để đựoc recursive DNS server coi là hợp lệ và chấp nhận.

7- Nếu recursive DNS server đựoc cấu hình cho TTL đủ ngắn, dù hacker có poisoning đựoc cache của DNS server, thì tác dụng thưc tế của cuộc tấn công cũng rất hạn chế.

Phát hiện máy đã bị nhiễm rootkit

Đây là một mẹo nhỏ mà tôi vẫn thường sử dụng để phát hiện ra trường hợp máy đã bị nhiễm rootkit (loại ẩn process). Cũng không có gì đặc biệt lắm, cách làm là sử dụng chính tool Task Manager

Các bạn hãy để ý phần trăm CPU rỗi trong tab process


Và hãy so sánh nó với % CPU busy bên tab performance.


Nếu tổng là 100% thì máy bình thường. Trong trường hợp máy bị nhiễm rootkit thì System Idle Process vẫn rất cao khoảng >95% trong khi CPU Usage có thể lên tới 50%

Còn như thế này nghĩa là đang "phê" virus rồi

How to Find and Check Number of Connections to a Server

- Whenever a client connects to a server via network, a connection is established and opened on the system. On a busy high load server, the number of connections connected to the server can be run into large amount till hundreds if not thousands. Find out and get a list of connections on the server by each node, client or IP address is useful for system scaling planning, and in most cases, detect and determine whether a web server is under DoS or DDoS attack (Distributed Denial of Service), where an IP sends large amount of connections to the server. To check connection numbers on the server, administrators and webmasters can make use of netstat command.

- Below is some of the example a typically use command syntax for ‘netstat’ to check and show the number of connections a server has. Users can also use ‘man netstat’ command to get detailed netstat help and manual where there are lots of configurable options and flags to get meaningful lists and results.

netstat -na
Display all active Internet connections to the servers and only established connections are included.

netstat -an | grep :80 | sort

Show only active Internet connections to the server at port 80 and sort the results. Useful in detecting single flood by allowing users to recognize many connections coming from one IP.

netstat -n -p|grep SYN_REC | wc -l
Let users know how many active SYNC_REC are occurring and happening on the server. The number should be pretty low, preferably less than 5. On DoS attack incident or mail bombed, the number can jump to twins. However, the value always depends on system, so a high value may be average in another server.

netstat -n -p | grep SYN_REC | sort -u
List out the all IP addresses involved instead of just count.

netstat -n -p | grep SYN_REC | awk '{print $5}' | awk -F: '{print $1}'
List all the unique IP addresses of the node that are sending SYN_REC connection status.

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
Use netstat command to calculate and count the number of connections each IP address makes to the server.

netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
List count of number of connections the IPs are connected to the server using TCP or UDP protocol.

netstat -ntu | grep ESTAB | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr
Check on ESTABLISHED connections instead of all connections, and displays the connections count for each IP.

netstat -plan|grep :80|awk {'print $5'}|cut -d: -f 1|sort|uniq -c|sort -nk 1
Show and list IP address and its connection count that connect to port 80 on the server. Port 80 is used mainly by HTTP web page request.

Show mtarestriction

su - zimbra
zmprov gacf | grep -i mtarestriction

"Relay Access Denied" errors in the MTA log (/var/log/zimbra.log)

"http://wiki.zimbra.com/index.php?title=ZimbraMtaMyNetworks"

- Không liệt kê trusted netwok --> Zimbar báo no relay allow, không cho relay từ mail client

zmprov gs mail.bank.com.vn | grep -i zimbraMtaMyNetworks để xem zimbraMtaMyNetworks (MTA Trusted Networks) hiện tại

kết quả --> zimbraMtaMyNetworks: 127.0.0.0/8 10.0.25.0/24 10.0.0.0/8

Bổ sung thêm

zmprov ms mail.bank.com.vn zimbraMtaMyNetworks '127.0.0.0/8 10.0.25.0/24 10.0.0.0/8 192.168.1.0/24'

Sau đó khởi động lại

zmmailboxdctl restart

(hoặc postfix reload)

- Nếu Alice đang dùng một máy có network không thuộc network "white list" mà access MTA này thì nó phải reject bởi vì đây là nguyên tắc không cho phép open relay. Cách duy nhất và tạm gọi là "reliable" là cách cho phép Alice "pop before smtp", đây là một cách buộc Alice phải authenticate xuyên qua pop3 (nhận mail) trước khi tạm thời open relay để Alice có thể gởi mail (xuyên qua smtp) vào qmail (rồi qmail mới gởi mail của Alice đến một MTA khác là đích).

- Nếu Alice đang dùng một máy có network không thuộc network "white list" mà access MTA này và access vào một web front end (web mail chẳng hạn) thì sau khi authenticate trên webmail ấy, Alice có thể gởi mail xuyên qua webmail. Ở tình trạng này, IP của webmail ấy đã thuộc "white list" của qmail MTA kia cho nên mail sẽ được qmail tiếp nhận (rồi qmail mới gởi mail của Alice đến một MTA khác là đích).

Layer 2 Network Protections against Man in the Middle Attacks

The configuration commands shown in this article are for Cisco IOS, but equivalent commands are available on Brocade, HP and most other managed switches on the market today. We’ll be covering DHCP Snooping, Dynamic ARP inspection, IP Source Guard, and Rate Limiting of ARP packets.

DHCP Snooping

DHCP Snooping intercepts all DHCP traffic, and maintains a table of MAC addresses to IP Addresses called a DHCP Snooping binding database. This sounds a lot like an ARP table, but is used instead to validate ARP traffic to protect against Man in the Middle Attacks which might poison the ARP table.

DHCP Snooping by default blocks all DHCP offer packets inbound to the switch port, which means that if a DHCP server is on that port, the DHCP requests will reach the server, but the addresses will never reach the DHCP client. So after enabling DHCP snooping, configure any ports that have DHCP servers attached, or uplink to switches with DHCP servers as “trusted”.

It makes good sense to periodically store your DHCP Snooping database to flash memory or a tftp or (preferably) an scp server. Without this, if a switch is rebooted, clients on untrusted ports will not have connectivity until they renegotiate a DHCP lease.

Anyone who has ever had a home router (with its DHCP server) appear on their corporate network knows how disruptive this can be, and can attest to just how valuable these DHCP snooping functions can be just to mitigate that one situation.

Configuration:

Switch(config)# ip dhcp snooping	Enables DHCP snooping globally.
Switch(config)# ip dhcp snooping vlan 1,2,6	Enables DHCP snooping on VLANs 1, 2 and 6 (this of course will be unique for each site)
Switch(config)# int g0/7 Switch(config-if)# ip dhcp snooping trust	On the port with the DHCP server (gig 0/7 in this example), enable dhcp snooping trust
Switch(config)# ip dhcp snooping database tftp://192.168.10.50/dbfile	On bootup, read the dhcp snooping database from a tftp server

Dynamic ARP inspection (DAI)

This feature uses the table created by the DHCP Snooping feature to validate all ARP responses that arrive inbound to switch ports. Gratuitious ARPs are integral to all Man in the Middle attacks that use ARP Cache poisoning. What DAI does is simply drop all ARP replies that do not have corresponding entries in the DHCP Snooping binding database. ARP reply packets where the MAC address in the body of the packet do not match the MAC address in the Ethernet header are also dropped.

In non DHCP environments, DAI can operate against a statically defined ARP ACL.
Ports that have multiple MAC addresses, such as uplink to physical or virtual switches, should be configured as “trusted”, this bypasses all DAI functions.

Configuration:

Switch(config)# ip arp inspection vlan 1	Turn on arp inspection for vlan 1
Switch(config)# int g0/8 Switch(config-if)# ip arp inspection trust	trust int g0/8 to have multiple arp entries - for instance, uplinks to physical or virtual switches, clusters, load balancers in some cases.

IP Source Guard

This feature uses the DHCP Snooping database as well, but takes things one step further. When a client host powers on, IP Source Guard will filter all traffic to and from that port except for the DHCP request and reply traffic. Once the address is assigned and the DHCP Snooping entry is populated for the port, any traffic received from that port from a different ip address is filtered.

Configuration:

Switch(config)# Int g0/8 Switch(config-if)# ip verify source

Enable ip source guard on one interface

or

Switch(config)# int g0/8 Switch(config-if)# ip verify source vlan dhcp-snooping

Enable ip source guard for all vlans defined on this interface

Rate Limiting Incoming ARP Packets

Many tools that perform Man in the Middle attacks based on ARP poisoning will generate large volumes of ARP reply packets (Gratuitous ARPs). Switches can generally be configured to Rate Limit these packets, and in many cases can be configured to either alert if a threshold is exceeded, or to place any ports that exceed a configured threshold in an error state, either for a configured period of time or until manually reset.

By default, when dynamic ARP inspection is configured, ARP packets are rate limited to some default value (15 per second on cisco platforms, but this may vary on other switches)

Configuration

Switch(config-if)# ip arp inspection limit rate 20	configure arp inspection for 20 packets per second. By default, if this is exceeded, the port is placed into an "errdisable" state.
Switch(config-if)# errdisable recovery cause arp-inspection interval 240	re-enable the errdisable'd port after 240 seconds.

Caveats and Comments on Layer 2 Network Protections

Many network components require on changing MAC addresses, so care should be taken when defining protections against ARP poisoning. These features should be disabled on interfaces that have components that have:

• Standby features such as vrrp, vrrp-e, hsrp and similar router or firewall clustering applications
• load balancers, or hosts configured with load balancing solutions such as Microsoft NLB
• Any clustering application such as microsoft, linux, solaris or other clustering solutions
• Ports that connect to Vmware ESX vswitch uplink ports, as a vmotion involves a virtual server mac migrating from one physical switch port to another with a corresponding RARP packet after completion.
• Switch ports that connect to ESX uplink ports that support load balanced or failover configurations for the ESX Service Console or vmkernel ports.

Features such as rate limiting of ARP packets, Storm control and port security (these 2 aren't covered in this post) can simply disable ports if their function is triggered. Unless configured for recovery, disabled ports remain in an Error Disabled state until manually re-enabled. Needless to say, this can cause major service disruptions unless implemented carefully.

While there are certainly some things to watch out for in implementing these features, the benefits of configuring the protections we've discussed almost always outweigh the risks (by a country mile). Most enterprises should really consider implementing at the very least DHCP Snooping and Dynamic ARP Inspection.

Tesking Checkpoint

1. Tail -f views messages in real-time. Fw log views the Firewall connection logs in
real-time : Tail -f /var/log/messages

2. Display interface statistics : Ifconfig -a (clish)

3. Setting the UID of 0 from the Voyager or the CLI will give the same machine permissions
as the root user on a Nokia IPSO device

4. The default priority when setting up VRRP on IPSO is 100

5. The Time-to-Live for a VRRP packet must be set to 255 otherwise the router should
discard the packet

6. View the current connections table: fw tab -t connections -s

Auditing Nokia Firewall

- Kiểm tra gói tin bị drops (over 1000) sẽ gây tắc nghẽn tại firewal
ipsctl -a | grep in_qdrop

- Kiểm tra Disk va Swap Space ( capacity không vượt quá 80%)
df -k

- Kiểm tra interface throughput report (bandwidth)
ipsctl -a | grep out_qdrops

Initial TTL values

The following table shows the initial TTL values that are used by a number of operating systems. Why should you care? Well when you are looking at a trace it is sometimes not obvious where the protocol analyzer was in relation to the hosts of interest. By looking at the TTL values recorded by the analyzer and knowing the initial TTL value you can get an idea of the "distance" between the end points and the analyzer. I gleaned the information in this table from looking at traces and when possible system documentation. I have also stolen shamelessly from other sources on the web.

OS	Version	Protocol	TTL	Notes
AIX		TCP	60
AIX		UDP	30	2
AIX	3.2, 4.1	ICMP	255	3
BSDI	BSD/OS 3.1 and 4.0	ICMP	255	3
Compa	Tru64 v5.0	ICMP	64	3
DEC Pathworks	V5	TCP and UDP	30	2
FreeBSD	2.1R	TCP and UDP	64	2
FreeBSD	3.4, 4.0	ICMP	255	3
FreeBSD	5.0	ICMP	64	2
HP-UX	9.0x	TCP and UDP	30	2
HP-UX	10.01	TCP and UDP	64	2
HP-UX	10.20	ICMP	255	3
HP-UX	11.00	ICMP	255	3
HP-UX	11.00	TCP	64
Irix	5.3	TCP and UDP	60	2
Irix	6.x	TCP and UDP	60	2
Irix	6.5.3, 6.5.8	ICMP	255	2
MPE/IX (HP)		ICMP	200
Linux	2.0.x kernel	ICMP	64	3
Linux	2.2.14 kernel	ICMP	255	3
Linux	2.4 kernel	ICMP	255	3
Linux	Red Hat 9	ICMP and TCP	64
MacOS/MacTCP	2.0.x	TCP and UDP	60	2
MacOS/MacTCP	X (10.5.6)	ICMP/TCP/UDP	64
NetBSD		ICMP	255	3
Netgear FVG318		ICMP and UDP	64
OpenBSD	2.6 & 2.7	ICMP	255	3
OpenVMS	7.1-2	ICMP	255	3
OS/2	TCP/IP 3.0		64	4
OSF/1	V3.2A	TCP	60	2
OSF/1	V3.2A	UDP	30	2
Solaris	2.5.1, 2.6, 2.7, 2.8	ICMP	255	3
Solaris	2.8	TCP	64
Stratus	TCP_OS	ICMP	255
Stratus	TCP_OS (14.2-)	TCP and UDP	30	1
Stratus	TCP_OS (14.3+)	TCP and UDP	64	1
Stratus	STCP	ICMP/TCP/UDP	60
SunOS	4.1.3/4.1.4	TCP and UDP	60	2
SunOS	5.7	ICMP and TCP	255
Ultrix	V4.1/V4.2A	TCP	60	2
Ultrix	V4.1/V4.2A	UDP	30	2
Ultrix	V4.2 - 4.5	ICMP	255	3
VMS/Multinet		TCP and UDP	64	2
VMS/TCPware		TCP	60	2
VMS/TCPware		UDP	64	2
VMS/Wollongong	1.1.1.1	TCP	128	2
VMS/Wollongong	1.1.1.1	UDP	30	2
VMS/UCX		TCP and UDP	128	2
Windows	for Workgroups	TCP and UDP	32	2
Windows	95	TCP and UDP	32	2
Windows	98	ICMP	32
Windows	98, 98 SE	ICMP	128	3
Windows	98	TCP	128
Windows	NT 3.51	TCP and UDP	32	2
Windows	NT 4.0	TCP and UDP	128	2
Windows	NT 4.0 SP5-		32	4
Windows	NT 4.0 SP6+		128	4
Windows	NT 4 WRKS SP 3, SP 6a	ICMP	128	3
Windows	NT 4 Server SP4	ICMP	128	3
Windows	ME	ICMP	128	3
Windows	2000 pro	ICMP/TCP/UDP	128
Windows	2000 family	ICMP	128	3
Windows	Server 2003		128	4
Windows	XP	ICMP/TCP/UDP	128

Cyber Security Awareness Month 2009 - Summary and Links

Published: 2009-11-01,
Last Updated: 2009-11-01 23:58:30 UTC
by Marcus Sachs (Version: 1)

As requested by many readers, below are links to all 31 of the diaries that we wrote for Cyber Security Awareness Month 2009. In 2007 we covered a large range of subjects based on what our readers submitted as ideas. In 2008 we took a closer look at the six steps of incident handling. This year we examined 31 different ports/services/protocols/applications and discussed some of the major security issues. Many readers submitted comments, tips, and tricks for securing them. If you have additional comments on any of these diaries feel free to add them directly to the bottom of the diary (you have to log in first) or if you want to remain anonymous you can send them to us via our contact form.

1 - Port 445 - SMB over tcp
2 - Port 0
3 - Port 5900 - VNC
4 - Port 20/21 - FTP-data/FTP
5 - Port 31337 - trojan horses
6 - Ports 67&68 udp - bootp and dhcp
7 - Port 6667/8/9/7000 - IRC
8 - Port 25 - SMTP
9 - Port 3389 -RDP
10 - The Questionable Ports
11 - Port 111 - RPCBind aka Portmapper
12 - Ports 161/162 - Simple Network Management Protocol (SNMP)
13 - Ports 3128, 8080 & .... - Proxies
14 - Port 514 - syslog
15 - Ports 995, 465, and 993 - Secure Email
16 - Port 1521 - Oracle TNS Listener
17 - Port 22 - SSH
18 - Port 23 - Telnet
19 - ICMP
20 - Ports 5060 & 5061 - SIP (VoIP)
21 - Port 135 - MS DCE locator
22 - Port 502 - Modbus
23 - Port 179 - Border Gateway Protocol
24 - Ports 1-20 and 37 - The Small Services
25 - Port 80 and 443 - Web services
26 - Ports 1433/1434 - MS SQL
27 - Ports 135, 137, 138, 139, ... - MS Active Directory Ports
28 - Port 123 - ntp
29 - Port 53 - dns
30 - Ports 47, 50, 500, 1723, 4500, ... - The "Common" IPSEC VPN Protocols
31 - Port 113 - ident

Marcus H. Sachs
Director, SANS Internet Storm Center

Windows 7 Hands On Lab - Step By Step

Dear All,

Nhân sự kiện Microsoft ra mắt "Hệ Điều Hành Được Mong Đợi Bấy Lâu: Windows 7". Nhất Nghệ phối hợp cùng Microsoft Việt Nam biên soạn 1 bộ hands-on Lab giúp các bạn khám phá những tính năng ưu việt của Windows 7.

Bộ Lab gồm 11 bài được biên soạn ở dạng tài liệu "step-by-step" theo 3 cấp độ: Beginer - Advanced - Expert.





A. CẤP ĐỘ BEGINNER

LEVEL 1 - LAB 1: WINDOWS 7 INSTALL – MIGRATE – UPGRADE

I. GIỚI THIỆU

Bài lab triển khai:

- Cài đặt mới (clean installation) Windows 7.
- Chuyển dữ liệu người dùng từ một máy Windows 7 sang một máy Windows 7 khác.
- Nâng cấp một máy Windows Vista Ultimate Service Pack 1 thành một máy Windows 7 và giữ nguyên mọi thông tin hiện có.

Các bước thực hiện:

A. Cài đặt mới: Thực hiện trên máy chưa có hệ điều hành, dùng đĩa DVD source Windows 7.
B. Chuyển dữ liệu người dùng: Thực hiện trên máy Windows 7 vừa cài đặt xong ở phần A
C. Nâng cấp: Thực hiện trên một máy Windows Vista Ultimate Service Pack 1, dùng đĩa DVD source Windows 7.

Xem chi tiết...

LEVEL 1 - LAB 2: WINDOWS 7 USER ACCOUNT CONTROL

I. GIỚI THIỆU

Bài lab triển khai trên một máy Windows 7 với mục tiêu khảo sát và thử nghiệm một số thông số liên quan đến cơ chế User Account Control (UAC)

Các bước thực hiện:

A. Thay đổi thông số UAC
B. Khảo sát phản ứng của UAC Notifications level 1
C. Khảo sát phản ứng của UAC Notifications level 2
D. Tắt chức năng UAC


Xem chi tiết...

LEVEL 1 - LAB 3: WINDOWS 7 BITLOCKER

I. GIỚI THIỆU

BitLocker là một tính năng tích hợp của Windows 7 có khả năng tăng cường bảo mật dữ liệu bằng cách mã hóa dữ liệu trên các phương tiên lưu trữ (hard disk drive, USB drive). Khi muốn truy cập thông tin, người dùng buộc phải nhập mật khẩu.

Các bước thực hiện:

A. Kích hoạt & Cấu hình BitLocker trên một đĩa USB.
B. Kiểm tra kết quả.
C. Thay đổi mật khảu BitLocker.
D. Phục hồi mật khẩu cũ
E. Tắt BitLocker

Xem chi tiết...


LEVEL 1 - LAB 4: INTERNET EXPLORER 8

I. GIỚI THIỆU

Windows 7 tích hợp trình duyệt Internet Explorer 8. Bài lab thử nghiệm cấu hình một số tính năng nổi bật của trình duyệt này.

Các bước thực hiện:

A. Khởi động IE 8

B. InPrivate Browsing
Khi người dùng truy cập vào trang web bất kỳ (ví dụ như kiểm tra thư, mua hàng trực tuyến, ...), trình duyệt sẽ lưu lại các thông tin như các tập tin cookie, các tập tin Internet tạm thời … đặc biệt là tên người dùng và mật khẩu (thông tin thường hay được ghi nhớ trong trình duyệt). Chức năng InPrivate Browsing có thể cấu hình để trình duyệt muốn lưu lại các thông tin đó.

C. SmartScreen Filter
Các trang web độc hại (hoặc ngụy trang) được cải tiến rất đa dạng với mục đích đánh cắp dữ liệu cá nhân như mật khẩu hay số thẻ tín dụng. SmartScreen Filter giúp bảo vệ máy tính của người dùng tốt hơn bằng cách cảnh báo người dùng khi họ đang truy cập các trang web (hoặc tải các tập tin) không an toàn. SmartScreen Filter hoạt động ở chế độ ngầm định.

D. Web Accelerators
Đơn giản hóa thao tác xác định vị trí của một địa điểm trên bản đồ bằng biểu tượng Accelerator. Người dùng có thể cài đặt Accelerators từ các trang web như Facebook hay bất kỳ trang web nào thường sử dụng.

E. Web Slices
Công cụ giúp người dùng cập nhật những thông tin của những trang web mà họ thường xuyên truy cập.


Xem chi tiết...

B. CẤP ĐỘ ADVANCED

LEVEL 2 - LAB 1: NGĂN CHẶN DÙNG PHẦN MỀM TRÊN WINDOWS 7

I. GIỚI THIỆU

Bài lab triển khai:
Bài lab dùng 01 máy Windows 7 thực hiện các thao tác cấu hình ngăn chặn người dùng sử dụng một số phần mềm.

Các bước thực hiện:

A. Chuẩn bị
1. Kích hoạt user account built-in Administrator & cài Yahoo Messenger
2. Tạo 2 user account – dùng chương trình Yahoo Messenger

B. Dùng Application Locker cấm user dùng Yahoo Messenger
1. Kích hoạt dịch vụ Application Identity
2. Cấu hình ApplicationLocker – Kiểm nghiệm

C. Dùng Software Restriction Policies cấm user dùng chương trình Calculator – Kiểm nghiệm


Xem chi tiết...


LEVEL 2 - LAB 2: WINDOWS 7 FIREWALL

I. GIỚI THIỆU

Bài lab dùng 01 máy Windows 7 thực hiện cấu hình một số tính năng của Windows 7 Firewall

Các bước thực hiện:

A. Khảo sát Windows Firewall Basic Interface

B. Dùng Windows Firewall Advanced Security Snap-in cấm truy cập internet


Xem chi tiết...


LEVEL 2 - LAB 3: WINDOWS 7 BACKUP - RESTORE

I. GIỚI THIỆU

Bài lab dùng 01 máy Windows 7 thực hiện công tác sao lưu và phục hồi dữ liệu

Các bước thực hiện:

A. Cấu hình Reconfiguring a Backup

B. Tạo đĩa phục hồi hệ thống

C. Cấu hình bảo vệ hệ thống

D. Tạo điểm phục hồi

E. Kiểm tra


Xem chi tiết...


LEVEL 2 - LAB 4: CÀI ĐẶT WINDOWS 7 TỰ ĐỘNG
(WINDOWS 7 UNATTENDED SETUP)


I. GIỚI THIỆU

Bài lab thực hiện các bước chuẩn bị và tiến hành cài đặt tự động Windows 7

Các bước thực hiện:

A. CHUẨN BỊ: Thực hiện trên máy Windows 7
1. Cài đặt Windows Automatic Installation Kit (Windows AIK).
2. Dùng Windows AIK tạo unattended setup answer file.
3. Tạo đĩa DVD cài đặt tự động.

B. CẢI ĐẶT TỰ ĐỘNG: Thực hiện trên một máy chưa cài đặt hệ điều hành.


Xem chi tiết...


C. CẤP ĐỘ EXPERT

LEVEL 3 - LAB 1: CÀI ĐẶT WINDOWS 7 TỰ ĐỘNG
QUA MẠNG


I. GIỚI THIỆU

Bài lab thực hiện các bước chuẩn bị và tiến hành cài đặt tự động Windows 7 trên hàng loạt máy mục tiêu.

Để thực hiện bài lab, cần có 03 máy cùng nối vào 01 switch:
- 01 máy Windows Server 2008 R2 đã nâng cấp domain controller
- 01 máy Windows 7
- 01 máy mục tiêu chưa cài đặt hệ điều hành.
- Cấu hình IP của Windows Server 2008 R2:
+ Ip Address: 192.168.1.254
+ Subnet Mask: 255.255.255.0
+ Preferred DNS : 192.168.1.254

Các bước thực hiện:

A. CHUẨN BỊ: Thực hiện trên máy Windows 7
1. Cài đặt Windows Automatic Installation Kit (Windows AIK).
2. Dùng Windows AIK tạo unattended setup answer file.
3. Tạo đĩa DVD cài đặt tự động.

B. CẤU HÌNH WINDOWS DEPLOYMENT SERVICES SERVER: Thực hiện trên DC
1. Cài đặt & cấu hình DHCP server
2. Cài đặt Windows Deployment Services server
3. Cấu hình Windows Deployment Services server
4. Cấu hình các image
5. Bổ sung cấu hình install image & cấu hình server

C. CÀI ĐẶT TỰ ĐỘNG QUA MẠNG: Thực hiện tại PC mục tiêu


Xem chi tiết...


LEVEL 3 - LAB 2: BRANCHCACHE


I. GIỚI THIỆU
Đối với một hê thống mạng công ty có nhiều chi nhánh, các user tại văn phòng chi nhánh thường xuyên truy cập dữ liệu đến các Server tại trụ sở chính thông qua đường truyền WAN. Khi số lượng truy cập quá nhiều trong cùng thời điểm thì dẫn đến tốc độ truy cập chậm hoặc truy cập thất bại.

BranchCache được phát triển nhằm giải quyết vấn đề nêu trên. BranchCache là 1 tính năng mới trong Windows Server 2008 R2 và Windows 7, có chức năng giảm thiểu lưu lượng truy cập file, lưu lượng truy cập website hoặc tăng tốc độ truy cập của các ứng dụng thông qua đường truyền WAN khi người dùng tại chi nhánh truy cập đến server tại văn phòng chính.

Bài lab này trình bày cách triển khai Branch Cache theo mô hình Distributed Cache

Các bước thực hiện:

A. CẤU HÌNH SERVER WINDOWS SERVER 2008 R2
1. Add feature Branch Cache
2. Cấu hình File server hỗ trợ Branch cache
3. Dùng policy để cấu hình BranchCache server
4. Cấu hình BranchCache trên shared folder

B. CẤU HÌNH BRANCHCACHE TRÊN CLIENT WINDOWS 7

C. KIỂM NGHIỆM: Client chép dữ liệu & giám sát tại Server
1. Cấu hình monitor counter tại server
2. Client chép dữ liệu và giám sát tại server


Xem chi tiết...


LEVEL 3 - LAB 3: VPN RECONNECT

I. GIỚI THIỆU

VPN Reconnect là một tính năng kết nối VPN mới được phát triển trên Windows 7 và Windows Server 2008 R2.

Thông thường khi thực hiện kết nối VPN qua internet, nếu vì một lý do nào đó mà kết nối internet bị gián đoạn thì kết nối VPN sẽ chấm dứt và ngưới dùng buộc phải kích hoạt lại kết nối VPN.

Kết nối VPN reconnect từ client Windows 7 đến server Windows Server 2008 R2 có khả năng tự động tái kết nối ngay lập tức mà không cần bất cứ sự can thiệp nào từ người dùng

Các bước thực hiện:

A. CẤU HÌNH SERVER
1. Xây dựng Enterprise Root Certification Authority
2. Chuẩn bị certificate template để cấp cho VPN server
3. Cấu hình certificate cho VPN server
4. Export certificate của Certification Authority
5. Tạo user account & cấp quyền kết nối VPN
6. Cấu hình VPN server

Copy from Trong – NN Blog