iptables block mac

is it possible to block ALL MAC adresses and then have a list of
approved macs? yes? how?

Re: iptables block mac

MDK wrote:
> is it possible to block ALL MAC adresses and then have a list of
> approved macs? yes? how?

Many layer II switches are capable of this. Not quite sure what you want
to achive, though. It is trivially simple to change the MAC addres of a NIC.

How, read your switch documentation!

Bogwitch.

Re: iptables block mac

Bogwitch skrev:
> MDK wrote:
>> is it possible to block ALL MAC adresses and then have a list of
>> approved macs? yes? how?
>
> Many layer II switches are capable of this. Not quite sure what you want
> to achive, though. It is trivially simple to change the MAC addres of a
> NIC.
>
> How, read your switch documentation!
>
> Bogwitch.

only ppl with approved MACs can go through the router and use the net.
all other MACs should be blocked.

Why? Because ppl give us their MAC and we open it up. Simple as that.
(Shared College Network)

Re: iptables block mac

MDK wrote:
> Bogwitch skrev:
>> MDK wrote:
>>> is it possible to block ALL MAC adresses and then have a list of
>>> approved macs? yes? how?
>>
>> Many layer II switches are capable of this. Not quite sure what you
>> want to achive, though. It is trivially simple to change the MAC
>> addres of a NIC.
>>
>> How, read your switch documentation!
>>
>> Bogwitch.
>
> only ppl with approved MACs can go through the router and use the net.
> all other MACs should be blocked.
>
> Why? Because ppl give us their MAC and we open it up. Simple as that.
> (Shared College Network)

Wireshark. Grab a MAC address. Set _MY_ MAC address to the grabbed MAC
address, I can get out on the router. Simple as that.

Bogwitch.

Re: iptables block mac

Bogwitch skrev:
> MDK wrote:
>> Bogwitch skrev:
>>> MDK wrote:
>>>> is it possible to block ALL MAC adresses and then have a list of
>>>> approved macs? yes? how?
>>>
>>> Many layer II switches are capable of this. Not quite sure what you
>>> want to achive, though. It is trivially simple to change the MAC
>>> addres of a NIC.
>>>
>>> How, read your switch documentation!
>>>
>>> Bogwitch.
>>
>> only ppl with approved MACs can go through the router and use the net.
>> all other MACs should be blocked.
>>
>> Why? Because ppl give us their MAC and we open it up. Simple as that.
>> (Shared College Network)
>
> Wireshark. Grab a MAC address. Set _MY_ MAC address to the grabbed MAC
> address, I can get out on the router. Simple as that.
>
> Bogwitch.

This isn't the ONLY setting preventing people from getting out through
the router, it is ONE of them.

You give lots of suggestions how to break it, what about some
suggestions on how to set it up?

Re: iptables block mac

On Sun, 11 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
<45cea5ca$0$45851$edfadb0f@dread16.news.tele.dk>, MDK wrote:

>Bogwitch skrev:
>> MDK wrote:
>>> Bogwitch skrev:
>>>> MDK wrote:
>>>>> is it possible to block ALL MAC adresses and then have a list of
>>>>> approved macs? yes? how?

Possible? Certainly. See http://www.netfilter.org/documentation/HOWTO/

[TXT] netfilter-extensions-HOWTO.txt 24-Dec-2006 16:06 79K
[TXT] netfilter-hacking-HOWTO.txt 24-Dec-2006 16:06 84K
[TXT] packet-filtering-HOWTO.txt 24-Dec-2006 16:06 52K

Those documents (and there are four more covering other aspects) are
older than the timestamp implies, but highly useful.

>>>> It is trivially simple to change the MAC addres of a NIC.

Agreed

>>> only ppl with approved MACs can go through the router and use the net.
>>> all other MACs should be blocked.
>>>
>>> Why? Because ppl give us their MAC and we open it up. Simple as that.
>>> (Shared College Network)

Sure hope you people have _written_ and _published_ the rules, and that
everyone knows them. You should also have approval from on high to
throw out any person who violates those rules.

>> Wireshark. Grab a MAC address. Set _MY_ MAC address to the grabbed MAC
>> address, I can get out on the router. Simple as that.

Not quite - two (or more) systems with the same MAC address trying to
shuffle packets at the same time can get very funny. Managed switches
can make it slightly more difficult, though hardly impossible.

>This isn't the ONLY setting preventing people from getting out through
>the router, it is ONE of them.

None the less, it's virtually useless as an access control.

>You give lots of suggestions how to break it, what about some
>suggestions on how to set it up?

Encrypted proxies. Disconnect "unused" network access points so that
non-registered users don't even have physical access. Monitor your mail
server, and seeing that user $FOO only collects mail from a "registered"
box. Also block ALL access from internal hosts through the router to the
world so that they _must_ use the proxies. If you don't know how to
set them up, you may want to hire someone who does.

Old guy

Re: iptables block mac

MDK wrote:
> is it possible to block ALL MAC adresses and then have a list of
> approved macs? yes?

Possible? Yes. It's also utterly pointless and not worth the trouble of
setting up and maintaining it.

> how?

iptables -m mac --help

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: iptables block mac

well how would you block out ppl then? most if not all the users here
are NOT IT geeks and will never be it, they can hardly set their email
servers correctly.

Re: iptables block mac

MDK wrote:
> well how would you block out ppl then? most if not all the users here
> are NOT IT geeks and will never be it, they can hardly set their email
> servers correctly.
>
Old Guy covered it fairly well. Good network and change management to
ensure unused network ports are not used. You can do this with MAC
filtering on a switch but that does not make it good policy to control
access on a router. A good logging encrypted proxy. Obviously, you have
to tell your users you are logging. Any administrative servers should be
completely inaccesible from the rest of the network.
Clear acceptable use policy. Users MUST be made aware of what they can
and can't do on your network. You must make users responsible for their
actions, if not, the network OWNER may be held accountable - it would
depend on the laws in your country.

Don't think for one second that because not many of your users are
technically proficient that you will have no problems. You only need one
technically proficient user to tell the rest of them or one inquisitive
user to do the research. It sounds as though your userbase may be well
versed in research.

Bogwitch.

Re: iptables block mac

On Sun, 11 Feb 2007in the Usenet newsgroup comp.security.firewalls, in article
, Bogwitch wrote:

>MDK wrote:
>> well how would you block out ppl then?

Mainly by policy - but we also disable unused ports on our switches.

>> most if not all the users here are NOT IT geeks and will never be
>> it, they can hardly set their email servers correctly.

Web Results 1 - 10 of about 246 for script-kiddy-HOWTO. (0.53 seconds)

script kiddy howto
/* This , Like the world is only what you perceive it to be */ Q:"How Do
I Become A Hacker?" A: learn to code , install SunOS , get a SPARC ,
devote the ...
packetstormsecurity.org/unix-humor/script-kiddy-HOWTO - 8k - Cached -

Right.

>Clear acceptable use policy. Users MUST be made aware of what they can
>and can't do on your network. You must make users responsible for their
>actions, if not, the network OWNER may be held accountable - it would
>depend on the laws in your country.

An AUP is the _FIRST_ step, and MUST BE THERE. Please remember that
the Berkeley 'r' commands (rsh, rlogin, rcp, etc.) were developed at a
university and have (effectively) _NO_ security, in an era when the
network was sniffable by anyone, anywhere on the 500 meter long cable.
The reason it wasn't a problem then is that packet sniffers were less
common, and the students knew that if they were caught mucking about,
they lost their computer privileges.

>Don't think for one second that because not many of your users are
>technically proficient that you will have no problems. You only need
>one technically proficient user to tell the rest of them or one
>inquisitive user to do the research.

One must remember that the average skript kiddie has trouble typing
commands with making (funny to watchers) mistakes even using something
as intuitive as the pico editor. But they are following scripts written
by people who know better, and the results do not match the skill of
the klown running the script.

Old guy