ipfw with nat - allowing by MAC address

[AT Matik]

On Thursday 26 April 2007 19:54, Lubomir Georgiev wrote:
>   Yeah! People, we can congratulate ourselves! We've done it! With a few
> modifications I've finally found the smallest working MAC filtered NAT
> system. So here's what I ended up with - I'm including the queues just for
> the entirety of the ruleset, they have nothing to do with the filtering.
>

not so loud, the honors are coming only at the end and often only after the 
end :) when we are dead already :) unfortunatly of course but life is hard :
( :)   

fun aside, even if you might be able to *block* access using a layer2 rule any 
further layer2 rules as skipping in order to jump to another rule on a 
*router* is not catching anything else as arp, means it is certainly useless 

a natd router is what the name says a router and so the legitmate traffic in 
this scenario is *IP* hitting the GW IP and *NOT* layer2, being then "routed" 
to the servers default gateway - so - as long as the mac of the src-ip is in 
the arptable it's traffic goes through whatever nasty fun you do 
with "layer2" level rules

if then exists a natd this traffic might be diverted before leaving the box

finally,  here is *NO* layer2 traffic (BRIDGED traffic) 

hence, what you can do is make traffic flow decision based on src/dst IPs or 
ports, nothing else

then,  even if you (can) block layer2 mac traffic (arp) on a router it does 
not touch any legitimate ip traffic, so obviously your arptable will *age 
out*  and suddenly no arp goes through (or to) this box anymore and/or 
depending on your rules anything is diverted and you lose access to the 
router ... so as hint, any who likes to play with arp of any kind should not 
only do ipfw flush but also run arp -ad in order to get clean and reliable 
results for nasty rules "in real time" :) 

blocking a mac by blocking arp is one thing
controlling traffic flow based on MAC is another

in order to control layer2 TRAFFIC flow you need a bridge

what follows is a thought because i never needed something like this but the 
only possible setup for *YOUR* wish I can imagin is first making it a bridge 
with no IP on the inner NIC, then associating the GW IP of the internal 
subnet to the bridge or the external nic

if you have then two IPs on the external NIC you divert on IP and not the NIC

*NOW* finally you get bridged traffic (LAYER2) to the gw ip which you CAN 
control as "skipto proto ip layer2 mac" not from authorized macs to a rule 
higher than the divert rule in order not hitting the divert rule. Ok?

Resuming, as long you have a router you can not control layer2 traffic, you 
only might be able to block certain arp traffic to a certain extense

Sooo, at the end this are only my thoughts and opinions, like I said before 
router and layer2 with ipfw sounds strange to me so I do not use it today and 
what I said here might work for one and not for another so please don't hit 
me if you get unexpected results :) 


some comments, no ofense pleease:

> 00100 allow ip from any to me not dst-port 8668 via xl0
> 00101 allow ip from me not 8668 to any via xl0

useless

> 00300 allow ip from any to any { MAC 00:19:d2:36:b8:48 any or MAC any
> 00:19:d2:36:b8:48 } layer2

not sure if you want "or" or even {}

> 00800 deny log logamount 200 ip from any to any MAC any any layer2 via xl0

this is your time-bomb which kills access to the router internally, means your 
ruleset might work until the active macs (arptable) are timing out (!on a 
router)

> 01203 divert 8668 ip from 192.168.1.0/24 to any out via fxp0
> 01205 divert 8668 ip from any to me in via fxp0

ook


> 01250 queue 1 ip from any to any src-port 80 not layer2 via fxp0
> 01251 queue 1 ip from any to any dst-port 80 not layer2 via fxp0
> 01300 queue 2 ip from any to any not src-port 80 not layer2 via fxp0
> 01500 allow ip from any to any
> 65535 deny ip from any to any
>

whatever ... but

if your interest or concern is only with tcp:80 you might consider squid which 
has some kind of mac acl and you reduce your ipfw-brain-damage on this 
issue :)

João









A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br