[gentoo-user] OT: iptables mac filtering

[gentoo-user] OT: iptables mac filtering

[James]

Hello,

Continuing my quest for iptables enlightenment....I have a question
about 'mac address' syntax. All options for mac and arp have been compiled
into a gentoo-hardened kernel.

I'm using variations of this  syntax in my script.

# Rule to only allow ssh by MAC address 
iptables -A INPUT -i eth0 -p tcp -m mac --mac-source xx:xx:xx:xx:xx:xx \
   --source-port 1024:65535 -d <ip.address> --dport 22 -j ACCEPT

Where  the mac address xx...xx is the system allowed in, via ssh
and the ip.address is that of the destination (/24 based) host
The rule works well  when packets have to traverse
a firewall/router as mac addresses do not get propagated (I think).

However, when I use  similar syntax to prevent a system on the same
local (ethernet) segment from being able to ssh into a local system, 
it does prevent ssh access, as expected. Granted MAC addresses
can be foiled, especially on the same segment, but how do I make this
rule work?: On a local segemnt how would I modify the syntax so 
that only a select machine (maybe IP + MAC) could access a host,
running iptables, via ssh?

thoughts and ideas are most welcome.

James





-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] OT: iptables mac filtering

[Daniel Iliev]

James wrote:
> Hello,
>
> Continuing my quest for iptables enlightenment....I have a question
> about 'mac address' syntax. All options for mac and arp have been compiled
> into a gentoo-hardened kernel.
>
> I'm using variations of this  syntax in my script.
>
> # Rule to only allow ssh by MAC address 
> iptables -A INPUT -i eth0 -p tcp -m mac --mac-source xx:xx:xx:xx:xx:xx \
>    --source-port 1024:65535 -d <ip.address> --dport 22 -j ACCEPT
>
> Where  the mac address xx...xx is the system allowed in, via ssh
> and the ip.address is that of the destination (/24 based) host
> The rule works well  when packets have to traverse
> a firewall/router as mac addresses do not get propagated (I think).
>
> However, when I use  similar syntax to prevent a system on the same
> local (ethernet) segment from being able to ssh into a local system, 
> it does prevent ssh access, as expected. Granted MAC addresses
> can be foiled, especially on the same segment, but how do I make this
> rule work?: On a local segemnt how would I modify the syntax so 
> that only a select machine (maybe IP + MAC) could access a host,
> running iptables, via ssh?
>
> thoughts and ideas are most welcome.
>
> James
>
>
>
>
>
>   

The rule you give in the example seems correct to me. I can imagine 2
reasons because of which its not working for you.
First this rule ends  with "ACCEPT" - it allows, does not forbid access.
The second reason is that there could be some other rules which take
precedence before a packet meets the rule in question and it obeys those
preceding rules.

-- 
Best regards,
Daniel


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] OT: iptables mac filtering

[Hans-Werner Hilse]

Hi,

On Wed, 9 Aug 2006 18:54:45 +0000 (UTC)
James <wireless@tampabay.rr.com> wrote:

> Where  the mac address xx...xx is the system allowed in, via ssh
> and the ip.address is that of the destination (/24 based) host
> The rule works well  when packets have to traverse
> a firewall/router as mac addresses do not get propagated (I think).

No, of course not. The incoming packet will have the MAC of the router
instead. Only ethernet frames carry a MAC, so there's no MAC in IP
tunnels, too.

> However, when I use  similar syntax to prevent a system on the same
> local (ethernet) segment from being able to ssh into a local system, 
> it does prevent ssh access, as expected. Granted MAC addresses
> can be foiled, especially on the same segment, but how do I make this
> rule work?: On a local segemnt how would I modify the syntax so 
> that only a select machine (maybe IP + MAC) could access a host,
> running iptables, via ssh?

Hm, by adding "-s <source IP>"? And of course, you need to change
INPUT's policy to REJECT or DROP, using iptables -P INPUT DROP. Note
that you probably want some rules allowing traffic local on that
machine, so also allow packets coming from "lo".

But you already mentioned it: There's not much point in blocking access
this way since MAC addresses can as well be spoofed as IP addresses.
Are you suffering from DOS attacks on your SSH server?

-hwh
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: OT: iptables mac filtering

[Richard Fish]

On 8/10/06, James <wireless@tampabay.rr.com> wrote:
> I need a rule on the 3 (nic) interface firewall so that only
> ssh from the LAN is allowed to the firewall or sytems (web
> server, mail dns) in the DMZ. Only one static ip is routable
> to this site. SSH from the outside should be completely blocked.
>
> Any ideas, examples or thoughts?

Just I guess as I haven't tried this:

---
IF_INTERNET=eth0
IF_DMZ=eth1
IF_LAN=eth2

# allow ssh connections from LAN to us
iptables -A INPUT -i $IF_LAN -p tcp --dport 22 -j ACCEPT
# allow routing of ssh connections from LAN to DMZ hosts
iptables -A FORWARD -i $IF_LAN -o $IF_DMZ -p tcp --dport 22 -j ACCEPT
# deny all other ssh connections
iptables -A INPUT -p tcp --dport 22 -j DROP
iptables -A FORWARD -p tcp --dport 22 -j DROP
---

HTH,
-Richard
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: OT: iptables mac filtering

[James]

Richard Fish <bigfish <at> asmallpond.org> writes:

> > I need a rule on the 3 (nic) interface firewall so that only
> > ssh from the LAN is allowed to the firewall or sytems (web
> > server, mail dns) in the DMZ. Only one static ip is routable
> > to this site. SSH from the outside should be completely blocked.

> # allow ssh connections from LAN to us
> iptables -A INPUT -i $IF_LAN -p tcp --dport 22 -j ACCEPT
> # allow routing of ssh connections from LAN to DMZ hosts
> iptables -A FORWARD -i $IF_LAN -o $IF_DMZ -p tcp --dport 22 -j ACCEPT
> # deny all other ssh connections
> iptables -A INPUT -p tcp --dport 22 -j DROP
> iptables -A FORWARD -p tcp --dport 22 -j DROP


Richard,

These rules worked like a charm. I had something similar, but had
the syntax messed up.
thx.

Now I have ONE big problem.
Spammers. (I think).

Running a sniffer between my firewall and the cable box's
ethernet (single static IP),
I see:

hackIP   myIP  TCP   smtp > 55634 (RST,ACK) Seq=0 ACK=1 WIN=0 LEN=0 MSS=1460
myIP hackIP    TCP   55634 > smtp  (SYN) Seq=0 ACK=1 WIN=0 LEN=0
hackIP   myIP  TCP   smtp > 55634 (RST,ACK) Seq=0 ACK=1 WIN=0 LEN=0 MSS=1460
myIP hackIP    TCP   55634 > smtp  (SYN) Seq=0 ACK=1 WIN=0 LEN=0
hackIP   myIP  TCP   smtp > 55634 (RST,ACK) Seq=0 ACK=1 WIN=0 LEN=0 MSS=1460
myIP hackIP    TCP   55634 > smtp  (SYN) Seq=0 ACK=1 WIN=0 LEN=0

Last night I saw this for a while and then a storm of smtp traffic.
This site does not even run a mail server and all systems where 
shutdown except for the firewall and the sniffer.

This explains why this site is listed as a spammer site...
Somebody has been reflecting email off of this site for some time,
I suspect.

Got any idea for a (iptables) syntax to stop this?   Do I need to
reinstall the sysetm (gentoo-hardened firewall)???????

thoughts and ideas are welcome.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: OT: iptables mac filtering

[Richard Fish]

On 8/11/06, James <wireless@tampabay.rr.com> wrote:
> myIP hackIP    TCP   55634 > smtp  (SYN) Seq=0 ACK=1 WIN=0 LEN=0
> hackIP   myIP  TCP   smtp > 55634 (RST,ACK) Seq=0 ACK=1 WIN=0 LEN=0 MSS=1460

Assuming you haven't mixed up the myIP and hackIP parts, this means
something on *your* system/network is trying to contact an smtp server
on what you are calling hackIP.  TCP/IP connections are initiated with
a SYN packet.  If they are accepted, you get a SYN,ACK packet back.
If they are rejected, you get a RST,ACK back.

Running 'host <hackIP>' might prove enlightening.

-Richard
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: OT: iptables mac filtering

[James]

Richard Fish <bigfish <at> asmallpond.org> writes:


> On 8/11/06, James <wireless <at> tampabay.rr.com> wrote:
> > myIP hackIP    TCP   55634 > smtp  (SYN) Seq=0 ACK=1 WIN=0 LEN=0
> > hackIP   myIP  TCP   smtp > 55634 (RST,ACK) Seq=0 ACK=1 WIN=0 LEN=0 MSS=1460

> Assuming you haven't mixed up the myIP and hackIP parts, this means
> something on *your* system/network is trying to contact an smtp server
> on what you are calling hackIP.  TCP/IP connections are initiated with
> a SYN packet.  If they are accepted, you get a SYN,ACK packet back.
> If they are rejected, you get a RST,ACK back.

Sorry, I transposed the entries. From Wireshark I took my time to copy 
more accurately
:
Source   dest.        proto  info
24.199.244.157   myIP  TCP   55634 > smtp  (SYN) Seq=0 Len=0 MSS=1460
myIP   24.199.244.157  TCP   smtp > 55634  (RST,ACK) Seq=0 Ack=1 Win=0 Len=0

> Running 'host <hackIP>' might prove enlightening.

# host 24.199.244.157
157.244.199.24.in-addr.arpa domain name pointer
rrcs-24-199-244-157.midsouth.biz.rr.com.


Remember, the entire network, except the firewall was physically
disconnected.  I did not save the Wireshark session at that time,

The lines above seen today, look very similar to the 
packet storm the session last night.....

However, I'll try to save it, the next time it explodes. The 
lines above are merely suspicious to me.
It does look like part of RoadRunner, but last night the 
spam was in high gear, until I shut down the link....

thoughts?


James



-- 
gentoo-user@gentoo.org mailing list