> Dan Muey wrote:
> > > Dan Muey wrote:
> > > > Howdy,
> > > > 
> > > > I realize that $ENV{'REMOTE_HOST'} and $ENV{'REMOTE_ADDR'} are 
> > > > handled differently and can be spoofed so don't worry I'm not 
> > > > basing any security on them.
> > > 
> > > I'm no security expert, but how can these be spoofed? They don't 
> > > come from the request headers, but are derived from the TCP 
> > > connection itself.
> > 
> > Well I'm not sure, I always thought what you said was true,
> 
> OMG! don't assume that! :~)
> 
> > but you
> > always hear folks saying that so I was trying to avoid the 
> pummeling I 
> > felt would be inevitable.
> 
> :~)
> 
> > 
> > > 
> > > Furthermore, how useful are these anyway? For example, 
> I'm currently 
> > > sitting behind a NAT proxy along with 300 or so other folks, so 
> > > you'll see the same REMOTE_ADDR for any of us who visit 
> your site. 
> > > Or is that what you mean by "spoof"?
> > > 
> > 
> > True, what I was logging was the ip that certain scripts 
> were called 
> > from. I have some websites that use LWP to call a script on 
> my server. 
> > So basically that means that, unless, something is changed on their 
> > server, my server will always see them as coming from the same ip 
> > address. If there are discrepencies I can look into it if 
> it matters.
> > 
> > As much as like to be able to only allow access from certain IP 
> > address I don't do it because everyone rants on and on about $ENV 
> > beinag able to be spoofed so easily.
> 
> Well, it can't be spoofed in the sense of being faked. If I'm 
> connecting from 206.107.121.3, There's no way to convince 
> your server that I'm really connecting from 66.118.101.132, AFAIK.
> 
> However, If I can use an intermediate system as a proxy, I 
> can convince you that I'm coming from a different host than I 
> "actually" am.
> 
> > 
> > So correct me if I'm wrong but if I have a script that runs on a 
> > server that I am the only user on and I am the only person 
> allowed to 
> > put anythign on it then $ENV{'REMOTE_ADDR'} may be a fairly 
> reliable 
> > way to limit access?? (barring my hero Kevin Mitnick and friends ;p)
> 
> No, if by "server" you mean the server on which you are 
> looking at REMOTE_ADDR. REMOTE_ADDR is the client address. 
> You don't want to build any scheme based on the supposed 
> hardness of the client system.
> 
> But because of proxies, you may have a "good guy" and a "bad 
> guy" using the same proxy. So you can't use REMOTE_ADDR alone 
> to distinguish between the two for identification purposes.
> 
> If it matters, you need some way for the client to pass you 
> some credentials with the request that you can validate. You 
> may even want to do this in combination with REMOTE_ADDR, to 
> decrease the risk that the credentials have been compromised 
> and are being used to attempt to gain access from an unexpected host.
> 

They do have to log in via a user name and password passed by LWP.
They will have a script that logs in via LWP so that will narrow it down.

I just wanted to add another layer of detectability if someone happens upon 
their log in info and decides to use it.

> > 
> > 
> > die "You not allowed freako!\n" unless $ENV{'REMOTE_ADDR'} =~ 
> > m/^1\.2\.3\.4$/; die "You gots to be logged in jack!\n" unless 
> > $ENV{'REMOTE_USER'} =~ m/^\w+$/;
> 
> 

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to