Firewalling revisited...

Henning Rohde hr at our-home.net
Thu Oct 18 08:46:34 PDT 2001


Hi Björn, 
hi everybody else,

Björn Lindberg wrote:
> 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 your IP, he would only be able to crack the
>> router with no important data on it, but he would not get immediately 
>> 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.
> 

Personally I prefer to do this in 2 steps: first log?in?to the router, 
second into the client. 
You've asked for comments, I've told you my thoughts, you're free to do 
what you consider to be best / to implement it on your own taste or 
priorities.

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

Again, you're free how to realize your concept.

> 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.
> 

But he must guess two, hopefulle different, passwords to do the login, 
sorry for not having been unambiguous.

>> 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?
> 

OK, that depends on your concept:
If you put a second machine into your net and start a webserver on it, 
everything is OK after you've altered your routing-scripts:

iptables -t nat -A PREROUTING -i $EXTDEV --dport 80 -j DNAT --to 192.168.1.2
iptables -t nat -A PREROUTING -i $EXTDEV --dport !80 -j DNAT --to192.168.1.1

The case I've been thinking about is, that you were having two clients 
behind your router:
Consider you're surfing at your desktop and your best friend is sitting 
infront of his notebook, both of you compete in finding the bestlooking 
girl in the whole internet!     ;-)

If you would do this without customizing your scripts
$IPTABLES -t nat -A PREROUTING -i $EXTDEV -j DNAT --to 192.168.1.1
would take precedence before the automatical 'back-route' you refered to, 
because it affects the packet _before_ routing.
Because of this rule any data coming-in into the external interface of your 
router would be sent to your desktop, your mate might try to start a 
connection to any a website from his laptop, but he would not see any image.

BTW, in one of my previous postings I asked you to verify your concept, did 
it prove to work as you want it to?
E.g., ssh from school to your internal client, X11-forward, X11-tunnel and 
so on...
Do me a please and send me the output of a 'traceroute -v' to your internal 
client, started on some box at school, I'm interested in the responses your 
router and your client send.


Have a nice day,

        Henning

-- 
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