Firewalling revisited...

Björn Lindberg d95-bli at nada.kth.se
Thu Oct 18 00:37:22 PDT 2001


Henning Rohde wrote:
 
> In your current setup you DNAT any incoming request to your internal
> client. Doing it this way, you do not use the highly apprechiated feature
> the conventional concept of a masquerading router has:
> 
> The conventional concept means, that the masqerading router does only SNAT
> outgoing requests, incoming requests are handelt by itself.
> If some cracker attacked his IP, he would only be able to crack the
> router with no important data on it, but he would not get imeedately full
> access to your documents. To access your documents he would need to crack
> your internal machine as well.
> 
> In your current concept a cracker who ssh'ed to your IP would get the
> login-prompt of your internal box. Cracking ssh seems quite unlikely,
> but to login is not so difficult if you happen to have accounts with
> weak passwords.

I agree. The reason I do it this way is because I want to be able to ssh
into my internal box from the outside, eg from school. I also want to be
able to run X clients through that ssh-tunnel.

That is also partly why I divide it in two scripts. The nat table now
exclusively handles routing, and the filter table handles firewalling.

On the other hand, I really don't see the difference though. If I
instead allow ssh-connections to my router, and then from my router to
my internal box, the cracker only has to log in twice. I mean, if he
cracks my router, he would just have to log in to my internal box.

> The other disadvantage, you concept has in my eyes, is that it allows
> only one client: What are you going to do if you'd like to put a second
> machine into your internal network, e.g., a notebook.
> Any connection initiated from the notebook would correctly be routed into
> the internet, but the answers would be redirected to 192.168.1.1,
> wouldn't they?

Well, yes and no. As I understand it, the nat table routes the first
packet of a connection, and then automatically routes the rest of the
packets in that connection accordingly. So, let's say I had another
internal box, which I run a web server on. I would be able to make
external connections from that box, and that whole session would get
routed properly, or at least that's my understanding. Then to be able to
visit my web server from the outside, I would route port 80 the same way
I now route port 22, to the internal web server box.

What do you think?


Björn
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message



More information about the blfs-support mailing list