2010-09-10 2 views
9

Tôi có một số tính năng bổ sung trên trang web mà nhân viên có thể sử dụng nhưng khách hàng không được phép xem.Có thể giả mạo IP của bạn ... đang kiểm tra địa chỉ IP có an toàn không?

Nhân viên tất cả sẽ thuộc một loạt các miền.

Những gì tôi làm là lấy ip sử dụng như sau:

$user_ip = gethostbyname($_SERVER['REMOTE_ADDR']); 

Sau đó, tôi nhận được một mảng của tất cả các ip cho các lĩnh vực người sử dụng sẽ được sử dụng gethostbyname

Sau đó, tôi kiểm tra xem người dùng thuộc một trong các tên miền như vậy:

in_array($user_ip,$allowedIPS) 

Vì vậy, nếu người dùng thuộc một trong các miền họ thấy các tính năng bổ sung để sử dụng nội bộ. Nếu không, họ chỉ nhìn thấy những gì có nghĩa là cho công chúng.

Câu hỏi của tôi là, điều này có an toàn không? Hoặc ai đó có thể giả mạo IP của họ xuất hiện giống như họ đang ở trên miền của chúng tôi và có quyền truy cập vào các tính năng này?

+0

có vẻ như việc sử dụng gethostbyname() là dư thừa ở đây. '$ user_ip = $ _SERVER ['REMOTE_ADDR'];' là đủ –

+0

@Col. Shrapnel Tôi không nghĩ đó là vấn đề ở đây. – RobertPitt

+0

'$ _SERVER ['REMOTE_ADDR']' IS địa chỉ IP của người dùng và bạn đang sử dụng gethostbyname trên đó, nếu tôi có thể tin vào mắt mình –

Trả lời

8

Không thể giả mạo kết nối TCP qua Internet mở do Three Way Handshake. Tuy nhiên, có thể truy cập tính năng này bằng cách sử dụng CSRF.

PHP kéo $_SERVER['REMOTE_ADDR'] trực tiếp từ ổ cắm TCP của Apache, ở đó không bị ảnh hưởng bởi kẻ tấn công. Và vâng, tôi đã xem mã này.

+0

Vì vậy, nếu tôi hiểu CSRF. Một nhân viên có IP được phép truy cập một trang web khác, nơi ai đó sử dụng CSRF để lừa trình duyệt của nhân viên truy cập trang bằng các tính năng ẩn. Vì vậy, có được quyền truy cập vào các tính năng thông qua IP của nhân viên. Nhưng kẻ tấn công vẫn không thể nhìn thấy các tính năng, đúng không? bởi vì nó là một cuộc tấn công mù. Họ chỉ có thể cố gắng "sử dụng" các tính năng một cách mù quáng. Đúng? –

+1

@ John Isaacks điều này là chính xác. Tuy nhiên "sử dụng csrf để lừa" là từ ngữ xấu. Các cuộc tấn công CSRF là các thẻ '' để tạo ra các yêu cầu GET và '

' tự động thực hiện '.submit()' khi trang hoặc iframe được xem.Tôi vẫn sẽ ngăn chặn CSRF trong trường hợp có một cuộc tấn công nội bộ. Điều này có thể đơn giản như kiểm tra người giới thiệu. – rook

+0

Tuyệt vời, cảm ơn! –

-1

Mọi thứ đều có thể, nhưng nó luôn là vấn đề về chi phí.
Trong hầu hết các trường hợp giả mạo như vậy không đáng giá

+2

shit họ upvote Amber cho câu trả lời tương tự. –

+6

có lẽ vì ngữ pháp của bạn là suck – davr

+0

@davr - không phải đó là teh suk? –

2

Có thể giả mạo IP, nếu không tầm thường.

Tại sao bạn không chỉ đăng nhập để có quyền truy cập vào các tính năng chỉ dành cho nhân viên?

+0

Khi bạn nói "có thể, nếu không tầm thường", bạn có nghĩa là, điều này không ok để lưu trữ thông tin nhạy cảm như tài khoản ngân hàng, nhưng không sao cho thông tin không nhạy cảm như nhà cung cấp sản phẩm? –

+1

Một lý do rất tốt là chi phí hỗ trợ. Có một ứng dụng với các thông tin riêng của nó có thể trở thành một cơn đau khổng lồ trong mông, nhanh chóng. Nếu anh ta có thể gắn vào một LDAP thoát hoặc máy chủ xác thực khác đó là một điều, nếu không, mặc dù nó có thể tạo ra một khối lượng lớn công việc đang diễn ra. Mật khẩu bị mất, thay đổi, nhân viên mới cần phải được thêm vào, chấm dứt nhân viên cần phải được loại bỏ, vv ... Không âm thanh như nhiều, nhưng trong một công ty cỡ vừa hoặc cao hơn nó có thể chắc chắn thêm lên theo thời gian. – Serapth

+0

[a] Nếu đó là một hệ thống mà họ không sử dụng thường xuyên, hoặc họ truy cập từ nhiều máy tính trong ngày, đăng nhập mỗi lần là một nỗi đau [b] anh ta sẽ phải cung cấp đăng ký, đăng nhập, 'quên mật khẩu ', và' quên tên người dùng 'trang. – egrunin

2

Tôi không nghĩ rằng điều này là có thể, bởi vì khi bạn thực hiện yêu cầu đến máy chủ, bạn thực sự yêu cầu ISP của bạn yêu cầu máy chủ.

miễn là bạn xác nhận tất cả các dữ liệu HTTP Meta rằng đạo ISP trên cho bạn, chẳng hạn như X-FORWARDED-FOR và meta proxy bạn sẽ có thể giữ một hệ thống chặt chẽ ..

heres một sơ đồ có thể giúp bạn uderstand ý tôi là gì: alt text

đọc tại đây để biết thêm thông tin.

http://www.astahost.com/info.php/hacker39s-view-easy-spoofing-ip-address_t13807.html

+0

Tôi nghĩ bạn đang bối rối ** định tuyến ** (trong lớp Mạng của ngăn xếp OSI) với ** proxy ** (trong lớp Ứng dụng). Rất ít ISP sử dụng proxy thực sự trong những ngày này. –

8

Câu hỏi của tôi là, đây là an toàn? Hoặc ai đó có thể giả mạo IP của họ xuất hiện giống như họ đang ở trên miền của chúng tôi và có quyền truy cập vào các tính năng này?

Không, trừ khi họ cũng có quyền truy cập vào mạng của một trong các IP được phép hoặc bất kỳ máy nào được phép trong một trong các IP bị xâm phạm và lưu lượng truy cập proxy.

Trong trường hợp của bạn, có vẻ như đủ tốt. Vâng, ngoại trừ những người dùng đặc quyền sẽ không được phép truy cập nội dung từ các IP khác mà không có một số loại VPN.

Lưu ý rằng IP spoofing thường có ý nghĩa khác với ý nghĩa bạn đang sử dụng. Nó có nghĩa là chỉ giả mạo địa chỉ nguồn của một gói tin. Điều này tự nó là vô giá trị bởi vì để truy cập dịch vụ, nó cũng sẽ là cần thiết để nhận được phản hồi từ máy chủ. Ngay cả "IP giả mạo" trong ý nghĩa này là hiếm ngày hôm nay do định tuyến tốt hơn.

+1

Có và không - phản hồi không phải lúc nào cũng cần thiết nếu bạn chỉ muốn thay đổi thứ gì đó (và đã biết yêu cầu thích hợp để gửi để làm như vậy). Nó sẽ ngăn chặn thăm dò, nhưng không nhất thiết phải khai thác. – Amber

+0

@Amber Theo phản hồi, ý tôi là gói SYN/ACK, chứ không phải phản hồi HTTP ... Nó sẽ không đi xa đến vậy. – Artefacto

+1

Trong khi điều này có thể vượt quá phạm vi của câu hỏi, có thể làm cho nó vượt xa, nếu bạn có mục đích độc hại - các số thứ tự TCP có thể dự đoán được, và do đó bạn có thể gửi trước một 'ACK' trả lời đến gói tin bạn biết máy chủ ở đầu kia sẽ gửi. – Amber

2

Nếu bạn định làm điều này, hãy thực hiện với cấu hình apache, không phải bằng mã. Về cơ bản bạn đang phát minh lại chức năng được tích hợp sẵn.

Đối với câu hỏi trực tiếp, như những người khác đã nói, giả mạo IP là có thể nếu không tầm thường. Cũng hy vọng bạn không có bất kỳ điểm truy cập không an toàn nào.

CHỈNH SỬA: Apache access control hướng dẫn. Đây là giả định của tôi bạn đang sử dụng Apache do sử dụng PHP, nếu bạn đang thực sự sử dụng IIS, nó vẫn là một cấu hình điều khiển thiết lập nhưng rõ ràng là khác nhau trong thực hiện của nó.

+0

Cảm ơn, phiên bản apache chỉ hoạt động để cho phép toàn bộ trang phải không? Tôi đang cố gắng cho phép các tính năng cụ thể trên các trang. –

+0

Có. Tuy nhiên, từ một phương pháp hay nhất, bạn gần như được đảm bảo để được phục vụ tốt nhất có trang web an toàn và không được bảo mật thay vì cách tiếp cận kết hợp và kết hợp. Nếu không, tôi hứa với bạn, với bất kỳ sự phức tạp nào đối với hệ thống của bạn, bạn sẽ rò rỉ thông tin bí mật tại một số thời điểm, hoặc tạo ra một cơn ác mộng bảo trì trong tương lai. – Serapth

0

Tôi đã bỏ qua ROOK trên trang này. Bạn không thể giả mạo một kết nối TCP và vẫn truy cập trang web của bạn từ cùng một máy làm giả mạo. Tại sao? Vì phản hồi mà máy chủ web của bạn sẽ thực hiện (ban đầu) sẽ là IP giả mạo trong nỗ lực thiết lập kết nối socket (bắt tay TCP 3 chiều). Có thể hiểu rằng nếu bạn có hai máy tính (A và B) tại hai địa chỉ IP công cộng khác nhau và bạn sử dụng một trong các máy tính (A) để giả mạo hoặc gửi gói đến máy chủ web của bạn bằng địa chỉ IP của B sao cho khi máy chủ web của bạn trả lời nó gửi gói tin đến B.

Nếu địa chỉ IP được sử dụng trong cuộc gọi giả mạo nằm trong mạng con của bạn thì máy trạm bên trong sẽ nhận gói TCP ACK cho gói TCP SYN không được khởi tạo và từ chối chúng hoặc bỏ qua chúng. Tôi không biết về bất kỳ việc thực hiện ngăn xếp TCP/IP nào sẽ cố gắng hoàn thành việc bắt tay 3 chiều đối với các gói chỉ ACK; nó phá vỡ giao thức chuẩn.

Giả mạo là kỹ thuật cho lũ UDP, nơi kẻ tấn công tấn công DoS (Từ chối dịch vụ) bằng địa chỉ IP giả mạo để cố gắng ẩn tuyến đường của họ.

Hy vọng điều này sẽ hữu ích.

0

$_SERVER['REMOTE_ADDR'] được cung cấp bởi máy chủ web của bạn và không thể giả mạo trực tiếp. Cách duy nhất xung quanh nó mà tôi có thể thấy là proxy kết nối thông qua một trong những IP được cho phép.

0

Khi chúng tôi phải đối mặt với một câu hỏi tương tự, chúng tôi đi đến kết luận rằng nếu người dùng truy cập chúng tôi qua http, chúng tôi hoàn toàn không thể dựa vào địa chỉ IP của họ, vì họ có thể đang sử dụng proxy. Nhưng https luôn là kết nối trực tiếp; nó không cho phép proxy, vì vậy chúng tôi có thể chắc chắn rằng địa chỉ IP mà chúng tôi thấy là chính xác. Vì vậy, chúng tôi đã khóa người dùng của chúng tôi dựa trên địa chỉ IP PLUS họ phải truy cập trang web qua https (và đăng nhập vào tài khoản của họ, tất nhiên).

Trường hợp của bạn có vẻ khác một chút so với của chúng tôi, nhưng tôi muốn nói ở trên cũng hữu ích cho bạn.

Thậm chí nếu bạn không đi theo con đường chính xác đó, bạn cần phải biết về proxy. Một proxy về mặt lý thuyết có thể cho phép bất kỳ số lượng người dùng khác nhau truy cập trang web của bạn từ một địa chỉ IP duy nhất, vì vậy nếu bạn quản lý IP của proxy vào danh sách các địa chỉ được cho phép thì bạn sẽ mở một lỗ hổng bảo mật, vì vậy bạn cần để đảm bảo rằng bất kỳ địa chỉ IP nào bạn thêm vào danh sách đều hợp pháp (đây là nơi https có thể trợ giúp).

Ngoài ra, nếu người dùng của bạn đến từ máy tính ở nhà, hãy lưu ý rằng địa chỉ IP của họ có thể thay đổi theo thời gian. Hầu hết các ISP sẽ phát hành khách hàng của họ với các IP động có thể được gán lại, nghĩa là mỗi khi bạn kết nối với internet, bạn sẽ có cơ hội nhận được một địa chỉ IP khác. Nếu đây là trường hợp, không có giả mạo xảy ra nhưng tuy nhiên bạn sẽ không thể xác định người dùng một cách đáng tin cậy theo địa chỉ IP của họ.