Can I block based on MAC address?

In short, the answer is no, you usually can't block based on MAC address. And if you could, it would be useless. To understand why, you must know a thing or two about how the internet works.

Communication between devices is commonly done via the Ethernet protocol (wiki), and despite the source and destination being identified by IP, actual communication is done per MAC. Imagine the following network:

If the client wants to send a packet to the server, it first checks whether the server is in the same subnet. Nope, the server has a 10.x IP, and the client an 192.168.x IP. The client then sends it to his router, R1, in the hope that it will be able to forward it to the destination. The packet contains:

Source IP:       192.168.1.100     (belongs to: Client)
Destination IP:  10.1.1.1          (belongs to: Server)
Source MAC:      01:01:01:02:02:02 (belongs to: Client)
Destination MAC: 02:01:01:02:02:02 (belongs to: R1)

Then R1 is like "Oh, that IP is somewhere on the internet". It changes the source IP to the public IP (so that the server can send a packet back), and forwards it to R2. The packet now contains:

Source IP:       172.16.1.1        (public IP from R1)
Destination IP:  10.1.1.1          (belongs to: Server)
Source MAC:      02:01:01:02:02:02 (belongs to: R1)
Destination MAC: 03:01:01:02:02:02 (belongs to: R2)

As you can see, the destination IP doesn't change, but the MAC addresses changes every time it gets forwarded (by a router) based on which router it is forwarded to and which router it came from.

Moving forward, R2 will not tamper with any of the IPs like R1 did because it is not a NAT router (like most consumers have). R2 will merely forward the packet.

In the end, the server will only be able to see the MAC address from R3. For the communication to work, that's all it needs to know besides the original IP from R1. (When a reply packet comes back at R1, other things make sure the packet finds its way to the client.) If you want to know why not all communication is simply MAC-based, have a look at this question on serverfault.

One exception to this is when the client is inside the same LAN as the server. As I mentioned, the client first compares the IP subnet of itself and the destination. If it's the same (e.g. 192.168.1.101 and 192.168.1.44, when on a /24 subnet), the communication is based on MAC address. The client will broadcast a message on the LAN, asking for the MAC belonging to the server's IP, and then send it to that MAC. The packet will still contain the destination IP, but there is no router between the two. (There may be, but then it will be acting as a switch or hub, not as router.) But this is probably not the scenario you had in mind.

If you could determine the MAC, that would be a pretty big privacy violation. Since your MAC address arguably identifies you uniquely on the globe, advertising networks would have no problem tracking you, also without tracking cookie or any other methods.

Blocking an attacker by MAC would be the same as blocking him/her by cookie because it is controlled by the client. Currently it's almost never changed because there is almost never a reason to, but if you could determine and block an attacker by MAC, he could simply change it. An IP addresses must be globally recognized in order to be routable, but a MAC doesn't have this issue.

Also, an attacker could block clients whose MAC he knows by spoofing that MAC address and then triggering the block. Whoever really uses that MAC address would be prohibited from using the service.

Conclusion: If it were possible it would be rather ineffective and while introducing a DoS vulnerability, but since you can't make the client send the MAC along with HTTP headers or something, it's just not possible outside the same LAN.

No, the MAC Address isn't send on the headers. Tough, you might want to check: https://panopticlick.eff.org/

Source MAC addresses (layer 2) are only going to show the last router to forward the packet.