Using the latest version of Kamikaze (8.09) on a WRT54G v.3 I'm trying to allow only one mac address to ssh into the router from WAN. If possible, I'd like to be able to do it over the webif, as I've been using that. But if necessary, I can use CLI to do so. I just haven't really learned much on working with the /etc/config/firewall.

So to sum it up for my overall use of the router is:
a)standard lan/wlan usage for laptops/desktops;
b)ssh into the router as needed from LAN for config, etc;
c)ssh into the router from one individual laptop from any internet connection, block all other attempts(drop or reject, doesnt matter);
d)forward port xxx from the router to one of the desktops for ssh tunneling- need remote access to files/programs on that desktop.

c) is the only part I need to work on now.

So I think it's possible, but I'm exactly sure how to go about it. Thanks in advance.

(Last edited by jourosis on 29 Apr 2009, 05:09)

this is was public/private key pairs are for
look for the authorized_keys file in /etc/dropbear

and disable password auth

(Last edited by zorxd on 29 Apr 2009, 05:51)

jourosis,

The MAC address is something that can attributed to the local clients, as it works on the Data Link layer (2nd level) of OSI model. And routable behavoir of internetworking is archived starting only from Network layer (3rd level).

zorxd:
Thanks for the info about ssh keys, but what I was aiming for was to only allow only one computer the chance of even using a key.

nas- I appreciate the info. Is there any possible way to rehash what you said in layman's terms? (I know if I can't understand that, I probably shouldn't be delving this deep into security, but I'm curious). Thanks.

Even if it worked, you can fake a mac address easily anyways so a key is more secure. Normally a random private key will be specific to only one host. If it's the only allowed key then only this host will be able to connect.

I understand how secure private keys would be. (using them currently). Most would call what I want to do very unnecessary, but it would just be another layer. It's in addition to using a non-standard port for SSH.

(Last edited by jourosis on 29 Apr 2009, 20:17)

But do you understand that the MAC address that your router will see will always be the same : the address of your DSL or cable modem.

If you care about security you could install denyhost to ban people trying to connect to your router. But I think it's in perl so you would have to install perl as well.

(Last edited by zorxd on 29 Apr 2009, 20:20)

Which is what nas was telling me I think? Thanks for the rehash in simpletext. It was what I needed

Does this mean that the firewall rules that can involve source MAC addresses are only useable for LAN/outgoing connections?

(Last edited by jourosis on 29 Apr 2009, 20:20)

It only works for devices on the same ethernet network as your router, but in all directions. When a packet gets routed, it's made at the IP level (layer 3), and the MAC adress is replaced with the MAC address of the router.

So if you have

3 computers<->router<->modem

This is two ethernet networks (lan and wan on your router)

If you send an IP packet from computer A to computer B, or from a computer to your router, the source MAC will be the original one. But if you send a packet from a computer to your modem, your modem will see that the ethernet packet (layer 2) is coming from your router instead of your computer because it's on a different network.

So you can filter/shape internet traffic on the LAN side by looking at :

- the source MAC addr on your lan (for outgoing traffic). Destination MAC addr will always be your router

- the destination MAC addr (for incoming traffic). Source MAC addr will always be your router

On the WAN side, there is only two devices (router and modem) so MAC address filtering/shaping is useless.
I think that you can't even filter/shape local traffic on your LAN (from one computer to an other) because it pass trough the switch but not trough the router.

(Last edited by zorxd on 29 Apr 2009, 20:42)

Interesting...Thanks for all the info zorxd!.