Security is a PROCESS

Win 7 pro
HW886-4R7HC-H9T3D-G6JMG-V8FJ8

win 7 Enterprise 
FHKXR-WCPQW-D644P-R2BJQ-6KHV7

Key Win7 : BR2KH-T22XP-Q4JH7-TCF9T-C2MYF

Nguồn: http://linux.web.cern.ch/linux/scientific4/docs/rhel-rg-en-4/s1-tcpwrappers-xinetd.html

1. Khái niệm
xinetd daemon (viết tắt của eXtended InterNET Daemon) là một TCP wrapped super service, để kiểm soát truy cập một tập con những dịch vụ mạng thông dụng như: FTP, IMAP và Telnet, ... Nó cũng cung cấp những tuỳ chọn cấu hình xác định để kiểm soát truy cập, logging, binding, redirection và việc sử dụng tài nguyên

Khi client thử kết nối đến một dịch vụ mạng được kiểm soát bởi xinetd, nó nhận được yêu cầu và kiểm tra bất kỳ truy cập TCP wrappers nào. Nếu truy cập được cho phép, xinetd xác nhận rằng kết nối được cho phép dưới access rules cho dịch vụ đó, và dịch vụ đó được gán một lượng tài nguyên xác định được định nghĩa trong rules. Sau đó một instance của dịch vụ yêu cầu được khởi tạo và trao sự kiểm soát kết nối cho nó. Khi kết nối được thiết lập, xinetd không gây bất cứ trở ngại nào trong việc giao tiếp giữa client host và server nữa.

2. Các files cấu hình cho xinetd
Những files cấu hình cho xinetd như sau:
/etc/xinetd.conf - File cấu hình toàn cục
Thư mục /etc/xinetd.d - thư mục chứa tất cả các file cấu hình cho mỗi dịch vụ xác định

File cấu hình /etc/xinetd.conf

xinetd.conf chứa đựng các cấu hình chung cho tất cả các dịch vụ được kiểm soát bởi xinetd. Nó chỉ được đọc khi dịch vụ xinetd được khởi tạo, do đó bất kỳ thay đổi nào trong cấu hình, bạn đều phải restart (hoặc reload) xinetd để có hiệu lực. Dưới đây là ví dụ cho Fedora 8:
Code:

 defaults
{
log_type = SYSLOG daemon info
log_on_failure = HOST
log_on_success = PID HOST DURATION EXIT

cps  = 50 10
instances = 50
per_source = 10
}

includedir /etc/xinetd.d

Ý nghĩa của các tham số:
log_type: SYSLOG authpriv: chỉ định đầu ra của service log. Bạn có thể gửi nó đến SYSLOG
log_on_success: Cấu hình cho việc log nếu kết nối thành công. HOST name và Process ID sẽ được log vào /var/log/secure
log_on_failure: cấu hình cho việc log khi kết nối bị dropped hoặc không được phép truy cập /var/log/secure
cps: giới hạn tỷ lệ các kết nối. Bao gồm 2 tham số. Tham số đầu tiên là giới hạn số lượng kết nối trong 1s. Nếu tỷ lệ các kết nối cao hơn giá trị này, dịch vụ sẽ tạm thời bị disabled. Tham số thứ 2 là thời gian chờ (tính bằng s) để enable lại dịch vụ sau khi nó bị disabled. Giá trị mặc định là 50 connections và thời gian nghỉ là 10s
instances: số lượng lớn nhất các requests mà xinetd có thể handle tại một thời điểm
per_source: giới hạn số lượng kết nối cho mỗi địa chỉ nguồn
includedir: đọc các file cấu hình cho các dịch vụ khác nằm trong thư mục /etc/xinetd.d

Thư mục /etc/xinetd.d

Thư mục này chứa đựng các file cấu hình cho mỗi dịch vụ được quản lý bởi xinetd. Cũng như xinetd.conf, thư mục này cũng chỉ được đọc khi xinetd được khởi tạo. Để bất kỳ thay đổi này có hiệu lực, bạn phải khởi động lại dịch vụ xinetd
Định dạng của các file nằm trong thư mục /etc/xinetd.d cũng sử dụng quy ước tương tự như /etc/xinetd.conf. Lý do chính để cấu hình của mỗi dịch vụ được lưu trong 1 file riêng biệt là nhằm tạo sự dễ dàng trong việc tuỳ biến, cũng như đỡ ảnh hưởng đến các dịch vụ khác

Ví dụ về rsync:
Code:

 # default: off
# description: The rsync server is a good addition to an ftp server, as it \
# allows crc checksumming etc.
service rsync
{
disable = yes
flags  = IPv6
socket_type     = stream
wait            = no
user            = root
server          = /usr/bin/rsync
server_args     = --daemon
log_on_failure  += USERID
}

Ý nghĩa các tham số:
service: định nghĩa tên dịch vụ, luôn phải thuộc /etc/services
disable: dịch vụ có được active hay không
flags: Gán thuộc tính cho kết nối.
socket_type: loại socket mạng. Trường này có thể nhận các giá trị: stream, dgram, raw
wait: định nghĩa dịch vụ là single-threaded (yes) hay multi-threaded (no)
user: người dùng có quyền chạy dịch vụ đó. root hoặc nobody thường được dùng ở đây.
server: đường dẫn của dịch vụ
server_args: chỉ định các tham số đưa vào cho server. Trong ví dụ này: rsync là một daemon nên yêu cầu đưa vào tuỳ chọn --daemon
log_on_failure: định nghĩa các tham số logging được thêm vào với những gì đã định nghĩa trong xinetd.conf

Làm việc với xinetd
Khởi động dịch vụ:
Code:

# /etc/init.d/xinetd start

Dừng dịch vụ:
Code:

# /etc/init.d/xinetd stop

Xác định xem xinetd có đang chạy hay không
Code:

 # /etc/init.d/xinetd status
xinetd (pid 2110) is running...

Khởi động lại dịch vụ
Code:

# /etc/init.d/xinetd restart

Nguồn: http://www.linux.com/feature/121916

Khi máy tính cần chạy những chương trình lớn hơn khả năng có thể của bộ nhớ vật lý (RAM), hệ điều hành sẽ sử dụng một công nghệ có tên gọi swapping. Nói nôm na thì công nghệ này sẽ dùng đến những mảng bộ nhớ tạm được lưu trên đĩa cứng, trong khi phần dữ liệu khác vẫn được chuyển vào RAM. Công nghệ này giúp bạn quản lý việc hoán đổi (swapping) tốt hơn cũng như tăng hiệu năng sử dụng.

Linux chia bộ nhớ vật lý thành các pages. swapping là một tiến trình thực hiện việc copy một page của bộ nhớ đến một không gian đã được cấu hình trước trên đĩa cứng (gọi là swap space), để giải phóng các pages của bộ nhớ. Tổng dung lượng của RAM và không gian hoán đổi (swap space) chính là tổng số bộ nhớ ảo (virtual memory)

swapping cần thiết vì 2 lý do:
1. Khi hệ thống yêu cầu một lượng bộ nhớ nhiều hơn mức RAM cho phép, chức năng hoán đổi của kernel sẽ đẩy bớt các pages được dùng ít hơn ra ngoài và gửi lượng bộ nhớ cho ứng dụng đang cần ngay lập tức.
2. Có một số pages quan trọng được sử dụng bởi 1 ứng dụng trong suốt quá trình startup, có thể chỉ được dùng cho khởi tạo thôi, sau đó không bao giờ dùng lại nữa, hệ thống có thể swap out những pages này ra, giải phóng bộ nhớ cho những ứng dụng khác, hoặc cho việc cache đĩa.

Tuy nhiên, swapping có một bất lợi. Tốc độ truy cập đĩa (milliseconds) chậm hơn từ 10 đến 1000 lần so với tốc độ truy cập RAM (nanoseconds). Thỉnh thoảng sẽ xảy ra sự trao đổi quá mức, kiểu như: một pages vừa được swapped out, ngay sau đó lại
swapped in rồi lại swapped out và cứ thế. Trong trường hợp này, hệ thống vừa phải vật lộn để tìm những phần bộ nhớ rỗi, vừa phải giữa cho các ứng dụng kia vẫn chạy. Cách tốt nhất trong tình huống này là tăng RAM lên.

Có 2 loại swap space, đó là: swap partition và swap file. swap partition là một phân vùng độc lập nằm trên đĩa cứng, chỉ có mục đích là hoán đổi (swapping), không có file nào khác nằm trên đó. swap file là một file riêng biệt nằm trên hệ thống, nó có thể nằm giữa hệ thống của bạn và các file dữ liệu

Để xem swap space trên hệ thống, bạn có thể dùng lệnh swapon -s
Code:

 $ swapon -s
Filename                 Type            size    Used    Priority
/dev/sda9                partition       1132540 0       -1

Mỗi dòng là một swap space tách biệt trên hệ thống của bạn. Type chỉ ra rằng swap space là partition hay file. Filename như bạn thấy là sda9 (partition). size là kích cỡ tính bằng KB của swap space. Used là lượng swap hiện đang được dùng. Priority chỉ ra swap nào sẽ được dùng trước (nếu bạn có nhiều swap). Một điều thú vị là: nếu bạn mount 2 hoặc nhiều swap space trên 2 thiết bị khác nhau với cùng độ ưu tiên, hệ thống sẽ thực hiện xen kẽ việc swapping giữa 2 swap space này để tăng performance.

Thêm 1 swap partition vào hệ thống
+ Xác định partition nào sẽ lấy làm swap
Code:

 # fdisk -l
/dev/sda9         swap      swap    defaults        0 0

+ Tạo hệ thống file swap cho nó
Code:

# mkswap /dev/sda9

+ Kích hoạt nó ngay lập tức:
Code:

# swapon /dev/sda9

+ Xác nhận xem nó đã được dùng chưa bằng lệnh:
Code:

# swapon -s

Để mount swap space tự động khi boot, bạn chỉnh sửa /etc/fstab và thêm vào một dòng tương tự như:

/dev/sda9 swap swap defaults 0 0

Để kiểm tra xem swap space đã được mounted tự động chưa mà không cần reboot, bạn có thể gõ, swapoff -a, sau đó lại swapon -a và check bằng swapon -s

Swap file cũng hoàn toàn tương tự như swap partition. Thuận lợi của nó là không cần tìm một partition độc lập hoặc phân vùng lại đĩa cứng để thêm vào. Có thể tạo swap file bằng lệnh dd như sau:
Code:

dd if=/dev/zero of=/swapfile bs=1024 count=1048576

Lệnh này tạo một file trống có kích thước 1048576 KB (1GB), với tên gọi swapfile

Tạo và mount nó:
Code:

 mkswap /swapfile
swapon /swapfile

Thêm một dòng vào /etc/fstab cũng tương tự như trên:

/swapfile swap swap defaults 0 0

Tôi nên dành bao nhiêu dung lượng cho swap space?
Không có một nguyên tắc nào cả, nhưng mọi người thường chia theo quy luật:
+ Hệ thống Desktop: nên để bằng 2*RAM - đủ để bạn chạy một số lượng lớn các ứng dụng
+ Server: cần ít hơn (có người cho rằng chỉ cẩn để bằng 1/2*RAM). Tuy nhiên bạn cần theo dõi swap space và tăng lượng RAM nếu cần thiết
+ Older desktop (hệ thống có ít RAM - 128 MB chẳng hạn): bạn có thể dành 3*RAM cho swap, hoặc có thể để 1GB.

Với Linux kernel 2.6 có 1 tham số mới là swappiness - để bạn có thể tweak cách mà Linux hoán đổi. Tham số này có giá trị từ 0 đến 100. Giá trị cao có nghĩa là nhiều paged được swapped, giá trị thấp có nghĩa là nhiều ứng dụng được giữ trong bộ nhớ - ngay cả khi chúng không làm gì cả (idle). Giá trị mặc định của swapiness là 60, bạn có thể thay đổi nó tạm thời (reboot mới có hiệu lực thật sự) bằng lệnh sau (với root):
Code:

echo 50 > /proc/sys/vm/swappiness

Nếu bạn muốn thay đổi vĩnh viễn, có thể chỉnh vm.swappiness trong /etc/sysctl.conf

Quản lý swap space là công việc cần thiết của người quản trị hệ thống. Một kế hoạch tốt kết hợp với việc sử dụng đúng đắn sẽ đem lại nhiều lợi ích. Đừng sợ thử nghiệm, hãy luôn luôn theo dõi hệ thống của bạn, chắc chắn bạn sẽ thu được những kết quả mong muốn.

QuanTA.

Nguồn:
http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html
http://www.sun.com/bigadmin/content/submitted/umask_permissions.html

umask là gì?
umask được sử dụng để kiểm soát quyền mặc định của các files mới khi nó được tạo ra. umask gồm 4 chữ số trong hệ cơ số 8 (four-digit octal)

Gán umask mặc định như thế nào?
Bạn có thể gán umask mặc định trong /etc/bashrc hoặc /etc/profile cho tất cả các users. Phần lớn các distro đều gán là 0022 hoặc 0002.
Để gán umask cho một user xác định nào đó, bạn có thể chỉnh sửa ~/.bashrc của user đó và thêm vào dòng sau:

umask 022

Lưu lại, logout và login lại để thay đổi trên có hiệu lực.

0022 và 0002 nghĩa là gì?
umask mặc định 0002 được sử dụng cho normal user. Với mặt nạ (mask) này, quyền mặc định của thư mục sẽ là 775 và quyền mặc định của file sẽ là 664.

umask mặc định cho root là 0022, nghĩa là quyền mặc định của thư mục sẽ là 755 và quyền mặc định của file sẽ là 644.

Nôm na bạn có thể hiểu rằng: Trước khi file hoặc thư mục được tạo ra, quyền truy cập đối với chúng được xác định dựa vào hai giá trị: quyền truy cập cơ sở (base permissions) và mặt nạ (mask). Đối với thư mục, quyền truy cập cơ sở là 0777(rwxrwxrwx), còn đối với files là 0666 (rw-rw-rw).

Thiết lập giá trị mask như thế nào?
Giá trị "mask" được thiết lập nhờ lệnh umask. Tất cả các file và thư mục được tạo ra sau đó sẽ chịu ảnh hưởng của giá trị mask mới.

Để tính toán quyền truy cập thư mục với umask 022 (root user):
Quyền truy cập mặc định: 777
Giá trị umask: 022
Quyền truy cập cho phép: 755

Để tính toán quyền truy cập file với umask 022 (root user):
Quyền truy cập mặc định: 666
Giá trị umask: 022
Quyền truy cập cho phép: 644

Lấy một ví dụ đơn giản: Bạn cần gán umask để các files được tạo ra sau đó sẽ có permissions là 600.
Ta có:
Quyền truy cập mặc định: 666
Giá trị umask: 066
Quyền truy cập cho phép: 600

Code:

 $ umask 066
$ touch test.txt
$ ls -l test.txt
-rw------- 1 quanta quanta 0 2008-02-16 17:38 test.txt

Quyền truy cập cho phép là kết quả giữa phép toán sau:

Quyền truy cập cho phép = "quyền truy cập mặc định" AND (NOT (Giá trị umask))

Ví dụ:
Quyền truy cập mặc định: 666 = 110 110 110
Giá trị umask: 123 = 001 010 011
--> NOT (Giá trị umask) = NOT (001 010 011) = 110 101 100
Quyền truy cập cho phép = 110 110 110 AND 110 101 100 = 110 100 100 = 644

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. smilie

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!

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 smilie

)

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.

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)

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ế.

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

- 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).

OfficeMalScanner file.doc scan brute	Locate shellcode, OLE data, PE files in file.doc
OfficeMalScanner file.doc info	Locate VB macro code in file.doc (no XML files)
OfficeMalScanner file.docx inflate	Decompress file.docx to locate VB code (XML files)
DisView file.doc 0x4500	Disassemble shellcode at 0x4500 in file.doc
MalHost-Setup file.doc out.exe 0x4500	Extract shellcode from file.doc’s offset 0x4500 and create it as out.exe

pdfid.py file.pdf	Locate script and action-related strings in file.pdf
pdf-parser.py file.pdf	Show file.pdf’s structure to identify suspect elements
pdfscan.rb file.pdf	Examine and display file.pdf’s structure (Usage)
pdftk file.pdf output out.pdf uncompress	Uncompress page streams in file.pdf and save the result in out.pdf

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

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.

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.

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

Monday, December 28, 2009

Thursday, December 24, 2009

Friday, December 18, 2009

Tuesday, December 15, 2009

Monday, December 14, 2009

Wednesday, December 9, 2009

Monday, December 7, 2009

General Approach

Microsoft Office Binary File Format Notes

Tools for Analyzing Microsoft Office Files

Useful MS Office Analysis Commands

Adobe PDF File Format Notes

Tools for Analyzing Adobe PDF Files

Useful PDF Analysis Commands

Additional Malicious File Analysis Tools

References

Post-Scriptum

Tuesday, November 24, 2009

Monday, November 23, 2009

Sunday, November 22, 2009

Thursday, November 19, 2009

Wednesday, November 11, 2009

Tuesday, November 10, 2009

Sunday, November 8, 2009

Monday, November 2, 2009

Windows 7 Hands On Lab - Step By Step

Wednesday, October 28, 2009

Tuesday, October 27, 2009