So I've been following this thread with some interest since security is always a big concern whenever giving any machine access to the internet. Though, the techinical scope of this discussion is pretty deep and a little beyond my current understanding.
Let me ask questions of you who are fairly expert in this field and maybe you can answer in more simple terms. I'm sure your answers would benefit most of us on the list. I'm using IPChains to do the NAT and firewall functions on my personal Linux server. The server listens on ports 25, 37, 53, 80, 110, and 515 on both interfaces and 139 on the internal interface. The IPChains rules allow incoming connections only to ports 25, 53, and 80 from the external interface. Rules are in place that limit outgoing connections to the common services from the internal clients (which use non-routable static IP's with no port maps), but they have complete freedom with the server's internal interface. The internal network comprises a couple Windows machines that have no special security measures taken upon them other than keeping the Windows software up to date to protect against things like hostile web sites and email. The Windows machines are also running anti-virus software to protect against hostile email attachments. I'm running an old kernel (2.2.18) and an old version of Debian (2.2r7) and security updates stopped about 6 months ago. I am aware of some security flaws in the version of Sendmail and Apache I'm running, but when I get the time, I'll do a Debian version upgrade (and switch to IPTables). I do have security measures enabled in the kernel like rejecting source routed packets and rejecting redirects. Am I doing what is reasonably possible to secure my personal network? Is there something else I should be doing? Am I doing anything wrong other than being behind in my software versions? Thanks, - Craig ----- Original Message ----- From: "Todd A. Jacobs" <[EMAIL PROTECTED]> To: "Robinson, Eric" <[EMAIL PROTECTED]> Cc: "Reno Linux Users Group" <[EMAIL PROTECTED]> Sent: Saturday, March 06, 2004 11:14 AM Subject: RE: [RLUG] NAT as a Security Tool On Fri, 5 Mar 2004, Robinson, Eric wrote: > Fair enough, although this assumes the attacker has already positioned > himself to capture traffic between the source and destination in order > to know what to spoof. This is an incorrect assumption. Given enough time and effort, at least some data will leak about clients behind a NAT device or firewall. In many cases, a simple footprint analysis will suffice to identify potential targets; it doesn't require a man-in-the-middle approach. > point to an entirely different socket. Is that possible? Otherwise, the > attacker would have to know what process he's talking to, and what Again, this is an incorrect assumption. Just like spam, or the Code Red virus, you can inject packets with the assumption that eventually a crafted packet will have an effect *somewhere*, even if it isn't targeted. You're thinking too much about directed traffic; you also need to consider shotgun approaches, such as many worms use. > True, but you'd still be talking to the browser process on the client. Again, you're making assumptions based on things not in your original premise. Who said only the browser process was listening on the client? What is stopping the client from listening on other ports, or stopping other ports from passing the NAT device? At any rate, the point is being missed. No one is saying it's *easy* to bypass a firewall or NAT device. What we're saying is that it can be done, and that dynamic NAT *by itself* does not significantly enhance security. However, clients running few listening sockets and whose translation address is highly dynamic will certainly reduce the time window available for *targeted* attacks. As for packet fragmentation, you can Google for examples. Here's one to get you started, though: http://www.insecure.org/sploits/NT.no_first_fragment.IP_frag.attack.html As part of a defense-in-depth, a bug-free *firewall* performing NAT will certainly help, but will require additional layers of security to be effective. _______________________________________________ RLUG mailing list [EMAIL PROTECTED] http://www.rlug.org/mailman/listinfo/rlug
