是否有可能欺骗您的 IP...测试 IP 地址安全吗?

发布于 2024-09-18 19:41:05 字数 417 浏览 5 评论 0原文

我在网站上有一些额外的功能,员工可以使用,但不允许客户看到。

员工都将分布在一系列域中。

我所做的就是像这样获取用户 ip:

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

然后我使用 gethostbyname 获取用户将位于的域的所有 ip 的数组

然后我检查用户是否位于其中一个域中so:

in_array($user_ip,$allowedIPS)

因此,如果用户位于其中一个域,他们会看到供内部使用的附加功能。否则他们只会看到对公众意味着什么。

我的问题是,这安全吗?或者有人可能会欺骗他们的 IP,让他们看起来像是在我们的域中并获得对这些功能的访问权限?

I have some extra features on a site that employees can use but customers are not allowed to see.

The employees are all going to be on a series of domains.

What I do is get the user ip like so:

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

Then I get an array of all the ips for the domains the users will be on using gethostbyname

Then I check if the user is on one of the domains like so:

in_array($user_ip,$allowedIPS)

So if the user is on one of the domains they see additional features for internal use. Otherwise they just see what is meant for the general public.

My questions is, is this secure? Or could someone potentially spoof their IP to appear like they are on our domain and gain access to these features?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(10

英雄似剑 2024-09-25 19:41:06

我的问题是,这安全吗?或者有人可能会欺骗他们的 IP,让他们看起来像是在我们的域中并获得对这些功能的访问权限?

否,除非他们还可以访问允许的 IP 之一的网络,或者其中一个 IP 下的任何允许的计算机受到威胁并代理流量。

在你的场景中,这似乎已经足够好了。好吧,除非特权用户在没有某种 VPN 的情况下将不被允许访问其他 IP 的内容。

请注意,IP 欺骗通常与您所使用的含义不同。这意味着仅伪造数据包的源地址。这本身是没有价值的,因为要访问服务,还需要接收来自服务器的响应。由于更好的路由,即使是这种意义上的“IP 欺骗”如今也很少见。

My questions is, is this secure? Or could someone potentially spoof their IP to appear like they are on our domain and gain access to these features?

No, unless they also have access to the networks of one of the allowed IPs, or any of the allowed machines under one of the IPs is compromised and proxies traffic.

In your scenario, it seems good enough. Well, except the privileged users will not be allowed to access the content from other IPs without some kind of VPN.

Note that IP spoofing generally has a different meaning than the one you're using. It means only forge the source address of a packet. This by itself is worthless because to access the service, it would also be necessary to receive the response from the server. Even "IP spoofing" in this sense is rare today due to better routing.

心舞飞扬 2024-09-25 19:41:06

由于三路,不可能通过开放互联网欺骗 TCP 连接握手。但是,也许可以使用 CSRF 访问此功能。

PHP 直接从 Apache 的 TCP 套接字提取 $_SERVER['REMOTE_ADDR'],因此它不会受到攻击者的影响。是的,我已经看过这段代码。

It is impossible to spoof a TCP connection over the open internet due to the Three Way Handshake. However, it maybe possible to access this feature using CSRF.

PHP pulls $_SERVER['REMOTE_ADDR'] directly from Apache's TCP socket, there for it cannot be influenced by an attacker. And yes, i have looked at this code.

左耳近心 2024-09-25 19:41:06

IP 欺骗是有可能发生的(如果不是微不足道的话)。

为什么不直接让员工登录来访问仅限员工使用的功能呢?

IP spoofing is possible, if non-trivial.

Why don't you just have your employees log in to get access to employee-only features?

江南月 2024-09-25 19:41:06

如果您打算这样做,请使用 apache 配置来完成,而不是使用代码。您基本上是在重新发明内置功能。

至于直接的问题,正如其他人所说,如果不简单的话,欺骗 IP 是可能的。还希望您没有任何不安全的无线接入点。

编辑:Apache 访问控制说明。这是我假设您由于 PHP 使用而使用 Apache,如果您实际上使用 IIS,它仍然是配置驱动的设置,但其执行方式明显不同。

If you are going to do this, do it with apache config, not with code. You are basically re-inventing functionality the is built-in.

As to the direct question, as others have said, spoofing an IP is possible if non-trivial. Also hope you don't have any unsecure access wireless points.

EDIT: Apache access control instructions. This is my assuming you are using Apache due to PHP usage, if you are actually using IIS, its still a config driven setting but obviously different in its execution.

2024-09-25 19:41:06

我认为这是不可能的,因为当您向服务器发出请求时,您实际上是在请求 ISP 请求服务器。

只要您验证 ISP 转发给您的所有 HTTP 元数据,例如 X-FORWARDED-FOR 和代理元,您就应该能够保持严密的系统。

这是一个图表,可以帮助你理解我的意思:
alt text

阅读此处了解更多信息。

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

I don't think this is possible, because when your making a request to a server, your actually requesting your ISP to request the server.

as long as you validate all the HTTP Meta data that the ISP Forwards on to you, such as X-FORWARDED-FOR and proxy meta you should be able to keep a tight system..

heres a diagram that may help you uderstand what i mean:
alt text

read here for more info.

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

意中人 2024-09-25 19:41:06

我对 ROOK 投了赞成票。您无法欺骗 TCP 连接并仍然从进行欺骗的同一台计算机访问您的站点。为什么?因为您的 Web 服务器(最初)做出的响应将是对欺骗的 IP 进行尝试建立套接字连接(TCP 3 路握手)。

可以想象,如果您有两台计算机(A 和 B),具有两个不同的公共 IP 地址,并且您使用其中一台计算机 (A) 使用 B 的 IP 地址欺骗或发送数据包到您的 Web 服务器,这样当您的 Web 服务器回复时 如果欺骗呼叫中使用的 IP 地址位于子网

内部,则内部工作站将收到未启动的 TCP SYN 数据包的 TCP ACK 数据包,并拒绝或忽略它们。我不知道有任何 TCP/IP 堆栈实现会尝试针对仅 ACK 数据包完成 3 路握手;它破坏了标准协议。

欺骗是一种 UDP 洪泛技术,攻击者使用虚假 IP 地址进行 DoS(拒绝服务)攻击,试图隐藏其踪迹。

希望这有帮助。

I upvoted ROOK on this one. You cannot spoof a TCP connection and still access your site from the same machine doing the spoofing. Why? Because the response your web server would make (initially) would be to the spoofed IP in an attempt to establish a socket connection (TCP 3-way handshake).

It is conceivable that if you have two computers (A and B) at two different public IP addresses and you use one of the computers (A) to spoof or send packets to your web server using B's IP address such that when your web server replies it sends packets to B.

If the IP addresses used in the spoofed call are internal on your subnet, then internal workstations would receive TCP ACK packets for uninitiated TCP SYN packets and reject them or ignore them. I'm not aware of any TCP/IP stack implementation that would try to complete a 3-way handshake against ACK only packets; it breaks standard protocol.

Spoofing is technique for UDP flooding where an attacker does a DoS (Denial Of Service) attack using a phony IP address to attempt to hide their tracks.

Hope this helps.

如果没有你 2024-09-25 19:41:06

$_SERVER['REMOTE_ADDR'] 由您的网络服务器提供,无法直接欺骗它。我能看到的唯一解决方法是通过允许的 IP 之一代理连接。

$_SERVER['REMOTE_ADDR'] is provided by your web server and it's not possible to spoof it directly. The only way around it that I can see is proxying the connection via one of the allowed IPs.

风情万种。 2024-09-25 19:41:06

当我们遇到类似的问题时,我们得出的结论是,如果用户通过 http 访问我们,我们不能绝对依赖他们的 IP 地址,因为他们可能使用代理。但https始终是直接连接;它不允许代理,因此我们可以确定我们看到的 IP 地址是正确的。因此,我们根据 IP 地址锁定了用户,而且他们必须通过 https 访问该网站(当然还要登录他们的帐户)。

您的情况听起来与我们的情况有些不同,但我想说上述内容对您也应该有用。

即使您不遵循该确切路径,您也需要了解代理。理论上,代理可以允许任意数量的不同用户从单个 IP 地址访问您的网站,因此,如果您设法将代理的 IP 放入允许的地址列表中,那么您就会打开一个安全漏洞,因此您需要确保您添加到列表中的任何 IP 地址都是合法的(这是 https 可以提供帮助的地方)。

此外,如果您的用户来自家庭 PC,请注意他们的 IP 地址可能会随着时间的推移而发生变化。大多数 ISP 都会向客户提供可以重新分配的动态 IP,这意味着每次您连接到互联网时,您都有可能获得不同的 IP 地址。如果是这种情况,则不会发生欺骗,但您仍无法通过 IP 地址可靠地识别用户。

When we were confronted by a similar question, we came to the conclusion that if the user was accessing us via http, we couldn't absolutely rely on their IP address, because they could be using a proxy. But https is always a direct connection; it doesn't allow proxies, so we could be sure that the IP address we were seeing was correct. Therefore, we locked our users down based on IP address PLUS they had to access the site via https (and log in to their account, of course).

Your case sounds a little bit different from ours, but I'd say the above should be useful for you as well.

Even if you don't follow that exact path, you do need to be aware of proxies. A proxy could theoretically allow any number of different users to access your site from a single IP address, so if you somehow managed to get a proxy's IP into your list of allowed addresses then you'd be opening up a security hole, so you need to be sure that any IP address you add to the list is legitimate (this is where https can help).

Also, if your users are coming from their home PCs, be aware that their IP address could change over time. Most ISPs will issue their customers with dynamic IPs which can be re-assigned, meaning that each time you connect to the internet, there's a chance you'll get a different IP address. If this is the case, there's no spoofing going on but nevertheless you won't be able to reliably identify a user by their IP address.

柒七 2024-09-25 19:41:06

正如之前所讨论的,通过 Internet 进行 TCP 中的 IP 欺骗是不可能的,但还存在其他攻击 Web 应用程序的方法。

请注意,许多 Web 实现(无论是否使用 PHP)都容易受到 X-Forwarded-For 注入的攻击。 X-Forwarded-For 是一个 HTTP 标头,用于指定请求通过代理时的原始 IP 地址。 Apache2 中没有(可能的)验证,并且在某些配置中,这是传递给 PHP 的 REMOTE_ADDR 的 IP 地址。所以,是的,IP 欺骗是可以通过这种方式实现的。

假设攻击者设置了值为 127.0.0.1 的请求标头 X-Forwarded-For。如果 HTTP 服务器上的配置允许这样做,则 127.0.0.1 将传递到 PHP-FPM 的 REMOTE_ADDR,而不是实际攻击者的 IP。当我浏览互联网时,我总是将此标头添加到我的请求中以测试网页的安全性。当我将 IP 设置为 localhost 时,其中许多会显示额外的管理工具栏。即使 stackoverflow 在 beta 阶段也出现了这个错误,而且今天的一些主要软件默认情况下仍然“容易”受到此错误的影响。

While as it is discussed before, IP spoofing in TCP over the Internet is impossible, other methods for attacking webapps exist.

Please note that many web implementations (either using PHP or not) are vulnerable to X-Forwarded-For injection. X-Forwarded-For is an HTTP header that specifies the original IP address when a request passes trough a proxy. There is no validation (possible) in Apache2 and on some configurations this is the IP address that is passed to PHP's REMOTE_ADDR. So yes, IP spoofing is possible this way.

Suppose an attacker sets a request header X-Forwarded-For with a value of 127.0.0.1. If the configuration on the HTTP server allows this, 127.0.0.1 will be passed to PHP-FPM's REMOTE_ADDR, not the actual attacker's IP. When I browse the Internet, I always add this header to my requests to test security of webpages. Many of them show additional admin toolbars when I set my IP to localhost. Even stackoverflow had this error when it was in beta stage and some major software today is still "vulnerable" to this by default.

落花随流水 2024-09-25 19:41:06

一切皆有可能,但始终是成本问题。
在大多数情况下,这样的欺骗是不值得的

Everything is possible, but it's always matter of cost.
In most of cases such a spoofing doesn't worth

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文