[users@httpd]
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
[users@httpd]
by Stephen Love
::
Rate this Message:
I have set up a routine in my server that logs all incoming IP addresses and parses for duplicates in the same list. HOWEVER...a person posting almost NEVER has the same address. I believe I am not using the actual IP Address at all. What I WANT is the actual SERIAL NUMBER (If you could call it that!) of the HARDWARE (Network Adapter) actually sending the message, or its REPLY TO address... the address it is COMMUNICATING FROM in order to actually send the message. I am SURE if it is to establish a 2-way link to send and confirm the message, the receiving end HAS that info, buried deep within what it receives. HOW can I get that, so that the route steps inbetween do not matter?
See us online at http://www.LOVEnCompany.com. ____________________________________________________________ Weight Loss Program Best Weight Loss Program - Click Here! |
|
|
Re: [users@httpd]
by Eric Covener
::
Rate this Message:
On Tue, Nov 10, 2009 at 8:19 AM, Stephen Love <stephenlove@...> wrote:
> I have set up a routine in my server that logs all incoming IP addresses and > parses for duplicates in the same list. HOWEVER...a person posting almost > NEVER has the same address. I believe I am not using the actual IP Address > at all. What I WANT is the actual SERIAL NUMBER (If you could call it that!) > of the HARDWARE (Network Adapter) actually sending the message, or its REPLY > TO address... the address it is COMMUNICATING FROM in order to actually send > the message. I am SURE if it is to establish a 2-way link to send and > confirm the message, the receiving end HAS that info, buried deep within > what it receives. HOW can I get that, so that the route steps inbetween do > not matter? You don't have access to their MAC address or any other universal identifier, no matter how much you use the shift key. -- Eric Covener covener@... --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by Brian Mearns-2
::
Rate this Message:
On Tue, Nov 10, 2009 at 8:28 AM, Eric Covener <covener@...> wrote:
> On Tue, Nov 10, 2009 at 8:19 AM, Stephen Love <stephenlove@...> wrote: >> I have set up a routine in my server that logs all incoming IP addresses and >> parses for duplicates in the same list. HOWEVER...a person posting almost >> NEVER has the same address. I believe I am not using the actual IP Address >> at all. What I WANT is the actual SERIAL NUMBER (If you could call it that!) >> of the HARDWARE (Network Adapter) actually sending the message, or its REPLY >> TO address... the address it is COMMUNICATING FROM in order to actually send >> the message. I am SURE if it is to establish a 2-way link to send and >> confirm the message, the receiving end HAS that info, buried deep within >> what it receives. HOW can I get that, so that the route steps inbetween do >> not matter? > > You don't have access to their MAC address or any other universal > identifier, no matter how much you use the shift key. > > -- > Eric Covener > covener@... > As Eric says, what you're looking for is a MAC address which is a universally unique identifier that every network device has (though I think even here, "universally unique" might have some qualifying conditions). MAC addresses are used in very low level protocols (link layer protocols, I believe) to send packets to specific devices. MAC addresses are for point-to-point communications, not end-to-end. You could set up a packet sniffer, like Wireshark, and capture the source MAC addresses of incoming packets, but that would probably just give you the MAC address of your router or modem. As you've discovered, IP addresses are not valid ways to identify end users. Most residential internet access is done through a dynamic IP address, meaning their ISP can change their IP address whenever it wants. Further, a lot of people access the web through proxy servers, so that a large number of end users are seen as the same IP address, and others access through proxy pools or networks like Tor so that the same person may have a different IP address for every request they make. It sounds like what you're looking for is a way to track your visitors. Google Analytics is a pretty good free service for doing exactly that, or you can set up your own similar system. The way these things work is by using cookies to track individual browsers. But of course, a lot of people don't use cookies. Further, if you're worried about active menace, cookies are terribly insecure unless you're using secure connections (and even then through various types of attack), so a malicious user could snoop other people's cookies and submit it with their own request, making it look like the request came from the other user. If you want to do more strict tracking, something along the lines of "sorry, you already voted, and you can only vote once.", you'll need to get much more sophisticated. Some sort of user-authentication (i.e., "log in") is a must for this, and you'll need to be very careful about people snooping cookies and log-in date (like, only use secure HTTPS connections). -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by Rich Bowen
::
Rate this Message:
On Nov 10, 2009, at 08:19 , Stephen Love wrote: > I have set up a routine in my server that logs all incoming IP > addresses and parses for duplicates in the same list. HOWEVER...a > person posting almost NEVER has the same address. I believe I am not > using the actual IP Address at all. What I WANT is the actual SERIAL > NUMBER (If you could call it that!) of the HARDWARE (Network > Adapter) actually sending the message, or its REPLY TO address... > the address it is COMMUNICATING FROM in order to actually send the > message. I am SURE if it is to establish a 2-way link to send and > confirm the message, the receiving end HAS that info, buried deep > within what it receives. HOW can I get that, so that the route steps > inbetween do not matter? > No, you can't. It's impossible. That information (the MAC address) doesn't make it past the first hop, and there's numerous pieces of hardware (routers, firewalls, proxy servers, etc) between client and server. The receiving end does NOT have that info, buried or otherwise. It's simply not there. -- Rich Bowen rbowen@... --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by Mark H. Wood
::
Rate this Message:
On Tue, Nov 10, 2009 at 10:52:18AM -0500, Brian Mearns wrote:
> As Eric says, what you're looking for is a MAC address which is a > universally unique identifier that every network device has (though I > think even here, "universally unique" might have some qualifying > conditions). Yes. Occasionally a manufacturer goofs and issues more than one part with the same MAC address burned in. We received two desktop boxes with the same MAC address once. Imagine how often it happens and isn't caught, because they went to two different customers. :-( Also, the IEEE 802 standards define Locally Administered Addresses. Essentially you can tell most Ethernet adaptors to use any MAC address you please, so long as a particular bit is on.* A further complication is that at any time, someone could have a NIC fail, replace it, and wind up using a different MAC address from then on. Is that one user, or two? You don't know. > MAC addresses are used in very low level protocols (link > layer protocols, I believe) to send packets to specific devices. MAC > addresses are for point-to-point communications, not end-to-end. To make this plainer: the first router on the path from user X to you will discard this information. As far as the protocol stack is concerned, it has no useful meaning beyond that point. It's thus very unlikely that you will get any help from hardware manufacturers in identifying remote users or hosts in the manner you specified. You'll need cooperation from your users. ----------------- * DECnet Phase IV used this to encode the network-layer address in the link-layer address, so the same NIC would have two different MAC addresses depending on whether DECnet had been started. And the LAA would change if you ever changed the network-layer address. What fun. -- Mark H. Wood, Lead System Programmer mwood@... Friends don't let friends publish revisable-form documents. |
|
|
Re: [users@httpd]
by awarnier
::
Rate this Message:
Mark H. Wood wrote:
... > > It's thus very unlikely that you will get any help from hardware > manufacturers in identifying remote users or hosts in the manner you > specified. You'll need cooperation from your users. > And I would add that, from a user point of view, I would be very reluctant to help at any system that would let me be identified in any way other than me voluntarily and knowingly providing my id by means of some obvious login page or certificate, and then only to some party I trust not to disseminate that information outside of my control. And enough recent cases have shown that such trustable parties are not very thick on the ground. So independently of the technical issues, you are up against some guaranteed and well-founded resistance. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by LuKreme
::
Rate this Message:
On 10-Nov-2009, at 13:49, André Warnier wrote:
> And I would add that, from a user point of view, I would be very reluctant to help at any system that would let me be identified in any way other than me voluntarily and knowingly providing my id by means of some obvious login page or certificate, and then only to some party I trust not to disseminate that information outside of my control. > And enough recent cases have shown that such trustable parties are not very thick on the ground. Heck, I don't even trust MYSELF that much. -- 'They say that whoever pays the piper calls the tune.' 'But, gentlemen,' said Mr Saveloy, 'whoever holds a knife to the piper's throat writes the symphony.' --Interesting Times --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
|
|
|
|
|
|
|
|
|
Re: [users@httpd]
by Eric Covener
::
Rate this Message:
On Tue, Nov 10, 2009 at 6:20 PM, Stephen Love <stephenlove@...> wrote:
> So what you are telling me is that there IS no REAL 2-way handshaking going > on. Then we've lost ALL hope of security. > What's "REAL" in this context? It's not authenticated and doesn't result in some session establishment unless you configure your application to require/manage such a thing? -- Eric Covener covener@... --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by Eric Covener
::
Rate this Message:
On Tue, Nov 10, 2009 at 6:24 PM, Stephen Love <stephenlove@...> wrote:
> Don't want identification. I want point to point response capability, even > if it goes away later... a way to know that I can send back to that exact > address and know it went to that particular computer instead of randomly > going all over the world. Sounds like either I have been misinformed about > how packets are sent, or a LOT of programmers simply do not know the truth! > 2-way handshaking requires session identification ALL the way back to its > source. You get all this from TCP, you just can't make any statement about how different TCP connections over time are related (as your OP implied) -- Eric Covener covener@... --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by Sean Conner-3
::
Rate this Message:
It was thus said that the Great Stephen Love once stated:
> So what you are telling me is that there IS no REAL 2-way handshaking > going on. Then we've lost ALL hope of security. There is a 2-way handshake, but it's at the TCP layer, which is used to establish a reliable, stream-oriented sequence of data. As far as the browser and server are concerned, they're talking directly to each other: HTTP client <-----> HTTP server but in reality, the HTTP protocol is wrapped in the TCP layer: HTTP client HTTP server ^ ^ | | v v TCP <-------------------> TCP but in reality, the TCP protocol (which establishes reliability and a stream oriented (or line oriented if you care to view it that way) over the IP protocol (which itself doesn't guarentee reliability, and is packet oriented, not stream-oriented): HTTP client HTTP server ^ ^ | | v v TCP TCP ^ ^ | | v v IP <-----------------------> IP And thus completes a full TCP/IP connection. IP itself is embedded in a multitude of hardware layer protocols, like Ethernet, T1 (which has a few framing protocols itself), PPP, PPPoE, SCSI [1] or even avian carriers [2][3], so the lower layers of the stack (below the IP layer) that get stripped and added as the packet makes it way across the Internet. An example might look like: HTTP client HTTP server ^ ^ | | v v TCP TCP ^ ^ | | v v IP +- IP --+ +- IP --+ IP ^ | | | | ^ | | | | | | v v v v v v Ethernet <--> Ethernet T1 <--> T1 Ethernet <--> Ethernet client router router server ^ | Any number of hops here (also note that the T1 listed here is just an example; it most likely is PPPoE over ATM (which comprises DSL I think), so there may even be a few layers below the IP layer) The MAC address of the client doesn't even survive the first hop. The server ends up with the MAC address of the router as the "sender", even though the IP packet comes from the client somewhere else on the Internet. It helps to think of it this way: IP allows individual computers to communiate; TCP allows individual programs to communiate. Once you get a connection, you have a few pieces of information about the other side: it's an HTTP connection (a given) over a TCP connection (a given) the local side's TCP port # (usually 80 if HTTP) the local side's IP address (typically a given) the remote side's TCP port # the remote site's IP address If you want more unique inforamtion, then you need to look into stuff like cookies and session management (which is beyond the scope of HTTP for the most part). -spc (Hope this clears up some misconceptions) [1] RFC-2143 [5] [2] RFC-1149, updated by RFC-2549 [3] No, really! It's even been done. [4] [4] http://en.wikipedia.org/wiki/IP_over_Avian_Carriers [5] RFCs are documents that document the various Internet standards. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
|
|
|
Re: [users@httpd]
by Brian Mearns-2
::
Rate this Message:
On Tue, Nov 10, 2009 at 6:37 PM, Eric Covener <covener@...> wrote:
> On Tue, Nov 10, 2009 at 6:20 PM, Stephen Love <stephenlove@...> wrote: >> So what you are telling me is that there IS no REAL 2-way handshaking going >> on. Then we've lost ALL hope of security. >> > > What's "REAL" in this context? It's not authenticated and doesn't > result in some session establishment unless you configure your > application to require/manage such a thing? > > -- > Eric Covener > covener@... Yes, why don't you tell us exactly what you want to do, what's your end goal? Visitor stats? Geographic locating? Authentication of a real-world identity? There's a lot of very bright and very knowledgeable people on this list, so if there's any way at all to do what you want, then there is a very good chance that somebody here will be able to tell you. It just might not be done the way you think it should be. As many of us have said, TCP is an end to end protocol. And in fact, it is stateful, so you can send messages back and forth between the two end points for as long as the connection is open. There is a handshake that goes on between the two end points to setup this connection, but this is not any sort of real authentication process that confirms the identity of either end. What TCP gets you is pretty good confidence that you are talking to the same person you were when you started the conversation, but even that confidence is really only upheld in the absence of active attacks like IP spoofing, and it provides absolutely no confidence that there aren't other people listening to the conversation, and potentially even participating in the conversation. If you're looking for security: like making sure no one else is listening to the conversation, no one else is modifying the conversation data, and or making sure that the person on the other end is who they claim to be...then you're going to need a much more sophisticated protocol than TCP, IP, or HTTP. SSL/TLS provides all these things, with the latest TLS version believed to be quite secure with current technologies and techniques. HTTPS layers HTTP over a secure SSL or TLS connection, and is available in Apache with mod_ssl. Your comment that "we've lost ALL hope of security" is quite accurate with regards to HTTP, TCP, and IP alone. These protocols were really not designed with any attention to security as security wasn't really an acknowledged concern at the time they were created. Thus we have add on protocols like SSL and TLS. Anyway, back to my point: tell us what you're actually trying to do and there's a good chance someone can help you, as long as you're willing to let go of any preconceived notions on how to get the job done (that's always the biggest stumbling block to learning something new). Cheers, -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by Brian Mearns-2
::
Rate this Message:
On Tue, Nov 10, 2009 at 10:29 PM, Stephen Love <stephenlove@...> wrote:
> Ok, now we're getting somewhere... just ENOUGH to eliminate the path > inbetween... I'd just like to ask APACHE for a unique signature of the > machine sending the message to compare it against others. Nothing more, > nothing less. > > > See us online at http://www.LOVEnCompany.com. > Well, see my most recent message, but just to summarize, apache can't uniquely identify the end machine on it's own, all it has is what that machine send to it, which is IP packet, which contains the TCP packet, which contains the HTTP packet, none of which include (on their own) a unique identifier for the end machine. The best you can do with just these protocols is generate a unique id, send it to the client, and ask them to send it back. You can do this using cookies, or by encoding the id in the URL. But either way, you're relying on the end user to cooperate (i.e., send back the same identifier). If you're looking for something that they can't reasonably fake or alter without your knowing, you'll need a crypto protocol like TLS (again, see my last message). -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by Norman Peelman
::
Rate this Message:
Stephen Love wrote:
> > Don't want identification. I want point to point response capability, > even if it goes away later... a way to know that I can send back to > that exact address and know it went to that particular computer > instead of randomly going all over the world. Sounds like either I > have been misinformed about how packets are sent, or a LOT of > programmers simply do not know the truth! 2-way handshaking requires > session identification ALL the way back to its source. > > you can go by and that can change on a request basis. The IP address is the 'street address' you want but they are not all assigned permanently at this time. -- Norman Registered Linux user #461062 --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by Norman Peelman
::
Rate this Message:
Stephen Love wrote:
> Ok, now we're getting somewhere... just ENOUGH to eliminate the path > inbetween... I'd just like to ask APACHE for a unique signature of the > machine sending the message to compare it against others. Nothing > more, nothing less. > > nope... -- Norman Registered Linux user #461062 --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by awarnier
::
Rate this Message:
Stephen Love wrote:
> Ok, now we're getting somewhere... just ENOUGH to eliminate the path inbetween... I'd just like to ask APACHE for a unique signature of the machine sending the message to compare it against others. Nothing more, nothing less. > > > See us online at http://www.LOVEnCompany.com. > Well, it looks like this list already gave you all the possible human-level help. If that does not solve your problem, maybe you should ask for some higher-level intervention. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: [users@httpd]
by Johnny SSH
::
Rate this Message:
André Warnier wrote:
> Stephen Love wrote: >> Ok, now we're getting somewhere... just ENOUGH to eliminate the path >> inbetween... I'd just like to ask APACHE for a unique signature of >> the machine sending the message to compare it against others. Nothing >> more, nothing less. >> >> >> See us online at http://www.LOVEnCompany.com. >> > Well, it looks like this list already gave you all the possible > human-level help. If that does not solve your problem, maybe you > should ask for some higher-level intervention. > > > directly compatible with the TCP/IP system's stack - in fact it's kind of an expanded version that all network engineers use!! Basically in the underlying network components you have physical, media access, and network layers (1-3); layers 4-7 usually deal with the computers themselves which start from ports and go to the apps themselves. Now layer 2, at least true for Ethernet means that the MAC address of the system is only point to point between machine and switch port, after that things change. Layer 3 is convoluted by the intervention of NAT or proxy so the only thing you are likely to get is the WAN IP address of the network. Unique identifiers are impossible, even using Cisco's proprietary CDP (cisco discovery protocol) which discoverers neighboring Cisco devices cannot go beyond next hop device as uses layer 2 addressing as reference!!! The only way I suppose in theory one could do what you are after is for the user to download a little app that has a unique signature and broadcasts the full system info according to that. So at least with the client part of the program you could have say 1 x 10^50 unique signatures generated by a shell script or program then link them to a server somewhere...... I do believe this is called spyware though and is highly illegal!!! In all honesty I think the best way is going through webalizer, GeoIP, awstats, or Ntop!!! And if going through reverse proxy with Squid like me; unlike me you can form the logs of Squid in a different way and hence forward those to Apache, then get Apache to read those 'different' logs so that you have the correct data collection available to you........ As far as I know of this would be about the only way to go! At least you get the WAN IP of the remote network and can collect and collate geographic locational information and also ISP info too :-) Without using divine power or alien intervention....... --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@... " from the digest: users-digest-unsubscribe@... For additional commands, e-mail: users-help@... |
attachment0 (205 bytes) 
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
