Sorry for asking the question here, but I know somebody is bound to know.Is there a way to force the media state of an interface to be up even when there''s no network link on the interface?I am running a vmware bridge on an interface which works perfectly when there is something plugged in but stops when the interface is down.I''ve had a google and not found anything as yet.Many thanks.Si _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Hello, Add a Statiuc IP to that interface good luck Kind Regards Samer ----- Original Message ----- From: Simon Purdy To: shorewall-users@lists.sourceforge.net Sent: Thursday, June 07, 2007 9:34 PM Subject: [Shorewall-users] General Linux Networking Question Sorry for asking the question here, but I know somebody is bound to know. Is there a way to force the media state of an interface to be up even when there''s no network link on the interface? I am running a vmware bridge on an interface which works perfectly when there is something plugged in but stops when the interface is down. I''ve had a google and not found anything as yet. Many thanks. Si ------------------------------------------------------------------------------ Play Movie Mash-up and win BIG prizes! ------------------------------------------------------------------------------ ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ------------------------------------------------------------------------------ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Thanks for the reply. Unfortunately it doesn''t work. Either linux doesn''t forward the packets (what would usually be the point as the wire on the interface is not plugged in) or vmware server requires the interface to be up for the bridge to route packets.Si From: samer_symantec@hotmail.comTo: mail@si2.co.uk; shorewall-users@lists.sourceforge.netDate: Thu, 7 Jun 2007 23:18:08 +0300Subject: Re: [Shorewall-users] General Linux Networking Question Hello, Add a Statiuc IP to that interface good luck Kind Regards Samer ----- Original Message ----- From: Simon Purdy To: shorewall-users@lists.sourceforge.net Sent: Thursday, June 07, 2007 9:34 PM Subject: [Shorewall-users] General Linux Networking Question Sorry for asking the question here, but I know somebody is bound to know.Is there a way to force the media state of an interface to be up even when there''s no network link on the interface?I am running a vmware bridge on an interface which works perfectly when there is something plugged in but stops when the interface is down.I''ve had a google and not found anything as yet.Many thanks.Si Play Movie Mash-up and win BIG prizes! -------------------------------------------------------------------------This SF.net email is sponsored by DB2 ExpressDownload DB2 Express C - the FREE version of DB2 express and takecontrol of your XML. No limits. Just data. Click to get it now.http://sourceforge.net/powerbar/db2/ _______________________________________________Shorewall-users mailing listShorewall-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/shorewall-users _________________________________________________________________ 100’s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Thursday 07 June 2007 10:34:11 am Simon Purdy wrote:> Sorry for asking the question here, but I know somebody is bound to know.Is > there a way to force the media state of an interface to be up even when > there''s no network link on the interface?I am running a vmware bridge on an > interface which works perfectly when there is something plugged in but > stops when the interface is down.I''ve had a google and not found anything > as yet.Many thanks.Si > _________________________________________________________________ > The next generation of MSN Hotmail has arrived - Windows Live Hotmail > http://www.newhotmail.co.ukWhy use a bridge? Vmware-Nat is easier, and more versatile in that you can run your vmware-nat on wireless or wired host network (whereas some wireless cards can''t be bridged). Nat is also somewhat more secure because you do not expose the virtual machine directly to the network. -- __________________________ John Andersen ScreenIO.Com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
John Andersen wrote:>Why use a bridge? >Vmware-Nat is easier, and more versatile in that you can >run your vmware-nat on wireless or wired host network (whereas some >wireless cards can''t be bridged). Nat is also somewhat more secure >because you do not expose the virtual machine directly to the >network.<soapbox mode> NAT is also fundamentally broken in ANY implementation, it is BAD, to be avoided whenever you have enough public IPs to avoid it. It''s an evil cludge invented to avoid having to fix the real problem (lack of addresses), and a second effect of it''s invention has been to delay implementation of the proper fix because too many people think it IS the fix. Along with NAT you need Application Level Gateways (ALGs) for the many protocols it breaks (including FTP and SIP), and for SIP it''s far from trivial to build an ALG - in fact it''s impractical to build a universal ALG that will work in all possible situations because it requires an intimate knowledge of how the network appears to the client which may not be the same as how it appears to the gateway. The security is useful, but no more than you can get with any half decent firewall. And of course, with NAT, you can only forward a port on a public address to one client internally, so if you have a few services you want to make public you end up having to cludge things further - like using non-standard ports. I think by now you''ll have got the idea that I think there is nothing positive about NAT beyond it''s ability to build broken networks that avoid people having to address the problem properly, and I certainly would not advocate it''s use where it can be avoided. </soapbox mode> Hear endeth my standard rant to those who say "just use NAT" ! ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Thursday 07 June 2007, Simon Hobson wrote:> I think by now you''ll have got the idea that I think there is nothing > positive about NATNO, on the contrary, I see a lot of chest thumping and half baked fud having nothing at all to do with solving the OP''s problem. Bridging a VMware guest machine requires the availability of a second IP and aliasing the nic. Neither of these is always a solution, some times you are not allowed a second IP, and some wireless nics can''t be bridged. Nat on the other hand allows the virtual machine to operate when the host only has one IP or even if the Host is disconnected. So thanks for the tirade, (but No thanks, really) but its totally out of place on a list dealing with Shorewall, which is most often used to make firewalls using... You guessed it, NAT. -- _____________________________________ John Andersen http://www.screenio.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Fri, Jun 08, 2007 at 07:48:59AM +0100, Simon Hobson wrote:> Along with NAT you need Application Level Gateways (ALGs) > for the many protocols it breaks (including FTP and SIP), and for SIP > it''s far from trivial to build an ALG - in fact it''s impractical to > build a universal ALG that will work in all possible situations > because it requires an intimate knowledge of how the network appears > to the client which may not be the same as how it appears to the > gateway.I vaguely recall (but can''t find offhand) somebody demonstrating that a universal SIP NAT solution is actually *impossible* - some of the scenarios are indistinguishable at the gateway but require different handling, and you can''t do that without sufficient prior knowledge of the network to identify which ones to use based on static admin-supplied instructions matching the IP address or port number or whatever your particular solution requires. The closest you can get would look vaguely like shorewall, a big heap of tools provided in the hope that the admin can find some way to hook them together that will work in their case, but with no particular reason to expect that they will always be able to (for example, non-trivial mixing of IPsec, SIP, and NAT is unlikely to ever work exactly right and there''s a good chance that nobody will be able to understand why). ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On 6/8/07, John Andersen <jsa@screenio.com> wrote:> On Thursday 07 June 2007, Simon Hobson wrote: > > I think by now you''ll have got the idea that I think there is nothing > > positive about NAT > > NO, on the contrary, I see a lot of chest thumping and half baked > fud having nothing at all to do with solving the OP''s problem. > > Bridging a VMware guest machine requires the availability of > a second IP and aliasing the nic. Neither of these is always > a solution, some times you are not allowed a second IP, and > some wireless nics can''t be bridged.But the fundamental problem NAT is directed at is one that should be fixed - not enough IPs. Why doesn''t your host give you a /24 block of addresses with your current internet service? There aren''t enough to go around. IPv6 is (among other things) an attempt to fix that.> So thanks for the tirade, (but No thanks, really) but its totally out of place > on a list dealing with Shorewall, which is most often used to make > firewalls using... You guessed it, NAT.That doesn''t make NAT necessary or good. It''s simply that in most cases there aren''t enough IPs to go around. If there were, NAT would be (IMO) useless. Will ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Fri, Jun 08, 2007 at 08:02:41AM -0400, Will Murnane wrote:> > That doesn''t make NAT necessary or good. It''s simply that in most > cases there aren''t enough IPs to go around. If there were, NAT would > be (IMO) useless. >That is, unless your intent is to make it (virtually) impossible to address your host(s) globally. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On 6/8/07, Roberto C. Sánchez <roberto@connexer.com> wrote:> On Fri, Jun 08, 2007 at 08:02:41AM -0400, Will Murnane wrote: > > > > That doesn''t make NAT necessary or good. It''s simply that in most > > cases there aren''t enough IPs to go around. If there were, NAT would > > be (IMO) useless. > > > That is, unless your intent is to make it (virtually) impossible to > address your host(s) globally.Name a case in which firewalling does not suffice. I''m curious to see what your answer will be. Will ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Fri, Jun 08, 2007 at 11:00:21AM -0400, Will Murnane wrote:> On 6/8/07, Roberto C. Sánchez <roberto@connexer.com> wrote: > > On Fri, Jun 08, 2007 at 08:02:41AM -0400, Will Murnane wrote: > > > > > > That doesn''t make NAT necessary or good. It''s simply that in most > > > cases there aren''t enough IPs to go around. If there were, NAT would > > > be (IMO) useless. > > > > > That is, unless your intent is to make it (virtually) impossible to > > address your host(s) globally. > Name a case in which firewalling does not suffice. I''m curious to see > what your answer will be. >I am not saying that firewalling is not sufficient, simply that NAT is viewd by some an added layer of defense. If it is not physically possible to address a particular host globally, then you must first penetrate another point on the network (likely a very well secured point) first. Think about it. Is there *ever* a need for a database server that powers a website to be accessible from the public Internet? Probably not. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Simon Hobson wrote:> <soapbox mode> > NAT is also fundamentally broken in ANY implementation, it is BAD, to > be avoided whenever you have enough public IPs to avoid it. It''s an > evil cludge invented to avoid having to fix the real problem (lack of > addresses), and a second effect of it''s invention has been to delay > implementation of the proper fix because too many people think it IS > the fix. Along with NAT you need Application Level Gateways (ALGs) > for the many protocols it breaks (including FTP and SIP), and for SIP > it''s far from trivial to build an ALG - in fact it''s impractical to > build a universal ALG that will work in all possible situations > because it requires an intimate knowledge of how the network appears > to the client which may not be the same as how it appears to the > gateway. > > The security is useful, but no more than you can get with any half > decent firewall. ><snipped for Brevity> Forgive me for posting on this topic, I want to clarify a few things in the hopes that novices will take notice. For all the arguing you kids are doing regarding NAT, the following remains true and "less than expert" admins should know about it. NAT, for all it''s faults, does a decent job of keeping outsiders from connecting to an internal network. Having access to a true class c that you can use for lan/wan purposes on face value seems nice. But when security mistakes are made in that context it can lead to unfettered access to to the internal infrastructure. Not only that, but you also multiply the number of security breach possibilities because now your internal network electronics, printers, fax machines, IP cameras, <name your esoteric device here> have to be hardened to the same level of a server (which would be behind a firewall anyhow). I don''t know about anyone else, but I certainly don''t relish the idea of having to add IP cameras, printers, and Windows machines to the weekly security audit .... I''ve got 36 servers to watch- that''s enough security worry. I certainly wouldn''t want the *majority* of IT people I''ve worked with saddled with making sure a firewall was adequately protecting a UPS. They just don''t have the protocol knowledge. So be careful here, some guy with good intentions is going to take your "technically correct" opinions, misconfigure a firewall for 240 devices on a class c, and 3 million people will have lost their credit card info- all because some cracker figured out how to script a dictionary attack through a Logitech Webcam. Remember the audience. -- Michael Cozzi cozzi@cozziconsulting.com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On 6/8/07, Michael Cozzi <cozzi@cozziconsulting.com> wrote:> NAT, for all it''s faults, does a decent job of keeping outsiders > from connecting to an internal network. Having access to a true class c > that you can use for lan/wan purposes on face value seems nice.Just because each device has its own public IP address doesn''t mean that it isn''t behind a firewall. A "default-deny" policy works equally well with or without NAT.> So be careful here, some guy with good intentions is going to take > your "technically correct" opinions, misconfigure a firewall for 240 > devices on a class c, and 3 million people will have lost their credit > card info- all because some cracker figured out how to script a > dictionary attack through a Logitech Webcam.If someone misconfigures a firewall with NAT, the same problem can occur. Unless I''m mistaken, a two-interface firewall like Shorewall creates will work just fine for routing a whole subnet, and setting rules for each machine behind it, even without NAT. It''s not a common setup, because ISPs don''t hand out large blocks of IPs, but it''s possible. Will ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Michael Cozzi wrote:>Simon Hobson wrote: >> <soapbox mode> >> NAT is also fundamentally broken in ANY implementation, it is BAD, to >> be avoided whenever you have enough public IPs to avoid it. It''s an >> evil cludge invented to avoid having to fix the real problem (lack of >> addresses), and a second effect of it''s invention has been to delay >> implementation of the proper fix because too many people think it IS > > the fix.> Forgive me for posting on this topic, I want to clarify a few things >in the hopes that novices will take notice. > > For all the arguing you kids are doing regarding NAT, the following >remains true and "less than expert" admins should know about it. > > NAT, for all it''s faults, does a decent job of keeping outsiders >from connecting to an internal network. Having access to a true class c >that you can use for lan/wan purposes on face value seems nice. But when >security mistakes are made in that context it can lead to unfettered >access to to the internal infrastructure. Not only that, but you also >multiply the number of security breach possibilities because now your >internal network electronics, printers, fax machines, IP cameras, <name >your esoteric device here> have to be hardened to the same level of a >server (which would be behind a firewall anyhow). > > I don''t know about anyone else, but I certainly don''t relish the >idea of having to add IP cameras, printers, and Windows machines to the >weekly security audit .... I''ve got 36 servers to watch- that''s enough >security worry. I certainly wouldn''t want the *majority* of IT people >I''ve worked with saddled with making sure a firewall was adequately >protecting a UPS. They just don''t have the protocol knowledge.What''s the difference, security wise between : DNAT net loc:a.b.c.d and ALLOW net loc:a.b.c.d assuming you have a default policy net->loc of drop ? One rule allows packets from the net to the device, the other rule allows packets from the net to the device. I do agree with you that NAT does make a fairly good packet level firewall - but then so does a firewall with a default policy of drop. I''d even go so far as to suggest that the only reason the botnet problem isn''t a lot worse is that too many (from the bot herders pov) are behind default firewalls.> So be careful here, some guy with good intentions is going to take >your "technically correct" opinions, misconfigure a firewall for 240 >devices on a class c, and 3 million people will have lost their credit >card info- all because some cracker figured out how to script a >dictionary attack through a Logitech Webcam.I think you slightly dampen your argument there. If a novice with no knowledge of firewalls is responsible for security of 3 million sets of credits card details then someone higher up has some serious questions to answer - and issues with the firewall are the least of their worries ! The sad thing is that whilst it''s good to have this discussion, the people who need to see it are almost certainly never going to :-( ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Historiadores acreditam que, em Sex 08 Jun 2007, Will Murnane disse:> Name a case in which firewalling does not suffice. I''m curious to see > what your answer will be.Sometimes there are ways to bypass firewalls. With NAT, even if you circumvent the firewall your internal addresses are still unreachable. If you have a valid /24 network, bypassing the firewall leaves your entire network on the wild. You can argue that all nodes should have local/application firewalls like ZoneAlarm and you can use internal firewalls between zones and blablabla... But in this case the complexity would be so overwhelming that it would be simpler to build a single good old crappy NATed firewall. Of course a real skilled hacker would break into the NAT router first and, once having access to a shell inside the router, connect to your local network directly. He can even use the compromised router as a redirector with a little help from my friend NetCat. But if you''re compromised this far there is something wrong with your security policy... That said, I agree with you: in some cases, NAT sucks. -- Henrique Cesar Ulbrich henrique.ulbrich@gmail.com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Historiadores acreditam que, em Sex 08 Jun 2007, Will Murnane disse:> Just because each device has its own public IP address doesn''t mean > that it isn''t behind a firewall. A "default-deny" policy works > equally well with or without NAT.You REALLY trust your firewall, don''t you? -- Henrique Cesar Ulbrich henrique.ulbrich@gmail.com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Simon Hobson wrote:> > What''s the difference, security wise between : > DNAT net loc:a.b.c.d > and > ALLOW net loc:a.b.c.d > assuming you have a default policy net->loc of drop ? >Simon, It''s a huge difference. RFC 1918 packets are not routable. Thus, even if your firewall drop rule failed, the chance of easy NAT traversal is pretty slim if the admin of the gateway machine has been smart about what services are exposed. You do not have that advantage if you are firewalling a LAN comprised of routable IPs. -- Michael Cozzi cozi@cozziconsulting.com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Fri, Jun 08, 2007 at 04:12:58PM -0300, Henrique Cesar Ulbrich wrote:> With NAT, even if you circumvent the firewall your internal addresses are > still unreachable. If you have a valid /24 network, bypassing the firewall > leaves your entire network on the wild.You have to realise that all you''re doing here is using a curious definition of "circumvent" and "bypass" to mean two different things. The methods used to penetrate a firewall are the same regardless of whether or not it performs NAT, and so are the effects. Even if a method existed to defeat the filtering part without defeating the NAT part, nobody would bother using it (and I''m not aware of any such method existing). ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
>Think about it. Is there *ever* a need for a database >server that powers a website to be accessible from the public Internet? >Probably not.Hello, here is a case: a web server accesses in-house SQL server that contains proprietary code and hardware too sensitive to be left sitting in a cage in some colo. NAT / Firewall (hope I''m using the terminology correctly here) has port forwarded to database server, with access allowed only from webserver''s ip. I''m reading this thread because I want to know what the dangers are with NAT etc. The conversation is interesting, but I would like a more in-depth explanation of why some are saying that NAT is not a good way to protect a network, and it would be good to know how a NAT firewall could be hacked, if Shorewall is secure enough to be used in the above scenario, what configuration mistakes to look out for with Shorewall, and especially, in much more detail, the answers to this question:> What''s the difference, security wise between : > DNAT net loc:a.b.c.d > and > ALLOW net loc:a.b.c.d > assuming you have a default policy net->loc of drop ?Thanks -J (Tried to make this more readable for you by putting carriage returns after each line, hope that doesn''t make it worse) ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Henrique Cesar Ulbrich
2007-Jun-08 20:43 UTC
NAT: good or evil? (was: General Linux Networking Question)
Historians believe that, in Fry 08 Jun 2007, Andrew Suffield said:> The methods used to penetrate a firewall are the same regardless of > whether or not it performs NAT, and so are the effects. Even if a > method existed to defeat the filtering part without defeating the NAT > part, nobody would bother using it (and I''m not aware of any such > method existing).When I say "bypass", I wasn''t being that specific. I was just saying that there are ways to avoid the firewall by using some other path. One way to "bypass" a firewall is using an alternate gateway. In many compromised clients I''ve been called to help, I''ve found that the point of penetration was not the main router/firewall, but: - an old dial-up connection (a hidden modem rack that no one knew was still active - and, yes, they are still very common in Brazil) - some "smart" executive that thought it would be nice to avoid the firewall restrictions and substribe to a DSL line connected to his own corporate desktop (another common and sad behavior in brazilian corporations) - "work at home" employees with poorly configured VPNs (the majority of brazilian businesses lack good IT personell because they want to pay peanuts) BUT (as you will say next) all of them were directly connected to the internal nets, so NAT was not a big problem to the invader. The internal nets, in all cases, were also poorly protected, designed and deployed, so were a enjoyable playground to even the less skilled kiddie. So, you''re right. In any way (with or without NAT) the atacker would gain access to the whole subnet on those examples. This doesn''t mean that NAT is a bad thing. If, for instance, a software failure, bug or operator mistake happens and the firewall rules are shut off, NAT would still be a temporary security layer. ALSO, real IPs cost money. Even with IPv6, they will still cost money - maybe less money, but money indeed. RFC1918 addresses are for free. -- Henrique Cesar Ulbrich henrique.ulbrich@gmail.com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On 6/8/07, Henrique Cesar Ulbrich <henrique.ulbrich@gmail.com> wrote:> Historiadores acreditam que, > em Sex 08 Jun 2007, Will Murnane disse: > > Just because each device has its own public IP address doesn''t mean > > that it isn''t behind a firewall. A "default-deny" policy works > > equally well with or without NAT. > > You REALLY trust your firewall, don''t you?Yes. Do you not trust yours? If your firewall lets packets through it''s not supposed to, I think it''s time to find a new one! To be clear, I''m not suggesting letting all of your machines be plugged into a switch that goes directly to the internet. That would lose you many advantages of having your own network - controlling DHCP, DNS, content filtering, and so forth - but when all the machines are going through one router, their security (aside from any filtering they themselves run) is dependent on how good the firewall is, not whether it does NAT or not. If your firewall drop rule fails, as Michael suggests, you have bigger problems than whether NAT is on or not. Will ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Fri, Jun 08, 2007 at 03:48:08PM -0400, jbrave wrote:> > I''m reading this thread because I want to know what the dangers are with NAT etc. > The conversation is interesting, but I would like a more in-depth explanation of > why some are saying that NAT is not a good way to protect a network, and it would > be good to know how a NAT firewall could be hacked,All methods for penetrating firewalls fall into one of two interesting classes: 1. Compromise the firewall host Any system-level exploit will do here. A flaw in ssh that gets you root access, or a buffer overrun in the kernel''s connection tracking engine, or whatever - anything that lets you run arbitrary code on the firewall. Once you''ve got that, you can modify it to do whatever you want, forwarding packets for you or just reconfiguring it to open a hole. 2. Construct a tunnel Tunnels are any traffic encapsulation method that lets you send lower-level packets through a higher-level protocol. Any protocol that permits arbitrary data transport can be used for tunnelling - popular choices are HTTP, DNS, and ping. You bundle up your IP packets, wrap them in an HTTP message or DNS query or whatever, and send them through the firewall to a host on the inside. The inside host unwraps them and sends them out to the network. This method requires at least partial user-level control over a host on the inside - a system exploit is not necessarily required, any user with access to send and receive packets on the internal network, and to the internet over your tunnelling protocol, will suffice. Common targets are web servers (exploit in apache), DNS servers (exploit in bind), etc. You will note that in neither case does NAT afford any protection or threat. It''s not really relevant to the security question. Saying that "NAT is not a good way to protect a network" is much like saying "cheese is not a good way to protect a network" - neither of them is going to do anything useful in this respect. ObPhilosophy: Remember what the word "firewall" means: it''s a partition in a building that prevents a fire from spreading past it. It is not a fire suppression system, and it is not a method for making all your stuff out of non-flammable materials, it is just a mechanism for containing the damage once a fire has already started. Network firewalls are the same - they are a contingency, they are not your primary method for preventing fires. Pretty much everything that you can do to reduce the threat of real-world fires has an analogue form in network security, and most of the tradeoffs are very similar (building every wall in your house out of fireproof materials is not a smart or cost-effective way to stop it from burning down, even if it would probably work). ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Andrew Suffield
2007-Jun-08 20:59 UTC
Re: NAT: good or evil? (was: General Linux Networking Question)
On Fri, Jun 08, 2007 at 05:43:21PM -0300, Henrique Cesar Ulbrich wrote:> BUT (as you will say next) all of them were directly connected to the internal > nets, so NAT was not a big problem to the invader. The internal nets, in all > cases, were also poorly protected, designed and deployed, so were a enjoyable > playground to even the less skilled kiddie. > > So, you''re right. In any way (with or without NAT) the atacker would gain > access to the whole subnet on those examples.My point exactly. NAT doesn''t have any effect on security.> This doesn''t mean that NAT is a bad thing.I''m not really saying that it is, just that it''s not a good thing either, from a security perspective.> ALSO, real IPs cost money. Even with IPv6, they will still cost > money - maybe less money, but money indeed. RFC1918 addresses are > for free.Now you''re getting into the real reasons for NAT - administrative, not security. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Simon Hobson
2007-Jun-08 21:05 UTC
Re: NAT is bad ? (Was: General Linux Networking Question)
jbrave wrote:> >Think about it. Is there *ever* a need for a database >>server that powers a website to be accessible from the public Internet? >>Probably not. > >Hello, here is a case: a web server accesses in-house SQL server that >contains proprietary code and hardware too sensitive >to be left sitting in a cage in some colo. NAT / Firewall >(hope I''m using the terminology correctly here) >has port forwarded to database server, with access allowed only from >webserver''s ip. > >I''m reading this thread because I want to know what the dangers are >with NAT etc. >The conversation is interesting, but I would like a more in-depth >explanation of >why some are saying that NAT is not a good way to protect a network,Well it''s not really a question of NAT not being a good tool to protect a network, but that NAT is a bad thing to have on a network. My take is that it break the most fundamental rules of IP : a) all devices have a globally unique address b) all addresses are routable from all other addresses* * with the modern qualifier that there may be ''administrative restrictions'' such as firewall in the way Many protocols use the IP address of one or more devices in the packets - FTP being the most common. To deal with this, just about every NAT gateway has to inspect packets for certain protocols and modify the contents of the packet to ''fix'' the fact that the address isn''t real. The tools that do this are usually known as Application Level Gateways. SIP (used in VoIP) is particularly bad since two devices may talk to different registrars (for control) and be told to deal directly between the end devices for their data stream. Since there is no preconfigurable link between the SIP session and the ports used for the RTP data stream then it gets ''interesting'' to make it work at all - to the extent that the variety of NAT employed by Zyxel makes SIP unusable* in my experience. * It can be made to work, but needs an external proxy that will ignore what''s in the SIP exchange and work out where the RTP packets are ACTUALLY coming from rather than where they SHOULD be coming from !> and it would >be good to know how a NAT firewall could be hacked, if Shorewall is >secure enough >to be used in the above scenario, what configuration mistakes to >look out for with >Shorewall,The main positive feature for NAT is that even if you accidentally change your default policy to allow, then no inbound traffic happens without there being a predefined mapping (aka port forwarding) or a matching outbound connection to create a dynamic mapping. If doing normal routing, then such a mistake would allow inbound traffic since there is no requirement for there to be a NAT mapping for the firewall to know where to send the packets. Ultimately, the ONLY reason NAT was invented was to work around the problem of IP address depletion. The downside is that it breaks all sorts of things (hence the creation of yet more protocols such as uPNP and STUN to try and work around the problems caused by the workaround to the first problem). And also, IMHO, by it''s very existence it has removed the pressure to fix the real problem and so after many many years there still is no real sign of IP6 being supported by the mainstream internet** ** As in most ISPs don''t support IP6, most consumer grade equipment doesn''t do IP6, I''ve yet to come across any VoIP equipment that does IP6, and so on.> and especially, in much more detail, the answers to this question: > >> What''s the difference, security wise between : >> DNAT net loc:a.b.c.d >> and >> ALLOW net loc:a.b.c.d >> assuming you have a default policy net->loc of drop ?IMHO there is no difference. If you have NAT then a DNAT rule will mangle the destination address appropriately and forward the packet. If you don''t have NAT then an ALLOW rule will forward the packet. As long as your default policy is drop (or deny) then other inbound traffic will be blocked. BTW the syntax of the above lines may not be correct - it''s just ''off the top of my head''.>(Tried to make this more readable for you by putting carriage >returns after each line, hope that doesn''t make it worse)It''s not been a problem for me, but I''d advise a shorter line length so when it gets quoted it doesn''t get word wrapped to have a single word on every other line. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Will Murnane
2007-Jun-08 21:07 UTC
Re: NAT: good or evil? (was: General Linux Networking Question)
On 6/8/07, Henrique Cesar Ulbrich <henrique.ulbrich@gmail.com> wrote:> When I say "bypass", I wasn''t being that specific. I was just saying that > there are ways to avoid the firewall by using some other path.If these ways exist, then this isn''t a problem with NAT or no NAT - it''s independent. If I open port 22 to my home box, and allow root access, I leave myself open whether NAT is on or not. The firewall and NAT features are related, in that they are in the same part of the kernel, but in terms of features they''re independent.> This doesn''t mean that NAT is a bad thing. > If, for instance, a software failure, bug or operator mistake happens and the > firewall rules are shut off, NAT would still be a temporary security layer."Temporary security" is even worse than no security at all. If the firewall rules get shut down, the default of the OS should be to drop the packets (not route them)... but even so, if it''s a concern, run two or three layers of firewalls. They''re cheap, especially if they don''t need to do NAT.> ALSO, real IPs cost money. Even with IPv6, they will still cost money - maybe > less money, but money indeed. RFC1918 addresses are for free.What I''ve heard (rumored) is that ISPs will hand out /64 blocks of IPs. The low 48 bits of that will be your machine''s MAC address, leaving 16 bits of routeable space. Thus, "cheap" would be the word for real IPs. Even if they only handed out smaller blocks, I can''t imagine any ISP so stingy as to hand out single IPs when they are so cheap. Will ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Simon Hobson
2007-Jun-08 21:12 UTC
Re: NAT: good or evil? (was: General Linux Networking Question)
Andrew Suffield wrote:> > ALSO, real IPs cost money. Even with IPv6, they will still cost >> money - maybe less money, but money indeed. RFC1918 addresses are >> for free. > >Now you''re getting into the real reasons for NAT - administrative, not >security.And I disagree anyway, I think we''ll find that the concept of getting a single address with IP6 will be laughable. Oh hang on a minute, I guess some ISPs will try it ! In general, I suspect that end users will find themselves with something like a /48, perhaps /24 on a cheapskate ISP, /8 would be REALLY tight-a***ed and that still gives you 253 addresses to go at ! ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/