Axalon Bloodstone wrote:
>
> On Sat, 21 Aug 1999, Steve Fox wrote:
>
> > >
> > > 5. I haven't found any package that will masquerade other LAN machines onto
> > > the internet. Supposedly it can be done through ipchains scripts, but
> > > I haven't made any work yet. I did use PaNTs which is supposed to work for
> > > RedHat 6 but I can't get anything through it on port 80 (web access).
> >
> > echo 1> /proc/sys/net/ipv4/conf/eth0/forwarding
> ipchains -P forward DENY
> > ipchains -I forward -j MASQ -s 192.168.0.0/16 -i eth0 -d 0/0
> > ipchains -I input -j DENY -s 192.168.0.0/16 -i ! eth0 -d 0/0 -l
> >
I haven't played with IP chains yet, but I get the notion that I may be
using it to put a bigger choke mechanism on a web server box. Could you
verify that my reading of the ipchains rules are correct?
By default, deny all forwarding. Allow forwarding of packets sourced on
192.168. and received on eth0. Deny forwarding of 192.168. packets that
did not get received on eth0.
Is that correct?
I've got the following setup: an ISDN connection that's terminated at a
Cisco router with 2 ethernet connections running their PIX firewall
software. On one ether port (192.168.4.x), is our "Internet" network.
It currently houses one machine which acts as the web/email server for
outside connections. Inside connections use that machine as their soul
gateway to the outside world (junkbuster and squid along with pop3 and
smtp services). The other ether port (192.168.3.x) connects to our
internal network.
I'd like to put a bigger limit on the kinds of things that the webserver
will allow to be sent into the internal network. We need to allow the
squid and junkbuster conversations in, and I also need to be able to
talk to the machine via telnet from the internal connection.
I'm not worried (much) about people being able to attack the internal
network from the Internet, since they're all private IP net addresses
that get nowhere when used on the Internet. However, if someone is able
to break into the web box, they can see the internal network and talk to
it from there. I'd prefer that not to be possible.
Any ideas?
--
Steve Philp
Network Administrator
Advance Packaging Corp.
[EMAIL PROTECTED]
