hr at our-home.net
Thu Oct 18 08:46:34 PDT 2001
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
> 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
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,
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