How ban mac-addres

[smithi]

Can't say we didn't try.

 

[kerogaz]

Can't say we didn't try.

How will my script work if it works with a policy of denying everything, but here you need to allow everything? By the way about three years ago I launched Layer 2. Did not help

 

[kerogaz]

You know you can add a filter to tcpdump(1)? tcpdump -ni igb3 host 10.44.1.17

In this case you probably want to capture traffic from a specific MAC address; tcpdump -eni igb3 ether 11:22:33:44:55:66 You'll want to add -e here too, so the output actually shows the MAC addresses of the packets.

tcpdump -eni igb3 ether 00:1E:8C:16:18:2B
tcpdump: can't parse filter expression: syntax error

 

[SirDice]

Oh, oops, sorry, it's tcpdump -eni igb3 ether host 00:1E:8C:16:18:2B

 

[kerogaz]

I don't know if my script will work with VladiBG recommendations

#!/bin/sh -

fwcmd="/sbin/ipfw"
${fwcmd} -f flush
${fwcmd} table all flush
${fwcmd} nat 1 delete

# NETWORK CONNECTIONS
if_inet="igb2"
if_lan="igb3"

# Local
${fwcmd} add allow all from any to any via lo0
#${fwcmd} add deny ip from any to any MAC any FC:34:97:BD:16:D9 in recv igb3
${fwcmd} add deny all from any to 127.0.0.0/8
${fwcmd} add deny all from 127.0.0.0/8 to any

# NAT
${fwcmd} nat 1 config if ${if_inet} same_ports reset log
${fwcmd} add nat 1 ip from "table(0)" to any out via ${if_inet}
${fwcmd} add nat 1 ip from any to any in via ${if_inet}

# TABLE (0):
${fwcmd} add allow ip from any to any
${fwcmd} table 0 add 10.44.1.1
---- etc all allowed ip
-----
${fwcmd} add allow tcp from any to any 80

 

[kerogaz]

I add

#MAC
${fwcmd}  add  allow ip from any to any layer2 mac-type 0x0806
${fwcmd}  add  deny ip from any to any MAC any fc:34:97:bd:16:d9

and after

sysctl net.link.ether.ipfw=1

all trafic stop

I think that without changing policy IPFW, nothing will work, and if I change the policy 65535 from deny to allow , my script will not work.But I changed policy 65535 to allow without rebuilding the kernel two years ago and it didn’t help

 

[smithi]

I add

#MAC
${fwcmd}  add  allow ip from any to any layer2 mac-type 0x0806
${fwcmd}  add  deny ip from any to any MAC any fc:34:97:bd:16:d9

and after

sysctl net.link.ether.ipfw=1

all trafic stop

Correct, because while you have allowed ARP (mac-type 0x0806), and you have blocked that particular MAC address (which could be in another table), you have NOT allowed all the other layer2 traffic (ethernet frames), so ALL traffic is now blocked, because you have not then added an allow all rule - see VladiBG's last:

ipfw add 500 allow ip from any to any

A final allow (or deny) of all traffic removes any need to consider whether the default last rule 65535 is deny or allow, so making absurd the notion of having to rebuild the kernel.

That's why the 'open' rc.firewall type is just 'add 65000 pass all from any to any'.

If it were me I'd specifically add, after denying particular MAC address rule/s,
add allow ip from any to any layer2
to finish off the layer2 section.

However the allow all rule at the end will serve the same purpose.

Just repeating VladiBG's rules here for reference, as it seems likely you won't believe me

ipfw -q -f flush
ipfw nat 1 config if igb2
ipfw add 100 allow ip from any to any layer2 mac-type 0x0806
ipfw add 200 deny ip from any to any MAC any fc:34:97:bd:16:d9
ipfw add 300 nat 1 ip4 from any to me in via igb2
ipfw add 400 nat 1 ip4 from 10.44.1.0/24 to any out via igb2
ipfw add 500 allow ip from any to any

 

[kerogaz]

You write that I don’t believe you. But this is not a religion to believe. I check and if it works, I say thank you. But for now, unfortunately, I cannot say thank you.
Your line 500 is in my scrit

# TABLE (0):
${fwcmd} add allow ip from any to any
${fwcmd} table 0 add 10.44.1.1

and "deny" is by default in line 65535 and NAT takes allowed IPs from the table (0) of my script, not from 10.44.1.0/24

If I set

ipfw add 400 nat 1 ip4 from 10.44.1.0/24 to any out via igb2

then my table (0) will not work.In general, it seems to me that this time the problem is not solved. I’m transferring the tables of allowed addresses to the Archlinux iptables and will turn it on as a gateway in critical cases when I need to kill MAC,fortunately this happens extremely rarely.Two years ago, I spent 1 month resolving this issue on forums in 4 countries. I didn’t achieve anything. I'm doing this now because I thought that something had changed in new releases of the system. I update from version 10 continuously.By the way, I had a script on iptables that only allowed through NAT those IP that met the requirements of their mac (the table of allowed IP + Mac was loaded) I tried to do this in IPFW, but this not worked

 

[Erichans]

You write that I don’t believe you. But this is not a religion to believe. I check and if it works, I say thank you. But for now, unfortunately, I cannot say thank you.

[slightly off-topic]
Generally, one could also consider being thankful for all the knowledgeable, well-intentioned help and assistance being freely offered—irrespective of the fact that it may look like it does not solve all ones problems, however frustrating that may feel.
[/slightly off-topic]

 

[wally]

Hello

Yes, I see this computer using nmap -Pn 10.44.1.178 . But tcpdump does not show packets from this address. However, this user with this MAC manually changes his static IP every day, and banning a new IP every day is unreasonable. Why would he do this if he doesn’t use the Internet?Or maybe he is using a tunneling program?

You state that the incoming packets are sourced from a class A private network.
You also state that the machines IP address changes on a daily basis, indicative of DHCP perhaps yet you state that it is statically assigned.

The machine must therefore be on the same LAN as you.
If the Network has is not running DHCP and is Statically configured, how come the user can just input a random IPv4 address from the network?
Do you assign IPv4 addresses on this network.

Is the ABR running dual stacks?

 

[SirDice]

However, this user with this MAC manually changes his static IP every day, and banning a new IP every day is unreasonable. Why would he do this if he doesn’t use the Internet?

Turn off the switch port they're connected to. Provide web browsing through a proxy, add authentication on the proxy. No account, no internet browsing. If all that doesn't work, use a LART.

 

[kerogaz]

Hello


You state that the incoming packets are sourced from a class A private network.
You also state that the machines IP address changes on a daily basis, indicative of DHCP perhaps yet you state that it is statically assigned.

The machine must therefore be on the same LAN as you.
If the Network has is not running DHCP and is Statically configured, how come the user can just input a random IPv4 address from the network?
Do you assign IPv4 addresses on this network.

Is the ABR running dual stacks?

All ip address of local network are static. The machine is gateway of this local network. I assigne ipv4 ot this network

 

[kerogaz]

Turn off the switch port they're connected to. Provide web browsing through a proxy, add authentication on the proxy. No account, no internet browsing. If all that doesn't work, use a LART.

Its request ports change every time and are in the upper ranges. In general, there is good news: I found this person geographically. This was an inexperienced user who was told that if there is no Internet, change the IP. But still the problem of filtering mac address was not solved

 

[smithi]

You write that I don’t believe you. But this is not a religion to believe. I check and if it works, I say thank you. But for now, unfortunately, I cannot say thank you.

Fair enough, but I'm about to show why I think you haven't got it working yet.

ipfw is very much like assembler code, requiring precision. If you examine ipfw source code you'll see its rules are parsed into a virtual machine of sorts, so traversing the ruleset is fast and efficient; thanks Prof. Rizzo!

As an old systems programmer I like it like that, but it's not for everyone. Many prefer using pf(8) which I see as more of a high-level, conceptual language than ipfw.

Your line 500 is in my scrit

# TABLE (0):
${fwcmd} add allow ip from any to any
${fwcmd} table 0 add 10.44.1.1

VladiBG's line 500, of his tested, working example script. But his nat rules are for 'ip4' not ip (=all).

With natd(8) it was an error to pass non-ip4 packets to it. I'm not certain with kernel NAT, but passing layer2 frames to it as you're doing here seems unlikely to end well. Only later do you pass all, including layer2.

So once again, please try with layer2 (ether) enabled and your pass ARP and deny $BOGON layer2 rule(s), adding immediately afterwards:

add allow all from any to any layer2

And then layer2 is done with, so proceed with your layer3 stuff - though I'd use ip4 on the nat rules (in case there are e.g. ipv6 packets in the mix).

In general, it seems to me that this time the problem is not solved. I’m transferring the tables of allowed addresses to the Archlinux iptables and will turn it on as a gateway in critical cases when I need to kill MAC,fortunately this happens extremely rarely.Two years ago, I spent 1 month resolving this issue on forums in 4 countries. I didn’t achieve anything. I'm doing this now because I thought that something had changed in new releases of the system.

Still sounds like you think there's something broken with ipfw, rather than you hadn't yet found out how to use it correctly?

I know ipfw(8) is a big manpage, but it's very thorough and kept correct and up to date, and you can ignore many sections that don't apply to your usage - but you won't get away without familiarity with the basics. Maybe check out pf?

I update from version 10 continuously.By the way, I had a script on iptables that only allowed through NAT those IP that met the requirements of their mac (the table of allowed IP + Mac was loaded) I tried to do it here, I also suffered for a month on the forums and nothing worked

Which forums?

Not sure what you're saying here, but you can also use tables of MAC addresses rather than single rules for white- or black-listing, if declared properly.

SirDice nailed it, but I'll add:
a BOFH with no LART is like a Pub With No Beer ...

 

[kerogaz]

Fair enough, but I'm about to show why I think you haven't got it working yet.

ipfw is very much like assembler code, requiring precision. If you examine ipfw source code you'll see its rules are parsed into a virtual machine of sorts, so traversing the ruleset is fast and efficient; thanks Prof. Rizzo!

As an old systems programmer I like it like that, but it's not for everyone. Many prefer using pf(8) which I see as more of a high-level, conceptual language than ipfw.



VladiBG's line 500, of his tested, working example script. But his nat rules are for 'ip4' not ip (=all).

With natd(8) it was an error to pass non-ip4 packets to it. I'm not certain with kernel NAT, but passing layer2 frames to it as you're doing here seems unlikely to end well. Only later do you pass all, including layer2.

So once again, please try with layer2 (ether) enabled and your pass ARP and deny $BOGON layer2 rule(s), adding immediately afterwards:

add allow all from any to any layer2

And then layer2 is done with, so proceed with your layer3 stuff - though I'd use ip4 on the nat rules (in case there are e.g. ipv6 packets in the mix).



Still sounds like you think there's something broken with ipfw, rather than you hadn't yet found out how to use it correctly?

I know ipfw(8) is a big manpage, but it's very thorough and kept correct and up to date, and you can ignore many sections that don't apply to your usage - but you won't get away without familiarity with the basics. Maybe check out pf?



Which forums?

Not sure what you're saying here, but you can also use tables of MAC addresses rather than single rules for white- or black-listing, if declared properly.

SirDice nailed it, but I'll add:
a BOFH with no LART is like a Pub With No Beer ...

whatever you say:

#MAC
${fwcmd}  add  allow ip from any to any layer2 mac-type 0x0806
${fwcmd}  add  deny ip from any to any MAC any fc:34:97:bd:16:d9
${fwcmd}  add  add allow all from any to any layer2

And ater

# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0
net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=100
net.inet.ip.fw.one_pass=0


net.link.ether.ipfw=1

service ipfw restart

all traffic stops and ssh and I go to the server to change net.link.ether.ipfw=1 to 0


After i see

 ipfw -a show
00100        4         394 allow ip from any to any via lo0
00200        0           0 deny ip from any to 127.0.0.0/8
00300        0           0 deny ip from 127.0.0.0/8 to any
00400     8806           0 allow ip from any to any layer2 mac-type 0x0806
00500     2542      235323 deny ip from any to any MAC any fc:34:97:bd:16:d9
00600  2572071   517705387 nat 1 ip from table(0) to any out via igb2
00700  9749972 11914216133 nat 1 ip from any to any in via igb2
00800 25039509 19952612494 allow ip from any to any
00900        0           0 allow tcp from any to any 80
65535    39252     5439536 deny ip from any to any

ipfw zero
Accounting cleared.
 # ipfw -a show
00100      0         0 allow ip from any to any via lo0
00200      0         0 deny ip from any to 127.0.0.0/8
00300      0         0 deny ip from 127.0.0.0/8 to any
00400     29         0 allow ip from any to any layer2 mac-type 0x0806
00500      0         0 deny ip from any to any MAC any fc:34:97:bd:16:d9
00600  20931   6834380 nat 1 ip from table(0) to any out via igb2
00700  62003  77619486 nat 1 ip from any to any in via igb2
00800 177019 143789809 allow ip from any to any
00900      0         0 allow tcp from any to any 80
65535  39252   5439536 deny ip from any to any

 

[wally]

All ip address of local network are static. The machine is gateway of this local network. I assigne ipv4 ot this network

From this I understand that you are using the machine as a router.
In which case I would not recommend attempting to filter at layer 2 (switching) when there is something going on you cannot understand at layer 3 IP
Static networks are normally configured for a more secure environment, as they permit a whitelist policy at layer 3. ie you specifically permit what traffic can travel about your subnet using specific IP's. If I were you I would switch to DHCP

A well configured Static Network will not have free IPv4 addresses which can be used to gain access to the network, anyone changing their IP address would cause a conflict and highlight the security issues.
Mac addresses can be spoofed and or changed and you would likely have the same issue with the User changing these.
Routers run ACL's NOT Firewalls and your ACL (In my opinon) needs some work.

Hope you get is sorted - there are some interesting ideas here.
Regards

 

[kerogaz]

Hooray!!!You know, I deny MAC of my computer and it gets banned without net.link.ether.ipfw=1 !!!
Next lines works and counters show filtered packages,

${fwcmd}  add  allow ip from any to any layer2 mac-type 0x0806
${fwcmd}  add  deny ip from any to any MAC any fc:34:97:bd:16:d9
${fwcmd}  add  add allow all from any to any layer2

only when net.link.ether.ipfw=0 !!!! Otherwise all traffic stops!!!

In general, thanks to everyone, I’ll filter like this

 

[smithi]

whatever you say:

#MAC
${fwcmd}  add  allow ip from any to any layer2 mac-type 0x0806
${fwcmd}  add  deny ip from any to any MAC any fc:34:97:bd:16:d9
${fwcmd}  add  add allow all from any to any layer2

Yes that's what I suggested, except you put 'add add' which I'd expect ipfw to complain about, and fail to add the rule.

And ater

# Uncomment this to...
net.inet.ip.fw.one_pass=0
...
net.link.ether.ipfw=1

service ipfw restart

all traffic stops and ssh and I go to the server to change net.link.ether.ipfw=1 to 0

If that's what you did, how come the supposedly added rule

allow all from any to any layer2

is NOT shown below, after your rule 500 and before nat rules?

After i see

 ipfw -a show
00100        4         394 allow ip from any to any via lo0
00200        0           0 deny ip from any to 127.0.0.0/8
00300        0           0 deny ip from 127.0.0.0/8 to any
00400     8806           0 allow ip from any to any layer2 mac-type 0x0806
00500     2542      235323 deny ip from any to any MAC any fc:34:97:bd:16:d9
00600  2572071   517705387 nat 1 ip from table(0) to any out via igb2
00700  9749972 11914216133 nat 1 ip from any to any in via igb2
00800 25039509 19952612494 allow ip from any to any
00900        0           0 allow tcp from any to any 80
65535    39252     5439536 deny ip from any to any

Doesn't your complete script flush rules first? It seems not.

It's often helpful to use
ipfw -t show
to see latest timestamps.
(-a is implied with 'show')

ipfw zero
Accounting cleared.
 # ipfw -a show
00100      0         0 allow ip from any to any via lo0
00200      0         0 deny ip from any to 127.0.0.0/8
00300      0         0 deny ip from 127.0.0.0/8 to any
00400     29         0 allow ip from any to any layer2 mac-type 0x0806
00500      0         0 deny ip from any to any MAC any fc:34:97:bd:16:d9
00600  20931   6834380 nat 1 ip from table(0) to any out via igb2
00700  62003  77619486 nat 1 ip from any to any in via igb2
00800 177019 143789809 allow ip from any to any
00900      0         0 allow tcp from any to any 80
65535  39252   5439536 deny ip from any to any

Again, no allow all layer2 rule, still invoking nat on 'ip' aka all, and some non-nat rules were NOT zeroed, which is suss.

I'm done; waste of time if you won't even notice a specifically added rule has gone missing.

 

[kerogaz]

Yes that's what I suggested, except you put 'add add' which I'd expect ipfw to complain about, and fail to add the rule.



If that's what you did, how come the supposedly added rule

allow all from any to any layer2

is NOT shown below, after your rule 500 and before nat rules?



Doesn't your complete script flush rules first? It seems not.

It's often helpful to use
ipfw -t show
to see latest timestamps.
(-a is implied with 'show')



Again, no allow all layer2 rule, still invoking nat on 'ip' aka all, and some non-nat rules were NOT zeroed, which is suss.

I'm done; waste of time if you won't even notice a specifically added rule has gone missing.

ipfw -t show
00100    0      0                          allow ip from any to any via lo0
00200    0      0                          deny ip from any to 127.0.0.0/8
00300    0      0                          deny ip from 127.0.0.0/8 to any
00400  415      0 Wed Sep 20 23:10:08 2023 allow ip from any to any layer2 mac-type 0x0806
00500   11    796 Wed Sep 20 23:09:53 2023 deny ip from any to any MAC any 00:e0:81:d5:78:f0
00600 3983 677191 Wed Sep 20 23:10:08 2023 allow ip from any to any layer2
00700    0      0                          nat 1 ip from table(0) to any out via igb2
00800    0      0                          nat 1 ip from any to any in via igb2
65535   60  24808 Wed Sep 20 23:09:11 2023 deny ip from any to any

That's all well and good, but when I deny MAC the line before 65535 disappears.Will this have any negative consequences?

ipfw -t show
00100    0      0                          allow ip from any to any via lo0
00200    0      0                          deny ip from any to 127.0.0.0/8
00300    0      0                          deny ip from 127.0.0.0/8 to any
00400  334      0 Wed Sep 20 23:20:53 2023 allow ip from any to any layer2 mac-type 0x0806
00500 2452 443448 Wed Sep 20 23:20:53 2023 allow ip from any to any layer2
00600    0      0                          nat 1 ip from table(0) to any out via igb2
00700    0      0                          nat 1 ip from any to any in via igb2
00800    0      0                          allow ip from any to any
65535   63  25143 Wed Sep 20 23:20:07 2023 deny ip from any to any

 

[kerogaz]

I have changed for the better. MAC filtering stopped for no reason at net.link.ether.ipfw=0 but started at net.link.ether.ipfw=1 and the entire network does not stop as before. Maybe this is the result of a system upgrade

 

[kerogaz]

There is only one inconvenience. If you comment out the ban of MAC in the rules and comment the line #net.link.ether.ipfw= 1 than restart IPFW after some time (sometimes after half an hour) all traffic stops and it is restored only after the system is rebooted.And if you work far away in SSH,then this means you need to go to the server...

 

[smithi]

There is only one inconvenience. If you comment out the ban of MAC in the rules and comment the line #net.link.ether.ipfw= 1 than restart IPFW after some time (sometimes after half an hour) all traffic stops

Commenting out that line in /etc/sysctl.conf is not the same as setting that variable to 0. Without rebooting it will retain its current value, unless your script specifically runs sysctl net.link.ether.fw=0

and it is restored only after the system is rebooted.And if you work far away in SSH,then this means you need to go to the server...

I thought you said you had it working? You know by now that net.link.ether.fw must be set to 1 for ipfw to be able to see and filter layer2 packets, don't you?

Perhaps some variety of Linux would suit your style better?

 

[kerogaz]

Commenting out that line in /etc/sysctl.conf is not the same as setting that variable to 0. Without rebooting it will retain its current value, unless your script specifically runs sysctl net.link.ether.fw=0



I thought you said you had it working? You know by now that net.link.ether.fw must be set to 1 for ipfw to be able to see and filter layer2 packets, don't you?

Perhaps some variety of Linux would suit your style better?

Iptables or nftables suits my style better than the Linux variety (Do it in one motion in command line with root rights: iptables -I INPUT -m mac --mac-source 00:22:66:B4:44:3A -j DROP - and works immediately without any hassle with layers) But for more than 10 years freebsd has been installed on the server and therefore I have to put up with ipfw Overall FreeBSD is a very reliable system and easy to administer. But why such a bulky and inconvenient to use IPFW was built in , is unclear