Jump to content

MAC Address Logging


Recommended Posts

Posted

I know there are methods in C/C++ to retrieve a mac address, but getting the mac address of someone connecting to you is a little harder I'm guessing. I'm guessing it would be hard to retrieve the actual mac address of the computer but at very least there might be a way to find the router's address, at least this is what i'm thinking as i could be absolutely wrong. While researching this topic i found the following code snippet.

include <iostream>
#include <stdio.h>
#include <netdb.h>
#include <netinet/if_ether.h>

int _get_MAC(void) {
   int sock,sockfd, n, cnt;
   char buffer[2048];
   unsigned char *iphead, *ethhead;
   struct ether_addr ether;

   if ( (sock=socket(PF_PACKET, SOCK_RAW,htons(ETH_P_IP)))<0){
       perror("socket");
       exit(1);
   }

   while (1) {
       if (n = recvfrom(sock,buffer,2048,0,NULL,NULL)== -1) {
           perror("recvfrom");
           close(sock);
           exit(1);
       } 

       ethhead = (unsigned char *)buffer;

       if (ethhead != NULL){
           iphead = (unsigned char *)(buffer+14); // Skip Ethernet header
           printf("\\n--------------------------------------"
               "\\nMAC destino (server): "
               "%02x:%02x:%02x:%02x:%02x:%02x\\n",
               ethhead[0],ethhead[1],ethhead[2],
               ethhead[3],ethhead[4],ethhead[5]);
           printf("MAC origen  (CAL30x): "
               "%02x:%02x:%02x:%02x:%02x:%02x\\n",
               ethhead[6],ethhead[7],ethhead[8],
               ethhead[9],ethhead[10],ethhead[11]);  

           if (*iphead==0x45) { // Double check for IPv4 and no options present
               printf("IP destino  (server): %d.%d.%d.%d\\n",
                   iphead[12],iphead[13],
                   iphead[14],iphead[15]);
               printf("IP origen   (CAL30x): %d.%d.%d.%d\\n",
                   iphead[16],iphead[17],
                   iphead[18],iphead[19]);
               printf("Protocolo   (UDP=11): %02x Hex\\n",iphead[9]);
           }
       }    
   }
   return 0;
}


int main(int argc, char **argv) 
{
   _get_MAC();
     return 0;
}

It's written in C and i think it would be very cool if this could be applied to the mangos server. I'm not sure if this is a question or a comment :lol:. I guess my question is with the method that the client connects to mangos is this possible or not. I'm sure I'm missing something but i just wanted to put it out there. Any comments, suggestion to point me in the write direction, or anything at all would appreciated.

Posted

Yes, it's easily possible to get first 14 bytes of a packet using RAW socket, but ... it has no real use for mangos. Use firewall if you want to do ban-by-mac .. however be aware that the address can be easily changed on the card / in the driver, so it's ineffective.

Posted

IP addresses can easily be changed as well, by either a dynamic IP or a proxy, so that isn't really any use either for serious security (even more so because you can't ban IP ranges, only specific addresses.)

I think a combination of MAC and IP banning would be the best security you can possibly have.

Posted
I have to disagree. The best security is to allow only localhost :D

A manager once complained about the internet bills here. I recommended just pulling the ethernet cable out of the computer and watching the money pile up.

On-topic: I think MAC banning would be a good measure for added security and will be looking into it.

Posted
On-topic: I think MAC banning would be a good measure for added security and will be looking into it.

Frankly, that's nonsense. There's absolutelly NO security when it comes to MAC addressing. Really NO security.

Mac-level addressing is used only within one subnet, ie. in LANs. It doesn't go over routers. So fine, it would be good for LANs at least ... no, wrong.

As I said earlier, you can very easily (in GNU/Linux, Windows, all *nixes I know) change the mac address of your card in a driver. So that you ban one user, he changes it to 44:55:66:77:88:99 and plays.

Now you could say "well I can at least allow several MACes and ban the rest". I had a real reason saying "NO security", this wouldn't work either. A banned user can change his MAC to already used one, making possible problems along the way (google for "switch port stealing").

If the network runs on IPv4, it can do even more - block someone else by spoofing an ARP reply of the mangos server and connect to the server under his identity. That way you can't even detect race conditions on the server machine (= spam of ARP packets, there will be none, since the original (now blocked) user uses nonexistent MAC, not the server's one).

It's very similar to IPv4 address "model" for LAN and connected with it via ARP. Ie. you can have two machines with the same IP address in the same subnet, but they will "fight" with each other about the place in server's ARP table. Well, the flood way mostly works.

Posted

This reminds me of people who think that MAC address filtering is an effective 'security' method on wireless networks (along with hiding the SSID, of course!).

Posted
Frankly, that's nonsense. There's absolutelly NO security when it comes to MAC addressing. Really NO security.

Mac-level addressing is used only within one subnet, ie. in LANs. It doesn't go over routers. So fine, it would be good for LANs at least ... no, wrong.

As I said earlier, you can very easily (in GNU/Linux, Windows, all *nixes I know) change the mac address of your card in a driver. So that you ban one user, he changes it to 44:55:66:77:88:99 and plays.

Now you could say "well I can at least allow several MACes and ban the rest". I had a real reason saying "NO security", this wouldn't work either. A banned user can change his MAC to already used one, making possible problems along the way (google for "switch port stealing").

If the network runs on IPv4, it can do even more - block someone else by spoofing an ARP reply of the mangos server and connect to the server under his identity. That way you can't even detect race conditions on the server machine (= spam of ARP packets, there will be none, since the original (now blocked) user uses nonexistent MAC, not the server's one).

It's very similar to IPv4 address "model" for LAN and connected with it via ARP. Ie. you can have two machines with the same IP address in the same subnet, but they will "fight" with each other about the place in server's ARP table. Well, the flood way mostly works.

Yeah, but you are saying it isn't effective for the reasons:

A. It doesn't go over routers; and

B. You can change it easily.

The only real problem I have with this is that the exact same applies to IP address banning. Do you think mangos should dump that as well, since it provides "NO security"?

I think you are missing a fundamental point. Yes, there are going to be experienced hackers out there to ruin your day and mess things up, and they are going to change their MAC if you block it. But most of the people out there who are hacking are 12-year-old kids with tools they found on the internet (which may or may not contain trojans) Most of them aren't going to figure out how to change their MAC address, let alone that you banned it.

There IS more security in banning IPs and MACs. You can change both, but by the time you do you might as well go hack on some less secure server.

Posted

Well the point is that not everyone has public dynamic IP or several SOCKS proxies available, so IP banning is effective even if the user isn't 12-year-old kid.

However .. http://www.google.com/search?hl=en&q=change+MAC+windows

Anyway - whatever. If you want it, I won't stand in your way :) .. My opinion is that mangos should provide only account-level and character-level banning, network-based bans (IPv4, IPv6, MAC, any tunnels (L2TP), ..) should be done externally.

Posted

The way I see it, there's no such thing as complete security, it's all about how many people are able to break it and how many are willing to put forward the time and effort to do so.

While there are ways to get around IP and MAC restrictions, those methods are not accessible to everyone. The people who you ban are usually not hackers but stupid kids who don't know about these things.

And when it comes to proxies it's hard to find good ones if you don't know where to look. Best you can hope for is extremely low bandwidth, huge latency and no guarantee of uptime. So the offenders might come back but they won't be able to actually play the game through a proxy.

Posted

Wow, very interesting thread responses, I do agree that any who can do at least a couple minutes of research can find out how to change there mac address on there computer. But doesn't everything that connects to the internet have a mac address, ie. routers?. And im guessing its harder to change the mac address on your router if not near impossible. Now i guess back to the question is it possible to get the routers mac address?

Posted
Wow, very interesting thread responses, I do agree that any who can do at least a couple minutes of research can find out how to change there mac address on there computer. But doesn't everything that connects to the internet have a mac address, ie. routers?. And im guessing its harder to change the mac address on your router if not near impossible. Now i guess back to the question is it possible to get the routers mac address?

If you'd ban your router, you would ban everyone.

Posted

Sorry i think i phrased that wrong i meant ban the mac address of the "offenders" router, although i might not understanding correctly but wouldn't that be theoretically possible?

Posted

If i didn't completely screw the Layer hierarchy in my head, then MAC address is used in the Ethernet layer, NOT the whole internet.

The MAC your server can query via ARP only helps it to determine the physical device that it has to send the packet to so it eventually gets forwarded to the actual recipent. Hence your server will generally not be able to determine the MAC of a player, or HIS router.

As said, you'd basically ban your own router and hence take the server offline...

Posted
So, the only real practical way to ban a MAC address is through client-side anti-cheat?

Not even then, as MAC changes everytime you route a packet using router. Do a traceroute to google.com for example - every machine in the way changes both (source + dest) MAC addresses in the packet. Furthermore - MAC header is not always standard, there can be a sattelite link in the way, using something else for link-level addressing.

  • 4 weeks later...
Posted
I wouldn't mind IP range banning (for those who have dynamic IPs but limited to a small subset of IPs)

Ok, time to bump an old thread.

My opinion here: Any method of IP banning/MAC blocking done by MaNGOS would be less effective than already-existing programs that do exactly this.

First, many routers can do this. Second, your firewall should be able to do this. Third, there are already-existing applications (such as PG2) that already do this.

Posted

Yes, but not everyone has access to such tools. For example, on a test server I was using once, it was a shared system, the root admin controlled the iptables and firewall. Furthermore, getting access to a datacenter's router controls isn't exactly an easy task.

Posted
I understand. Sometimes it's too hard to click on the link embedded in my previous post.

What? PG2? If I'm using iptables, I thought you would have assumed I used Linux.

Yeah, there's probably some firewall tool out there. But without root access, it might be hard to find one which works properly.

Posted

Full of assumptions here, because I assumed you could see the links to Linux and OS X versions at the PG2 homepage.

Do you expect me to embed three separate links in a forum post? At some point in time, you have to do a little looking yourself and not expect others to do it all for you.

Posted

Given the non-existant version of PG2 (natch, "MoBlock") requires access to /etc, and on a shared system, you don't allow users to have write-access to /etc, that might be difficult to use.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use