Xác thực (ident)

Một phần của tài liệu tìm hiểu và cài đặt hệ thống firewall kết hợp với proxy để bảo vệ hệ thống mạng bên trong (Trang 84 - 127)

ACL loại này sẽ match với tên người dùng mà giao thức ident sẽ truy vấn được. Đây là một giao thức đơn giản được chi tiết tại RFC 1413 và nó làm việc như sau:

1. Client thực hiện kết nối đến Squid

2. Squid kết nối đến cổng xác thực (113) trên máy client.

3. Squid ghi vào một dòng với hai giá trị cổng là cổng lắng nghe của Squid và cổng nguồn thực hiện kết nối của client.

4. Server ident bên phía client sẽ gửi lại dữ liệu tên người dùng dựa vào tiến trình đã mở kết nối đến Squid.

5. Squid sẽ lưu lại tên người dùng và dùng nó để kiểm tra match với các ACL.

Khi Squid gặp một ACL loại ident này với một yêu cầu cụ thể, yêu cầu đó sẽ hoãn lại cho đến khi tiến trình dò tìm thông tin xác thực hoàn thành. Vì thế sử dụng ACL ident có thể tăng đáng kể độ trể đối với các yêu cầu của người dùng.

3.4.6. Số lƣơng kết nối tối đa (maxconn)

ACL maxconn muốn nói đến số lượng kết nối tối đa đồng thời từ một địa chỉ IP. ACL này hữu dụng khi ngăn cấm một người dùng nào đó sử dụng quá nhiều tài nguyên. ACL maxconn chỉ match với một yêu cầu khi yêu cầu đó vượt quá số lượng mà ta quy định. Vì thế ta chỉ sư dụng ACL maxconn trong luật deny. Ví dụ:

Trang 84

ACL maxconn dựa vào một cơ sở dữ liệu được quản lý bởi Squid. Cơ sơ dữ liệu này cho phép lưu trữ thong tin của từng địa chỉ IP người dùng. Nếu ta có quá nhiều trạm trong mạng, cơ sở dữ liệu này có thể sẽ chiếm dụng nhiều tài nguyên. Ta có thể loại bỏ cơ sơ dữ liệu này và đồng nghĩa với việc ACL maxconn sẽ không làm việc được nữa.

3.4.7. Trình duyệt (browser)

Hầu hết các HTTP Request đều có kèm một thông tin header User-Agent. Giá trị này tùy thuộc vào trình duyệt mà ta đang sử dụng. Ví dụ, đối với trình duyệt Firefox trên hệ điều hành Ubuntu là Mozilla/4.51 [en] (X11; I; Linux 2.2.5-15 i686).

ACL browser cũng sử dụng biểu thức chính quy để match với giá trị trong header User-Agent.

3.4.8. Nội dung trong request (req_mine_type)

ACL req_mine_type muốn nói đến header Content-Type trong HTTP Request bên phía client gửi đi. Header Content-type thường xuất hiện trong những yêu cầu có body. Phương thức POST và PUT thường có header này nhưng phương thức GET lại không. Ta thường dùng ACL req_mine_type để dò tìm những loại file gửi đi qua HTTP Request.

ACL req_mine_type sử dụng biểu thức chính quy để match. Chẳng hạn để bắt được loại file âm thanh (audio), ta có thể viết một ACL như sau.

3.4.9. Nội dung trong response (rep_mine_type)

Tương tự như ACL req_mine_type, ACL rep_mine_type cũng sử dụng header Content-Type nhưng là trong HTTP Response từ bên phía server gửi trả lại.

acl AuidoFileUploads req_mime_type -i ^audio/ acl OverConnLimit maxconn 4

Trang 85

3.4.10.External ACL

External ACL là một tính năng mới kể từ Squid 2.5. Yêu cầu sẽ được kiểm tra bởi một tiến trình khác và gửi trả lại Squid thông tin là có match hay không. External_acl_type dùng để định nghĩa một loại ACL mới và cú pháp như sau:

Squid hỗ trợ một số tùy chọn (options) sau:

 ttl=n là lượng thời gian tính bằng giây để cahce một kết quả đã match trước đó. Mặc định là 3600 giây.

 negative_ttl=n tương tự như ttl nhưng là để cache một kết quả không match.

 concurrency=n chỉ số lượng tiến trình tạo ra. Mặc định là 5.

 format là một hoặc nhiều từ khóa bắt đầu với ký tự %. Squid có thể hỗ trợ những loại định dạng sau:

 %LOGIN. Tên đăng nhâp.

 %IDENT. Tên đăng nhập thông qua giao thức ident.

 %SRC. Địa chỉ IP của client.

 %DST. Địa chỉ của server nguồn.

 %PROTO. Giao thức sử dụng.

 %PORT. Cổng cần kết nối.

 %METHOD. Phương thức sử dụng.

 %{Header}. Giá trị một header trong HTTP request, ví dụ %{User- Agent} sẽ yêu cầu Squid gửi một chuỗi như "Mozilla/4.0 (compatible; MSIE 6.0; Win32)" đến tiến trình thực hiện kiểm tra.

 %{Hdr:member}. Chọn ra những mục trong danh sách dựa trên HTTP headers, ví dụ ta có một HTTP header: X-Some-Header: foo=xyzzy, bar=plugh, foo=zoinks và định dạng %{X-Some-

Trang 86

Header:foo} sẽ yêu cầu Squid gửi chuỗi sau đến tiến trình bên ngoài: foo=xyzzy, foo=zoinks

 %{Hdr:;member}. Tương tự như %{Hdr:member}, nhưng có thể liệt kê nhiều thành phần member.

Đôi khi danh sách giá trị của một ACL có thể rất dài và để liệt kê hết trong một ACL trong file squid.conf trở nên rườm rà. Thay vì thế ta có thể đưa những giá trị đó vào một file bên ngoài và Squid có thể kèm file đó vào khi đọc file cấu hình squid.conf khi gặp ACL dạng acl name "filename".

Squid sử dụng phép toán OR khi kiểm tra một ACL có match lệ hay không. Một ACL có thể có nhiều giá trị và bất kỳ một giá trị nào match với yêu cầu thì ACL đó được xem là match. Ví dụ ta có một ACL acl Marketing ident Tom, Lisa, Bob, Bart. Nếu một yêu cầu được gửi từ một người trong danh sách thì ACL này sẽ được match.

3.4.11.Luật kiểm soát truy cập

ACL Element là bước đầu trong việc xây dựng hệ thống kiểm soát truy cập. Bước tiếp theo là xây dựng hệ thống luật kiểm soát truy cập. Squid cung cấp rất nhiều loại danh sách truy cập.

 http_access là loại danh sach truy cập quan trọng nhất, nó quyết định yêu cầu nào được cho phép hay bị từ chối.

 http_reply_access tương tự như http_access nhưng khác ở chổ Squid kiểm tra trả lời từ phía server thay vì yêu cầu ở phía client.

 icp_access dùng để cho phép hoặc ngăn chặn truy cập từ những server Squid khác.

 no_cache yêu cầu Squid không được lưu trữ thông tin trả về.

 miss_access quyết định việc cách xử lý đối với những cache miss. Danh sách truy cập này hữu dụng khi ta có nhiều server Squid.

 redirector_access quyết định những yêu cầu nào được gửi đến tiến trình chuyển hướng.

Trang 87

 ident_lookup_access cho phép ta kiểm soát được việt sử dụng giao thức ident đối với từng yêu cầu cụ thể.

 always_direct. Bình thường Squid luôn thử gửi những cache miss đến server cache cấp cha, tuy nhiên danh sách truy cập này làm Squid luôn gửi yêu cầu đến server nguồn.

 never_direct ngược với always_direct, danh sách truy cập này làm Squid gửi những yêu cầu cache_miss đến những proxy server khác.

 cache_peer_access điều khiển cách gửi HTTP requests và truy vấn ICP/HTCP đến những server cache khác.

 reply_body_max_size giới hạn kích thước tối đa của phần body trong HTTP Response.

 delay_access điều khiển độ trễ cho request.

 tcp_outgoing_address buộc Squid sử dụng một địa chỉ IP cục bộ khi kết nối đến server.

 tcp_outgoing_tos gán một số giá trị TOS/Diffserv trong kết nối đến server hoặc server cache khác.

 header_access giúp Squid điều khiển loại bỏ các HTTP header bên phía client.

 header_replace giống như header_access nhưng thay vì chỉ loại bỏ chỉ thị này có thể giúp ta thay thế HTTP header

3.4.12.Phƣơng thức match luật trong Squid

Như đã nói ở trên, Squid sử dụng phép logic OR khi tìm kiếm một ACL Element và bất kỳ giá trị nào trong một ACL đều có thể dẫn đến match với ACL đó. Ngược lại với ACL Element, Squid sử dụng phép logic AND khi kiểm tra một danh sách truy cập. Cú pháp cơ bản một luật danh sách truy cập như sau.

Trang 88

Để luật này có thể được match, một yêu cầu cần phải match với tất cả ACL1, ACL2, và ACL3. Nếu một trong những ACL đó không match, Squid sẽ ngừng tìm kiếm tại luật này mà chuyển sang luật tiếp theo. Trong mỗi một luật ta có thể tối ưu quá trình tìm kiếm bằng các đặt các ACL Element khó match nhất lên trước. Ta xét ví dụ sau:

Luật trên không được hiệu quả vì ACL A thường match nhiều hơn ACL B. Sẽ tốt hơn nếu ta đảo ngược vị trí của hai ACL này, và trong hầu hết các trường match không match Squid chỉ cần kiểm tra một ACL thay vì phải hai ACL.

Một lỗi mà người dùng thường gặp là viết một luật sẽ không bao giờ match được, chẳng hạn:

Luật này sẽ không bao giờ được match vì một địa chỉ IP nguồn không thể cùng lúc bằng 1.2.3.4 và 5.6.7.8.

Khi Squid tìm được một luật match, quá trình tìm kiếm sẽ kết thúc. Nếu không tồn tại một luật nào match, mặc định Squid sẽ lấy kết quả ngược với kết luật cuối cùng mà Squid kiểm tra. Giả sử ta có một cấu hình đơn giản như sau:

Giả sử người dùng Mary gửi một yêu cầu, cô ấy sẽ bị chặn. Luật cuối cùng là một luật cho phép và nó không match với tên tên người dùng là Mary. Chính vì vậy, lựa chọn mặc định là ngược với cho phép là từ chối. Tương tự, nếu luật cuối cùng là một luật cấm, thì lựa chọn mặc định sẽ là cho phép. Để rõ

acl Bob ident bob http_access allow Bob acl A src 1.2.3.4 acl B src 5.6.7.8 http_access allow A B acl A method http acl B port 8080 http_access deny A B

Trang 89

ràng, ta nên luôn luôn đưa vào cuối danh sách luật một luật cho phép hoặc từ chối tất cả yêu cầu.

3.4.13.Một số tình huống sử dụng Squid

Hầu hết những cấu hình Squid thường giới hạn truy cập dựa vào địa chỉ IP của người dùng. Đó là một trong những cách tốt nhất để bảo vệ hệ thống khỏi tấn công. Cách dể nhất là viết một ACL chỉ cho phép những yêu cầu từ mạng bên trong và từ chối tất cả.

Ta có thể không cho một số địa chỉ bên trong mạng sử dụng Squid bằng cách đưa luật http_access deny lên trước luật cho phép tất cả mọi trạm trong mạng.

Để ngăn chặn một danh sách các trang web cấm ta liệt kê tất cả những trang web đó một file là blocksite sau đó dùng loại ACL Element url_regex

để tạo một ACL.

Đôi khi quản trị viên muốn chỉ cho phép người dùng truy cập tại một thời điểm nào đó. Với yêu cầu này ta nên sử dụng ACL Element time. Ngoài ra, việc ngăn chặn nên áp dụng cho tất cả người dùng trừ những người dùng đặc biệt. Nếu ta muốn cho phép những người dùng nào đó có quyền ưu tiên hơn ta có thể kiểm tra người dùng đó bằng ACL Element proxy_auth. Ta có thể làm như sau:

acl blocksite url_regex "/usr/local/squid/etc/blocksite" http_access deny blocksite

acl All src 0/0

acl MyNetwork src 10.10.10.0/24

http_access allow MyNetwork http_access deny All

Trang 90

Với cách ngăn chặn bằng dstdomain có thể ngăn chặn được nhiều yêu cầu gửi đến những tên miền này. Tuy nhiên, với những người dùng có hiểu biết về công nghệ thông tin có có thể vượt qua được luật cấm này bằng cách dùng địa chỉ IP thay vì tên miền khi gửi yêu cầu. Nếu ta muốn ngăn chặn tất cả những loại yêu cầu kiểu như vậy ta nên sử dụng ACL Element dstdom_regex như sau:

Cache một đối tượng trả về từ server nguồn là nhiệm vụ chính của Squid, nhưng đôi khi ta lại cần cấu hình để Squid không cache những đối tượng tra về với lý do là server đó ở gần hay nói đúng hơn là trong mạng cục bộ. Như vậy, Squid sẽ không cần phải lưu giữ cache, điều này sẽ làm cho Squid không phải tốn bộ nhớ và để lưu trữ cũng như thời gian tìm kiếm cache để trả về cho client.

3.5. Những vấn đề cơ bản về đĩa cache

3.5.1. Chỉ thị cache_dir

Đây là một trong những chỉ thị quan trong nhất trong file cấu hình squid.conf. Chỉ thị này chỉ cho Squid cách và nơi để lưu những đối tượng cache được vào đĩa. Cú pháp cơ bản như sau:

acl LocalServers dst 10.10.10.0/24 no_cache deny LocalServers

acl IPForHostname \

dstdom_regex ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ http_access deny IPForHostname

auth_param basic program /usr/local/squid/libexec/ncsa_auth /usr/local/squid/etc/passwd

acl Authenticated proxy_auth REQUIRED acl Admins proxy_auth Pat Jean Chris

acl blocksite dstdomain "/usr/local/squid/etc/blocksite" acl All src 0/0

http_access allow Admins http_access deny blocksite http_access allow Authenticated http_access deny All

Trang 91

Trong đó scheme là chỉ ra loại phương thức lưu trữ, mặc định là ufs. Tùy vào hệ thống tập tin của hệ điều hành chạy Squid mà ta có thể lựa chọn một trong những phương thức lưu trữ sau đây: ufs, aufs, diskd, coss, và cuối cùng là null.

Tiếp đến directory chỉ ra thư mục sẽ lưu các đối tượng cache được. Thông thường mỗi một chỉ thị cache_dir sẽ tương ứng với một đĩa hay một partition. Ta cũng nên chỉ sử dụng một thu mục chứa cache trên một đĩa cứng.

Size là tham số thứ ba của chỉ thị cache_dir chỉ ra kích thước của bộ nhớ cache. Ta chỉ nên sử dụng 90% kích thước của bộ nhớ còn trống thay vì ta phải để dành một lượng bộ nhớ để lưu trữ những thông tin khác, chẳng hạn các file tạm thời hay swap.state log.

L1 và L2 là hai tham số được sử dụng cho loại phương thức lưu trữ ufs, aufs, và diskd. Squid sẽ tạo hai cấp thư mục con bên trong thư mục chứa cache. Tham số L1 và L2 chỉ ra số lượng thư mục con ở cấp một và cấp hai, mặc định là 16 và 256.

Trang 92

Hình 3.1 Cấu trúc thư mục cahce theo lược đồ ufs

3.5.2. Chỉ thị cache_swap_low và cache_swap_high

Hai chỉ thị này góp phần điều khiển sự thay thế đối tượng lưu trong đĩa. Giá trị của hai chỉ thị này là ngưỡng phần trăm sẽ thực hiện thay thế đối tượng khi mà tổng kích thước của tất cả đối tượng trong cache so với kích thước tối đa của thư mục cache đạt đến ngưỡng. Mặc định cache_swap_low có giá trị là 90 và cache_swap_high là 95.

Nếu tổng dung lượng đã sử dụng dưới cache_swap_low thì Squid sẽ không loại bỏ đối tượng nào. Khi dung lượng thư mục cache đã lớn hơn giá trị này thì Squid sẽ bắt đầu loại bỏ đối tượng.

3.5.3. Chỉ thị minimum_object_size và maximum_object_size

Ta có thể điều khiển cả kích thước tối thiểu cũng như tối đa của đối tượng cache. Những đối tượng lớn hơn maximun_object_size hay nhỏ hơn minimun_object_size sẽ không được lưu vào thư mục cache, tuy nhiên những đối tượng đó vẫn có thể được lưu trong RAM.

3.5.4. Chỉ thị store_dir_select_algorithm

Khi Squid cần lưu trữ một đối tượng vào đĩa, Squid gọi một hàm để chọn ra một trong những thư mục để lưu đối tượng này. Nếu vì một vài lý do mà hàm open không thể gọi được, đối tượng mới này sẽ không được lưu.

Squid có hai thuật toán lựa chọn thư mục lưu đối tượng mới là least-load và round-robin. Least-load là thuật toán lựa chọn thư mục cache có ít đối tượng hay dung lượng được lưu bên trong nhất. Round-robin là thuật toán luôn luôn chọn thư mục tiếp theo trong danh sach để lưu nếu lượng lưu trữ vẫn còn nhở hơn 100%.

3.5.5. Chỉ thị cache_replacement_policy

Chỉ thị này điều khiển chính sách thay thế đối tượng trong thư mục cache. Chính sách điều khiển những đối tượng nào sẽ bị thay thế khi Squid cần lưu

Trang 93

trữ một đối tượng mới mà không còn chỗ trống. Squid hỗ trợ những chính sách sau:

 LRU (least recently used) là chính sách mặc định trong Squid. Chính sách này chọn ra đối tượng ít được sử dụng nhất để loại bỏ.

 GDSF (greedy dual-size frequency)

 LFUDA (least frequency used with dynamic aging)

Chỉ thị này được sử dụng một cách đặc biệt không giống như các chỉ thị khác trong squid.conf. Vị trí của chỉ thị này rất quan trọng. Ta có thể thay đổi chính sách thay thế này cho từng cache_dir bằng cách gán giá trị cho chính sách này khác đi trước khi tạo một cache_dir mới. Chẳng hạn:

Như vậy, hai cache_dir đầu sử dụng chính sách thay thế LRU còn hai cache_dir sau lại sử dụng chính sách thay thế GDSF. Tuy nhiên kết quả này có thể hiển thị không đúng khi sử dụng trình quản lý cachemgr.

3.5.6. Chỉ thị refresh_pattern

Chỉ thị này không trực tiếp điều khiển cache. Nó chỉ giúp Squid quyết định khi nào thì một yêu cầu gửi đến được xem là cache hit hay là cache miss. Nếu ta quá rộng rãi trong vấn đề này có thể sẽ tăng tỉ lệ cache hit nhưng đồng thời

Một phần của tài liệu tìm hiểu và cài đặt hệ thống firewall kết hợp với proxy để bảo vệ hệ thống mạng bên trong (Trang 84 - 127)

Tải bản đầy đủ (PDF)

(127 trang)