Thử thêm resume=/dev/sda4 vào cuối dòng kernel trong /boot/grub/menu.lst xem thông báo "Unable to access resume device SWAP-sda4" có mất đi không?
 

Nguyên văn đây:

cái SWAP-sda4 chỉ là LABEL cho /dev/sda4 thôi 

Trước khi bạn thực hiện # swapoff -a, Linux lưu label của /dev/sda4 là SWAP-sda4, trong /etc/fstab chứ còn ở đâu nữa.
 

Thử thêm resume=/dev/sda4 vào cuối dòng kernel trong /boot/grub/menu.lst xem thông báo "Unable to access resume device SWAP-sda4" có mất đi không?
 

enn3exlibs wrote:

quanta wrote:

Không những nó không được auto mount nữa mà khi khởi động tớ nghĩ bạn sẽ gặp thông báo sau:

Unable to access resume device SWAP-sda4 

 

uhm, mình phải thêm noresume vào /etc/fstab:

... ro root=LABEL=/ rhgb quiet noresume 

 

Ý bạn nói là: khi bạn thêm noresume vào /boot/grub/menu.lst thì cái thông báo kia mới mất hả? Không cần mà, chỉ cần chỉnh lại trong /etc/fstab, sau đó gõ Code:

# swapon /dev/sda4

là OK (tớ đã test).
 

enn3exlibs wrote:

Vấn đề là cơ chế để thay thế /dev/sda4 bằng SWAP-sda4 mà vẫn mount partition sda4? 

Ý bạn là: muốn để SWAP-sda4 trong /etc/fstab mà vẫn auto mount được? Tớ nghĩ là không thể. Lý do: có lẽ cái LABEL=SWAP-sda4 sẽ mất đi khi bạn dùng Code:

# swapoff -a

sau này có muốn gán lại nó cũng không hiểu nữa. Và chỉ có cách duy nhất là dùng /dev/sda4 (device name) nó mới hiểu.
Làm gì có "cơ chế thay thế" gì đâu.
 

SWAP-sda4 swap swap defaults 0 0

Không những nó không được auto mount nữa mà khi khởi động tớ nghĩ bạn sẽ gặp thông báo sau:

Unable to access resume device SWAP-sda4 

 

... ro root=LABEL=/ rhgb quiet noresume 

Vậy nó đừng sờ sờ trước modem ADSL và Internet nhằm mục đích gì? Anh em cho ý kiến thử xem. hehe
 

3- Không ít website lại không detect ra WAN IP của chính máy ta, mà detect ra một WAN IP khác ( thí dụ không detect ra WAN IP 203.126.7.125, như đã nói ở điểm 1 trên đây, mà detect ra một WAN IP khác, thí dụ 203.126.7.100 chẳng hạn.

Vậy thì cái đia chỉ WAN IP 203.126.7.100 này là WAN IP của gate way server của mạng ADSL của ISP hay là của Cache Proxy server của ISP. Khi nào nó là của Gate way server, khi nào là của Cache Proxy server ? Tai sao?
( Proxy server có nhiều loại, ở đây phải gọi là Cache Proxy server cho chính xác, để phân biệt với anonymous proxy servers chẳng hạn)
 

enn3exlibs wrote:

conmale wrote:

Cơ chế kiểm tra (và lấy IP) của user từ HVA như sau:
1) nếu trên HTTP header có giá trị x-forwarded-for thì nó sẽ dùng IP của giá trị này. Đây chính là giá trị public IP thật sự của em.
 

chào anh,
Hình như cơ chế kiểm tra IP của hva không đúng, không hiển thị ip trong trường x-forwarded-for của http header, trong khi một số trang khác hiển thị địa chỉ này, phải chăng có cơ chế khác để lấy địa chỉ "thực" nếu http header không có giá trị x-forwarded-for?
--> cũng có thể là private IP


 

HTTP header "X-Forwarded-For" không phải là header chính thức và tiêu chuẩn của HTTP 1.1 cho nên không thể bắt buộc proxy phải ứng dụng. Bởi thế, nếu proxy không ứng dụng và không kèm theo giá trị này thì khi request đụng đến HVA web server, giá trị của nó là "null". Nếu vậy, IP được dùng để hiển thị trên diễn đàn chính là IP của proxy server. Phương pháp "lấy" IP của HVA là phương pháp "non-intrusive", có nghĩa là proxy cho gì lấy nấy chớ không "đòi" client phải gởi cụ thể cái gì cả. Nếu header đi từ client xuyên qua proxy không có giá trị "x-forwarded-for" hoặc bị proxy lột mất thì chẳng có gì để ghi nhận cả.

Để lấy IP thật sự của client, server phải request client "cái gì đó" và tùy ở proxy có chịu chuyển gởi request này đến client hay không. Cũng tùy ở client có "chịu" gởi trả lời hay không nữa.
 

Để lấy IP thật sự của client, server phải request client "cái gì đó" và tùy ở proxy có chịu chuyển gởi request này đến client hay không. Cũng tùy ở client có "chịu" gởi trả lời hay không nữa.
 

Cơ chế kiểm tra (và lấy IP) của user từ HVA như sau:
1) nếu trên HTTP header có giá trị x-forwarded-for thì nó sẽ dùng IP của giá trị này. Đây chính là giá trị public IP thật sự của em.
 

Thế cụ thể như trường hợp của tớ : Dùng gói Mega YOU của FPT Telecom đây , IP mà các anh kĩ thuật lắp máy đặt cho mình là 192.168.1.33 và IP của mình trên IP-adress.com là : 118.71.183.36 .
Bạn y3ndtx bảo người ta nói bậy thì bạn hãy giải thích giúp tớ trường hợp của tớ đi . Thankss  

Tal wrote:

Khi máy A cần chuyển dữ liệu đến default gateway, nó cần biết địa chỉ MAC của router. Ví dụ địa chỉ IP của router là: 172.28.88.1. Em chạy Switch Sniffer (SW) trên máy B.

Quá trình: máy A gửi broadcast một ARP request đến tất cả các máy trong mạng hỏi địa chỉ MAC của máy có IP 172.28.88.1. Do máy B chạy SW nên sẽ nhận nó có IP 172.28.88.1 và sẽ gửi địa chỉ MAC của máy nó cho A, và máy A sẽ tưởng nhầm đó địa chỉ MAC của router. Do đó tất cả các gói tin A -> router sẽ qua B. Tất nhiên router cũng sẽ trả lời A và sẽ cho A địa chỉ MAC của nó. Vậy reply nào (B -> A, router->A) đến trước sẽ chiếm kết nối từ A trước.

Câu hỏi của em là làm sao mà ARP reply của B (chạy SW) luôn đến trước vì đâu có gì bảo đảm là nó có thể gửi reply nhanh hơn router.  

Switch sẽ update các entry, trừ khi được set tĩnh

 

@enn3exlibs: trả lời ko liên quan đến hỏi.

 

Khi máy A cần chuyển dữ liệu đến default gateway, nó cần biết địa chỉ MAC của router. Ví dụ địa chỉ IP của router là: 172.28.88.1. Em chạy Switch Sniffer (SW) trên máy B.

Quá trình: máy A gửi broadcast một ARP request đến tất cả các máy trong mạng hỏi địa chỉ MAC của máy có IP 172.28.88.1. Do máy B chạy SW nên sẽ nhận nó có IP 172.28.88.1 và sẽ gửi địa chỉ MAC của máy nó cho A, và máy A sẽ tưởng nhầm đó địa chỉ MAC của router. Do đó tất cả các gói tin A -> router sẽ qua B. Tất nhiên router cũng sẽ trả lời A và sẽ cho A địa chỉ MAC của nó. Vậy reply nào (B -> A, router->A) đến trước sẽ chiếm kết nối từ A trước.

Câu hỏi của em là làm sao mà ARP reply của B (chạy SW) luôn đến trước vì đâu có gì bảo đảm là nó có thể gửi reply nhanh hơn router.  

bạn thử set up một con ISA 2000 và set một rule deny_all ở phía dưới xem?
 

ại sao lại cho phép mọi thứ đi vào vậy anh? em xin nêu: "ở dòng cuối cùng" nó khác với ở dòng trên cùng, trước khi đến dòng cuối cùng thì đã bị chặn từ trên. Em thật sự không biết có fw nào hoạt động ngược lại( nghĩa là nó xử lý rule từ dưới lên) nếu có thì quả là em phải tìm hiểu thêm mới dám hỏi.
 

Thế này, có firewall xử lí rule từ trên xuống, cũng có firewall xử lí rule từ dưới lên, cái quan trọng là bạn đặt câu hỏi trong khi đang thử nghiệm firewall nào.
 

Vấn đề này đâu đáng để đi đến "xung đột" quá đáng nhỉ?
 

-Trường hợp firewall xét rule từ trên xuống, cũng thế nhưng ngược lại thôi.
-Trường hợp firewall của bạn xét rule từ trên xuống: allow_all đặt trên đầu thì allow tất cả (như bạn nói), firewall vô tác dụng, nếu ta sắp xếp các rule deny_one trên rule allow_all này thì ngoài các thứ bị "deny", các thứ còn lại đi vào được hết.


**Thử trả lời câu hỏi của bạn:
Nếu dùng Allow_all, bạn phải liệt kê từng thứ một muốn deny, có nghĩa bạn phải tạo một dãy rule dài dòng, phức tạp phía trên rule allow_all

deny xxx from A to B 

Theo yêu cầu của bạn _ngăn mọi nguồn có khả năng gây nguy hại có thể_, bạn phải tạo bao nhiêu rule như trên?

Câu hỏi của anh Conmale _ Cái gì khiến cho em có ý tưởng khai triển từ hướng "allow_all" vậy?_ chắc là ám chỉ điều này


Nếu dùng deny_all bạn sẽ tiết kiệm đc nhiều công sức viết rule, và sắp xếp rule cho hợp lí.

--Vài ý kiến 

SYN request không phải là câu lệnh 

uh ! vậy tớ muốn gửi làm cho victim gửi SYN request lại thì làm cái gì ?
thông cảm tớ mới tìm hiểu về DDos 

Công ty mình cài mạng Domain, bộ phận IT cấm một số máy không được vào các trang upload(như megaupload, yousendit ...), cấm vào yahoo, google, và nhiều trang khác. Cấm dùng cả firefox. Có một số lãnh đạo cao hơn vẫn vào được rất nhiều trang và hầu như không bị cấm.

Lúc trước em đổi Gate way thì có thể thoát khỏi những ngăn cản này. Nhưng bây giờ không làm như vậy được nữa.

Xin hỏi có các nào để thoát khỏi được những ngăn cản do bộ phận IT đặt ra như trên không?

Cảm ơn các đại hiệp đã giúp đỡ. 

enn3exlibs wrote:

em đã đọc kỹ rồi mới gởi bài mới. Anh phán: "firewall của em hoàn toàn vô dụng". Thứ nhất fw kiểu này không phải hoàn toàn vô dụng, vẫn được dùng khi không đòi hỏi khắt khe về bảo mật, hay dữ liệu bị mất không ảnh hưởng nghiêm trọng, dùng để ngăn một số nguồn nguy hại cụ thể. Thứ hai từ đầu em có đề cập đến hiệu năng của fw đâu?

thực sự từ đầu những bài viết của anh quá xa với câu hỏi của em, vì muốn tìm hiểu em mới nhiều lần giải thích câu hỏi của mình, thôi em kết thúc ở đây.


 

Thiếu! đừng bỏ bớt câu nói của người khác ra và nhảy thẳng đến kết luận. "Nếu em dùng allow all ở dòng cuối cùng, firewall của em hoàn toàn vô dụng". Vô dụng bởi vì rốt cuộc nó cho phép mọi thứ đi vào. Nếu chưa hiểu thì chịu khó tìm hiểu thêm.
 

Ngay từ đầu em nói rằng "ngăn mọi nguồn có khả năng gây nguy hại có thể", đây không phải là hiệu năng của FW thì là cái gì?
 

Thực sự từ đầu em không trình bày rõ ràng nên câu trả lời không đúng như ý em muốn. Nếu em nêu ra cụ thể rằng em đang làm quen với ipfilter firewall và em muốn hiểu các rule của nó thì nội dung thảo luận đã khác rồi. Nên rút kinh nghiệm cho việc trình bày lần sau để tránh phí thời gian và bị lạc đề. 

DrDoS viết tắc từ distributed reflection denial of service. Dịch ra tiếng Việt là từ chối dịch vụ (bằng) phát tán ánh xạ.

Câu trên có nghĩa là gì? Nó có nghĩa đây là một dạng tấn công từ chối dịch vụ nhưng dạng này đặc biệt ở chỗ nó không tấn công trực tiếp từ máy của kẻ tấn công mà nó mượn tay những hệ thống khác để tấn công (phát tán). Hơn nữa nó không chỉ đơn thuần tấn công từ nhiều máy con (zombies) mà dùng máy con để tấn công những routers để mượn tay routers tấn công nạn nhân (ánh xạ).

Ví dụ, từ laptop của tôi, tôi điều khiển 10 máy con (10 zombies). Tôi ra lệnh cho các máy con tấn giả mạo IP của nạn nhân nào đó (giả sử như xxx.xxx.xxx.xxx) đồng loạt gởi SYN request đến một loạt routers. Các routers này đều nghĩ rằng nạn nhân có IP là xxx.xxx.xxx.xxx đang muốn SYN với chúng nên chúng trả lời SYN-ACK về xxx.xxx.xxx.xxx ---> dẫn đến tình trạng DDoS. Nạn nhân không hề gởi SYN bao giờ nhưng lại "bị" trả lời dồn dập. Nếu zombies không gởi SYN trực tiếp đến routers nào gần nạn nhân nhất mà gởi đến routers cách vài hops rồi mới đến đích (nạn nhân) thì tạo ra tình trạng reflection (ánh xạ).

Ví dụ 10 con zombies đồng loạt gởi 10 SYN đến 100 routers và 100 routers này gởi SYN-ACK đến nạn nhân, điều này có nghĩa, ngay cùng một lúc có:
10 x 10 x 100 = 10000 SYN-ACK packets dội đến nạn nhân. Các con số trên gia tăng, nạn nhân chết.

Vậy, muốn thực hiện dạng tấn công này, từ các thông tin trên thử suy nghĩ xem kẻ muốn tấn công cần hội đủ các điều kiện nào? (đọc thật kỹ phần màu xanh ở trên, nếu chưa hiểu, đọc kỹ lại. Nếu vẫn chưa hiểu, tìm một quyển sách nói về TCP/IP mà nghiên cứu thật kỹ rồi đọc lại phần màu xanh). 

À... hoá ra em thắc mắc mấy cái ipfilter rule?
 

thierry wrote:

cái USB hok cóa driver kèm theo. Chỉ có cái đĩa tiện phần mềm hỗ trợ thôi. Cắm thử vào 1 số máy khác cũng hok nhận nốt. Máy nhận máy hok. 

Thực ra USB này bị lỗi, bạn thử format xem, nếu không được thì botay
Tôi cũng đã gặp trường hợp này rồi, không có cách giải quyết nào khác 

enn3exlibs wrote:

conmale wrote:

Cái gì khiến cho em có ý tưởng khai triển từ hướng "allow_all" vậy? 

em đang đọc tài liệu về fw, thử so sánh hai hướng triển khai deny_all và allow_all, thắc mắc của em không yêu cầu nhiều kiến thức về fw mà cần nhiều kiến thức về network.


 

Em vẫn không tập trung trả lời câu hỏi của anh. Câu hồi đáp của em ở trên không dính dáng gì đến câu anh hỏi cả.

 

deny và allow là những khái niệm gì mà chỉ cần nhiều kiến thức về network mà không cần nhiều kiến thức về fw? 

enn3exlibs wrote:

....
Mình muốn tìm hiểu dùng policy allow_all thì cần những rule deny gì( mình ví dụ tạo luật hủy các ICMP đi vào để ngăng ping, chặn tấn công làm lụt ICMP, drop ngẫu nhiên các packet trong trường hợp bị DOS ...)


 

Cái gì khiến cho em có ý tưởng khai triển từ hướng "allow_all" vậy? 

Sao bạn lại đi ngược thế kia. Người ta từ Yêu cầu bảo mật mới có thể thiết kế các policy cho hợp lý mà bạn lại muốn từ các policy để tìm hiểu? Hơn nữa, nếu ai dám mạnh miệng trả lời bạn là cần RuleA, RuleB vân vân khi chưa rõ yêu cầu cụ thể của bạn là gì thì bạn cũng đừng nên nghe theo.

Các điều kiện bạn đưa ra: Không NAT, stateful packet filter hoàn toàn không giúp ích gì cho việc thiết kế một bộ policy cho thích hợp. Chỉ có cái default allow all (khoai đoán ý bạn là thế) là có thể ứng dụng thành một rule trong policy bảo mật của bạn mà thôi. Bạn có thể tự hỏi mình vài câu:

1. Bạn có dịch vụ gì?
2. Ai có quyền sử dụng dịch vụ đó.
3. Ai không có quyền sử dụng dịch vụ.
4. Sử dụng thế nào thì là thích hợp, thế nào là không thích hợp.