Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPChains question (SOLVED)



I honestly don't understand the issue.  The masquerader should not make
anything more valuable than if the target machine was itself directly on
the public network, although -- depending upon how the masquerade is done
-- the IP address seen by the target machine would be that of the
masquerader rather than of the actual source machine.  An outside attacker
could, for example, port scan the masquerader and find out what ports are
in use for masquerading or anything else, but it would be hard to take
over these ports without knowing quite a lot more about the instantaneous
status of the masquerader adn what its ports really were reflecting.

There are two fundamentally different masquerading schemes, one using a
kind of pass-through scenario and another using a more formalized Network
Address Translation (NAT) scenario.  It stands to reason that the dynamic
allocation of resources inherent in a pass-through scheme would lead to
generally greater security vulnerability, but it is not immediately clear
to me how that is specifically the case.  There are some peripheral
issues, such as what happens if you elect to masquerade disconnected mode
packets, such as UDP or ICMP datagrams.

-- Mike


On 2000-05-15 at 12:11 -0400, Christoph Doerbeck A242369 wrote:

> I would agree that SSH is designed and engineered to be "safe", but my
> original point was that by changing the firewall's IPCHAIN timeouts, you
> are setting global values, not just those for SSH.  This could make
> other port services masquaraded on the FW more vulnerable (T/F)?


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org