Randy Millis (Lists acct.) wrote:
> On Fri, 22 Jun 2001, Reckhard, Tobias wrote:
>
>> However, even in that case you can always
>> download the tarballs, compile and install them yourself.
>
> That sounds like hours of work though.:-)
Can be, but I think the point was that they aren't mutually exclusive,
both options always exist. Some packages aren't distributed as RPM's
for various reasons.
Also look at the -t argument to rpm -(i|U|F). =)
> Not sure I'd know where to begin
> either. And there is always the question of what RPMs are safe to
> remove. How would one know that?
Part of the reason for having a package management system in the first
place is to keep you from yanking dependencies out from under a
component that you actually need. For example, on my desktop here:
[mjinks@titan mjinks]$ sudo rpm -e glibc
error: removing these packages would break dependencies:
glibc >= 2.0.5-5 is needed by timeconfig-3.0.12-2
glibc >= 2.1 is needed by authconfig-4.0.16-4
glibc >= 2.2 is needed by mysql-3.23.32-1.7
glibc = 2.2 is needed by glibc-devel-2.2-12
glibc is needed by dsniff-2.3-2
glibc is needed by libnet-1.0.1b-3
glibc is needed by libnids-1.16-1
glibc >= 2.1.92 is needed by rpm-4.0.2-7x
[and so forth...]
That said, you probably don't want to just run around yanking packages
at random. rpm -qa will list all the packages on your box, rpm -qi
<package-title> will give you some info on what the package does if you
don't know, and there are all sorts of other RPM tricks for more subtle
situations.
> Now 6.2 or 7.1?
>
> - 6.2 is older (may be bad), but there may be more known issues with it
> than something brand new (may be good)
> - 7.1 has many fixes over 6.2 (may be good), but there are also new bugs
> introduced in a new version (may be bad). So what is the most logical
> choice? Or is my logic flawed???? :-)
You could generate the same conundrum with respect to security patches:
some of them might introduce new bugs, oh no! I like to default to the
latest practical choice unless there's a clear and compelling reason not to.
In the case of Red Hat, 7.1 is the first version that uses kernel 2.4 by
default (getting 2.4 onto RH6.2 can be a real pain, even with updates
applied) and IPtables seems to be a pretty clear win over previous
firewalling methods under Linux. Much of the "new in this release"
stuff that I'm aware of in the 7.x series of Red Hat has to do with
parts of the system that you shouldn't be using on a firewall anyway,
like groovy GUI environments, newest PostgreSQL, and so forth.
I believe (may recall incorrectly) that 7.0 was the first Red Hat to
ship with crypto by default (ssh, ssl, etc.) as well as snort. All nice
to have on a firewall.
>>> - Is there an easy and or more effective way to way to upgrade Redhat rpms
>>
>
>> I suppose it's the easiest way and it'll help you avoid circling
>> cross-dependencies (RPM A needs RPM B needs RPM A...) that I've seen with
>> RedHat RPMs.
>
>
> Yes, this is SOOOOO frustrating!
As someone else has already mentioned, the A->B->A problem is fixable by
putting all relevant packages on the same (-i|-U|-F) command line.
>>> - What's the are some of the best ways to set up a VPN and what are some
>>
>
>> Well, FreeS/WAN is the predominant IPSec implementation on Linux. There is
>> also a PPTP server, but that protocol is not viewed too highly by many. Note
>> that IPSec has problems with NAT.
>
>
> Will check it out. Why the dim view on PPTP?
My understanding is that the protocol itself isn't so bad (from a
security standpoint at least -- practicality and scalability will
probably be better in the long run with IPSec, er, IPv6); rather, all
implementations from Microsoft have been flawed.
See http://www.counterpane.com/pptp.html
> I had heard that IPSEC fails over NAT. Why is that?
It's not exactly like that; if your IPSec router is also your NAT gate,
everything is fine; problems come up when you want to put an IPSec peer
behind a NAT barrier, since IPSec relies on knowing the real address of
its peer in order to route. Rewrite the IP header, and that won't work.
>> A VPN basically extends your network. You can transport anything TCP/IP
>> over a VPN, so yes, you can do NetBIOS over TCP/IP and NFS across a VPN,
>> if you want to.
>
>
> But, **do** I want to? Are there pros and cons to doing allowing NFS and
> SMB this way? Is there a better way?
VPN connectivity (generally) involves trusting the remote network as
much as you trust your local LAN. File sharing services are touchy for
the same reason that they're useful, because they allow easy read-write
access to data on your system. There's nothing "wrong" about NFS/SMB
over a VPN as long as you remember to extend the concerns inherent in
each service to include the two together.
Say you have a colleague who runs an insecure LAN at home; if you let
that colleague mount $HOME from home, you also grant the same privilege
to any intruders on that colleague's LAN. So be careful, that's all.
If you must provide remote NFS and/or SMB, you might as well encrypt it.
Recent releases of Samba do include an SSL option, there may be ways
to do something similar with NFS but I don't know if the issues get
hairy when you use UDP (NFS) instead of TCP (SMB). Or you can just wrap
all your traffic in a VPN and be reasonably assured that no matter what
the client does, nobody between here and there will sniff the traffic.
Also note that all the same firewalling tricks you do at your border
router already (NAT, packet filtering, traffic analysis, etc.) should be
available in the system you use for IPSec. So if you want to be choosy
about the protocols you permit from off-site, you should be able to.
>>> - I have only set up a previous NAT box and the current Bastille firewall
>>> using an external IP and a private internal network. I want to set up a
>>> firewall for a lab that contains machines with external IP addresses. How
>>> would I do that or am I better off to redo the internal network with a
>>> private IP range? What are the security implications of both alternatives?
<snip>
> What I don't understand is how I set up a firewall to protect a collection
> of hosts that are on the public internet now and have public addresses.
One way is to put those hosts on a private LAN with RFC1918
(non-routable) addresses -- either the same private LAN you have now, or
a different one, the fabled "DMZ network" -- and then use your
firewall's NAT implementation to forward ports for public services onto
the appropriate nets/hosts. IPTables can do this.
> Do I just physical stick the firewall between Public and Private
> networks- physically isolating them? How does the traffic get passed back
> and forth?
>
> I guess NAT works like a router between Public and Private networks,
> huh?
You've got the idea.
> If I just seperate (PHYSICALLY) publicly addressed hosts, then
> do I need to set up a routing deamon to pass the traffic between
> Public and Private physical networks (but public addresses)?
Nope.
Suppose you have a web server and a mail server, and both need to take
inbound connections. Say you give the mail server the address 10.0.0.1,
and the web server 10.0.0.2.
On the firewall we have one public IP address, call it 1.2.3.4. Using
your NAT implementation of choice, you could tell the firewall to take
connections from [ANYWHERE] which are bound for 1.2.3.4:80, and re-route
them to 10.0.0.2:80; to take connections from [ANYWHERE] bound for
1.2.3.4:25 and reroute to 10.0.0.1:25.
You can get a lot more complicated than this (the firewall might have
many addresses, for example, each with its own set of filtering and NAT
rules), but that's the gist. The docs for whichever firewalling tool
you end up using will have specifics on the syntax, but any decent NAT
implementation should be able to do this. IPtables certainly can.
> How do I hide the hosts behind the firewall and sill allow
> them to reach the internet?
If you're still asking that question then you don't quite understand NAT. ;)
> Or should I just set up NAT and renumber them
> all internally? Guess I'd need my own name server for internal use too,
Yup. If you're already using RFC1918 addresses you probably want that
anyhow.
--
~~~Michael Jinks, IB // Technical Entity // Saecos Corporation~~~~
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
