12:19 p.m.
Are there any active project about it?
like:
http://www.camrdale.org/apt-p2p/
for Debian.
Why doesn't it have viability? Why does it have?
What are the security issues regarding it?
e.g.:
No port forwarding is needed in p2p (no need for open ports [? fixme]):
http://samy.pl/pwnat/ - these kind of projects will be more prevalent, as the isp's
will show up with the Large Scale NAT's -
http://tech.slashdot.org/story/10/12/17/2226230/Carrier-Trick-To-Save-IPv...
- soon we will run out of ipv4 addresses.
Yum does the gpgcheck, so we just need audited code, that does the p2p part. (i'm not
a developer, sorry).
Remember this video(?): Twitter - Murder Bittorrent Deploy System
http://vimeo.com/11280885
Common sense: if i need to spread lot's of files no matter small or big, to
many-many-many-many pc's, then i would give a 10 Mbit line to the master server, and
the remaining job is done by the people, so that in this way, they could contribute to the
project.
The Fedora installer could contain a question: how would you like to receive updates? [if
e.g.: GNOME is installed, the updates would be "forced*", because it's
likely not a server, just a desktop pc] - and the answers would be: by http or by p2p (or
p2p with encryption)
What is you're opinion? Objection? Please tell me, because i just can't understand
why doesn't this brilliant technology/method spreads. It would be very-very scalable.
+ if i go to the main website, and click "Get Fedora"
https://fedoraproject.org/en/get-fedora
it would need to accentuate the ISO download by torrent, not http, the servers would be
way more "relieved", and ready for any expected, or unexpected loads (ddos, a
version of Fedora is out, growing number of Fedora users).
I'm sure there would be many Fedora or other RPM based distribution users, who would
happily seed the packages. Broadband connections, HDD's are cheap in 2011.
*by forcing i meant it should install updates without asking, the primary security relies
on that the packages are up-to-date or not.
**_I LOVE FEDORA_, i just wanted to write down my opinion, sorry
Thank you for reading and have a nice day.
1:40 p.m.
On Sunday 26 December 2010 18:19:22 S Mathias wrote:
No port forwarding is needed in p2p (no need for open ports [?
fixme]):
http://samy.pl/pwnat/
While I find these ideas of NAT and firewall-piercing quite interesting, there
is always a "but" somewhere --- in the pwnat case, it is a "but what if the
ICMP is filtered?" (as it actually is for most NAT'd networks I've seen).
The only permanent solution to usability of p2p in general is IPv6, where all
addresses will be public and thus accessible from outside. And IPv6 would fix
other protocols broken by introduction of NAT, not just p2p stuff.
But until then, p2p can never be completely reliable/available to everyone, as
http is now.
Common sense: if i need to spread lot's of files no matter small
or big, to
many-many-many-many pc's, then i would give a 10 Mbit line to the master
server, and the remaining job is done by the people, so that in this way,
they could contribute to the project.
Not everyone needs every file to update, so this will not scale as well as you
might imagine. Also, with all the mirrors out there, I don't see much benefit
in using p2p for updating.
The Fedora installer could contain a question: how would you like to
receive updates? [if e.g.: GNOME is installed, the updates would be
"forced*", because it's likely not a server, just a desktop pc]
Forced? Why? I generally do a "yum update" only manually, and even then I
inspect what is to be installed before I agree to proceed. And I'm a desktop
user. No, you never want to *force* updates on people, it might break some 3rd
party software they are maybe using. Think kernel updates and nVidia closed
source drivers, as the most common example.
- and the
answers would be: by http or by p2p (or p2p with encryption)
Whereas only http is the protocol that can be assumed to be available
everywhere and to everyone. The p2p solutions always rely on other ports being
open, UDP/ICMP availability, etc.
+ if i go to the main website, and click "Get Fedora"
https://fedoraproject.org/en/get-fedora
it would need to accentuate the ISO download by torrent, not http, the
servers would be way more "relieved", and ready for any expected, or
unexpected loads (ddos, a version of Fedora is out, growing number of
Fedora users).
Oh, my...
You surely missed an *insanely* big thread on this list, devoted precisely and
exclusively to the *bitching* about removal of bittorent links from the then-
newly-designed "get fedora" website...
IIRC, Mairin Duffy was nearly crucified for removing the torrent link from the
page. In a nutshell, the argument was that (according to statistics) only
every fifth Fedora user actually uses torrent to download the .iso. The
counterargument was that (again according to statistics) since there are cca 1
million Fedora users out there, 200 thousand people just got screwed. The
counter-counterargument was that people who know how to use torrent typically
know how to use google to find the .torrent of the .iso, so no need for a link.
The ccc-argument was that anyone with a clue what is an operating system could
use google to find a Fedora .iso, so no need for a "get Fedora" page in the
first place, which defeats the purpose... And so on and on, with a lot of
tangent discussions and even more unrelated bitching about list ettiquette
etc... Look it up in the archives, if you are interested.
The whole thing was eventually resolved when Mairin gave in (based on some
sound and friendly advice of other Fedora devs) and created a link for "other
download methods, including torrents" and updated the website...
My point --- you don't want to open that topic again. ;-)
I'm sure there would be many Fedora or other RPM based
distribution users,
who would happily seed the packages. Broadband connections, HDD's are
cheap in 2011.
There are mirrors who happily do that right now via http, so I don't see any
serious benefit.
*by forcing i meant it should install updates without asking, the
primary
security relies on that the packages are up-to-date or not.
No, the primary security relies in the brain of the person using the computer.
Automatic updates that leave the user out of the loop are known to be a Very
Bad Idea (tm).
I've seen automatic updates breaking my own and other people's systems more
often than I want to remember, and the whole thing can get pretty bad
occasionally. Just think of a new kernel update which breaks the closed nVidia
drivers (or sometimes open radeon drivers ;-) ), and similar problems that pop
up every now and then. Really, you *don't* want enforced updates. The user
*must* be given a choice whether to accept or not accept any individual
package update, including security updates.
HTH, :-)
Marko
2:30 p.m.
On 12/26/2010 11:40 AM, Marko Vojinovic wrote:
Automatic updates that leave the user out of the loop are known to be
a Very
Bad Idea (tm)
Automatic updates are part of the slavewear mentality: I know what your
computer needs and you don't. Once you allow them you're effectively
giving control of what's installed on your computer to whoever controls
the updates. Granted, I've never needed to reject an update, but I like
to know what's happening and occasionally, that's a Good Thing(TM).
I use nVidia graphics on this box and have had good luck with
kmod-nvidia. Once in a while, I'll see that there's a kernel update but
no matching kmod. With automatic updates, I'd probably end up being
forced to update and reboot into a system that can't run X and, unless I
understood what was going on, I'd be hosed. I've been on
fedoraforum.org for several years and every time this happens, there are
threads from newcomers who don't know that they need to reboot into
their old kernel, or how to do it. As it is, I have two choices: refuse
the kernel update or simply hold off on rebooting until the kmod catches
up. (Well, in point of fact, I picked choice number three: I have both
the kmod and akmod so that it doesn't matter if the kmod's up to date.)
How I deal with the situation isn't the point, of course. What's
important is that I have enough control over my box to be able to
control the situation. My sister uses Ubuntu because, unlike me, she's
not a geek and needs something that Just Works(TM). When her updater
has updates, she installs them; if it tells her to log out and back in,
or reboot, she does. On the very rare occasions that something goes
wrong I walk over to her computer and help her. Even so, she's still in
charge because even Ubuntu lets her review the updates and decide if she
wants them. Granted, she doesn't have the knowledge to do so but if,
let's say, I happened to know that a certain update were bad, I could
warn her and talk her through rejecting it. She's never forced to
accept anything, and IMAO anything else would be counter to the basic
philosophy of Linux.
6:51 a.m.
On Wednesday 29 December 2010 01:11:00 Bill Davidsen wrote:
Marko Vojinovic wrote:
> On Sunday 26 December 2010 22:11:17 you wrote:
>> On 12/26/2010 02:40 PM, Marko Vojinovic wrote:
>> Historically, we used nat for 2 purposes:
>> (1) to shield inside machines
>> (2) free up ipv4 (was an accidental consequence of (1)
>
> In a nutshell, the conclusion is that (1) is an urban legend --- NAT
> *does* *not* (and moreover, *should* *not* ) shield your inside machines
> from outside attacks. You still need to use the proper firewall for
> shielding.
>
> The only benefit of NAT is (2), ie. artificially enlarging the scope of
> available v4 IP numbers, at the price of breaking functionality. And this
> is not a consequence of (1), but rather the primary reason why NAT was
> introduced in the first place.
Clearly you have little understanding of the other uses of NAT, one of
which is connect redirection. For instance, when I get a connect to an IP
and port, it allows me send the connection to some machine inside the
firewall without having to have the rest of the machine ports available or
the "real" IP visible.
You don't need NAT for this. Just configure the firewall to drop all
nonestablished incoming packets to that machine's IP, except those on that
specific port. This has nothing to do with visibility of the IP of that
machine.
Btw, you need the firewall anyway, so why having to maintain both NAT and
firewall, when you can maintain just the firewall?
I realize that somehow you have convinced yourself
that not allowing everyone on Earth to bang on every machine somehow is
bad or unnecessary,
I never said anything like that, nor am I convinced that is true. You realized
wrong.
and that every machine running every OS can somehow be
protected by a firewall,
Why not? Just implement the firewall instead of the NAT at your gateway, and
you are done. I bet that the firewall is actually already there, working along
with NAT (unless you have disabled it on purpose, which would be a bad idea
anyway). This is the most common configuration these days, AFAIK.
but in practice this doesn't work most of the
time. What is possible in theory with a perfect firewall doesn't happen
and/or take a huge investment in effort and auditing to approximate.
This is just FUD. How much time takes to implement NAT yourself? Have you ever
tried it, or have you just used a preconfigured NAT implementation in your
router? Routers come with a preconfigured firewall as well, for users who don't
want to bother doing it manually. I see absolutely no serious investment in
effort and auditing of a firewall.
It's as easy to implement as NAT. And it's already there, in most of the
networking hardware one can buy these days, preconfigured for most common
usecases.
NAT can even be used for load balancing including fail-over, and
again
there are other ways, but little to be gained by doing it at lower levels.
If NAT were seriously useful for these things, people would use it for that
purpose. As you may know, NAT can be implemented also with *public* IP's ---
the internal address does not need to be a local, non-routable one.
But I've never ever see anyone implement NAT over public IP's just to deal
with fail-over and load-balancing. This is always done within dns
configuration, the round-robin method being the most elementary (and crudest)
way.
The only usage of NAT I've ever seen is artificial increase in the IP pool. And
that's precisely the reason why it has been designed, and also why it will
become obsolete once IPv6 becomes dominant.
Please understand which problem set is most simply solved by NAT (or
anything else you suddenly decide is obsolete). IPv6 solutions will
undoubtedly be different, but don't just make a generalization because you
want it to be true.
You know, it is possible to implement NAT under IPv6, too, if you can find a
meaningful purpose for it. Let's wait and see how many people will find it
necessary or at least useful for anything, once everyone obtains a /64 segment
of v6 addresses.
My bet is that in 20 years noone will even remember the concept of NAT, let
alone implement it anywhere...
HTH, :-)
Marko
5:02 a.m.
On Tue, 2010-12-28 at 20:11 -0500, Bill Davidsen wrote:
Clearly you have little understanding of the other uses of NAT, one
of
which is connect redirection. For instance, when I get a connect to an
IP and port, it allows me send the connection to some machine inside
the firewall without having to have the rest of the machine ports
available or the "real" IP visible.
That's just port forwarding, not NAT. It's a fixed rule.
NAT is the magic genie in the middle that keeps track of connections
from various internal machines going out, and makes sure that the
related returning traffic goes through to the right internal machine.
I realize that somehow you have convinced yourself that not allowing
everyone on Earth to bang on every machine somehow is bad or
unnecessary, and that every machine running every OS can somehow be
protected by a firewall, but in practice this doesn't work most of the
time. What is possible in theory with a perfect firewall doesn't
happen and/or take a huge investment in effort and auditing to
approximate.
Piffle! It's completely easy to firewall a computer in the same way
that NAT pretends to be a firewall: Ignore all unexpected incoming
connections. Do nothing (neither block, or otherwise act especially on)
any outgoing connections. That basic configuration can be preset, so
dumb users can simply "turn on firewall."
NAT is NOT a firewall. It's not meant to be. It cannot be relied upon
to act as one, because that is not its purpose nor design.
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
7:11 p.m.
Marko Vojinovic wrote:
On Sunday 26 December 2010 22:11:17 you wrote:
> On 12/26/2010 02:40 PM, Marko Vojinovic wrote:
>> The only permanent solution to usability of p2p in general is IPv6, where
>> all addresses will be public and thus accessible from outside. And IPv6
>> would fix other protocols broken by introduction of NAT, not just p2p
>> stuff.
>
> Why would anyone want all internal machines public anyway ?
>
> Historically, we used nat for 2 purposes:
>
> (1) to shield inside machines
> (2) free up ipv4 (was an accidental consequence of (1)
There was a quite large thread on the CentOS list recently about this.
In a nutshell, the conclusion is that (1) is an urban legend --- NAT *does*
*not* (and moreover, *should* *not* ) shield your inside machines from outside
attacks. You still need to use the proper firewall for shielding.
The only benefit of NAT is (2), ie. artificially enlarging the scope of
available v4 IP numbers, at the price of breaking functionality. And this is
not a consequence of (1), but rather the primary reason why NAT was introduced
in the first place.
Clearly you have little understanding of the other uses of NAT, one of which is
connect redirection. For instance, when I get a connect to an IP and port, it
allows me send the connection to some machine inside the firewall without having
to have the rest of the machine ports available or the "real" IP visible. I
realize that somehow you have convinced yourself that not allowing everyone on
Earth to bang on every machine somehow is bad or unnecessary, and that every
machine running every OS can somehow be protected by a firewall, but in practice
this doesn't work most of the time. What is possible in theory with a perfect
firewall doesn't happen and/or take a huge investment in effort and auditing to
approximate.
But when the service is being moved to another host, with NAT new connections
are simply sent to another host, leaving existing connections to taper off in
some non-disruptive manner. Yes this can be done at lower levels, with complex
routing at the MAC level, but there is no joy in doing things the hard way just
because it is possible.
NAT can even be used for load balancing including fail-over, and again there are
other ways, but little to be gained by doing it at lower levels.
Please understand which problem set is most simply solved by NAT (or anything
else you suddenly decide is obsolete). IPv6 solutions will undoubtedly be
different, but don't just make a generalization because you want it to be true.
After IPv6 gets introduced, the number of available IP addresses will
be more
than enough to eliminate any need for NAT, while for security you'll still use
the same firewall as you needed to do with IPv4. The net gain is that protocols
that were broken by NAT will not be broken anymore, in addition to the larger
address space.
Of course, some people will remain dense forever and keep implementing NAT
even in IPv6, with an illusion that it will improve their security. Those
people cannot be helped, unfortunately... ;-)
Best, :-)
Marko
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
5:56 p.m.
On 12/27/2010 03:16 PM, Marko Vojinovic wrote:
Oh, but the scanner *will* get a response, that's the whole point of port-
forwarding. A scanner sends out a bait, NAT forwards it to appropriate server,
the server responds, NAT forwards the response back to the scanner.
Not if the router is set to drop any incoming packets on ports that
aren't forwarded, and that was what I was thinking of.
If malware has infected one of your machines, it typically *will* initiate the
connection (calling-home), and the NAT will do nothing to prevent
communication in that case.
I simplified there a little. I was thinking that if the "mother ship"
gave out your IP to other infected boxes they wouldn't be able to
connect. Probably I should have been more specific. Thanx for bringing
it up.
>
> In your example above, what's the difference between scanning your NAT
> box for open ports and having them forwarded by the NAT box to a box
> on your internal network or scanning a publicly accessible box on your
> internal network directly?
>
Again, the router silently drops all attempts to connect to any port not
forwarded. Yes, your firewall should do the same thing and probably does.
11:53 a.m.
On 12/27/2010 12:44 PM, Chris Adams wrote:
implemented defense in depth.
NAT is a combination of a stateful firewall and a packet mangler (that
changes the IP+port fields). A stateful firewall without a packet
mangler (i.e. no NAT) is just as secure.
probably - and yes if all is configured well - however, at first blush
it seems firewall misconfiguration (errors) could be less of an issue
with non-routable addresses - they have nowhere to go on the inside -
and since some of us have less experience with ip6 - this may be more of
an issue than with ip4 - I could be being naive here ...
12:14 p.m.
On Mon, Dec 27, 2010 at 12:41 PM, Joe Zeff <joe(a)zeff.us> wrote:
On 12/27/2010 09:15 AM, Patrick O'Callaghan wrote:
>
> Actually IIRC you have that the wrong way round. NAT was invented to
> deal with address space exhaustion, and had the side-effect of hiding
> machines behind the router.
Before somebody steps in again to point out that NAT isn't a firewall,
I'd like to give my perspective on it. If your router uses NAT and only
forwards those ports you've told it to (and then, each port only goes to
one machine) port scanners can't find your machines because nothing
responds to their attempts to connect. And, of course, even if you have
malware trying to act as some sort of server it won't do any good unless
your machine initiates the connection. No, this isn't a firewall, but
it's better than having your box sitting on the net completely exposed.
Consider NAT as one layer of protection in a properly designed and
implemented defense in depth.
NAT doesn't have anything to do with security.
In your example above, what's the difference between scanning your NAT
box for open ports and having them forwarded by the NAT box to a box
on your internal network or scanning a publicly accessible box on your
internal network directly?
The firewall's the only defense in both cases.
11:44 a.m.
Once upon a time, Joe Zeff <joe(a)zeff.us> said:
Before somebody steps in again to point out that NAT isn't a
firewall,
I'd like to give my perspective on it. If your router uses NAT and only
forwards those ports you've told it to (and then, each port only goes to
one machine) port scanners can't find your machines because nothing
responds to their attempts to connect. And, of course, even if you have
malware trying to act as some sort of server it won't do any good unless
your machine initiates the connection. No, this isn't a firewall, but
it's better than having your box sitting on the net completely exposed.
Consider NAT as one layer of protection in a properly designed and
implemented defense in depth.
NAT is a combination of a stateful firewall and a packet mangler (that
changes the IP+port fields). A stateful firewall without a packet
mangler (i.e. no NAT) is just as secure.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
11:41 a.m.
On 12/27/2010 09:15 AM, Patrick O'Callaghan wrote:
Actually IIRC you have that the wrong way round. NAT was invented to
deal with address space exhaustion, and had the side-effect of hiding
machines behind the router.
Before somebody steps in again to point out that NAT isn't a firewall,
I'd like to give my perspective on it. If your router uses NAT and only
forwards those ports you've told it to (and then, each port only goes to
one machine) port scanners can't find your machines because nothing
responds to their attempts to connect. And, of course, even if you have
malware trying to act as some sort of server it won't do any good unless
your machine initiates the connection. No, this isn't a firewall, but
it's better than having your box sitting on the net completely exposed.
Consider NAT as one layer of protection in a properly designed and
implemented defense in depth.
11:15 a.m.
On Sun, 2010-12-26 at 17:11 -0500, Genes MailLists wrote:
Historically, we used nat for 2 purposes:
(1) to shield inside machines
(2) free up ipv4 (was an accidental consequence of (1)
Actually IIRC you have that the wrong way round. NAT was invented to
deal with address space exhaustion, and had the side-effect of hiding
machines behind the router.
poc
6:56 a.m.
--- 夜神 岩男 <supergiantpotato(a)yahoo.co.jp> wrote:
--- S Mathias <smathias1972(a)yahoo.com> wrote:
> Are there any active project about it?
>
> like:
> http://www.camrdale.org/apt-p2p/
> for Debian.
>
> Why doesn't it have viability? Why does it have?
>
> What are the security issues regarding it?
So long as it is easily configurable for the
user/admin
(many of my Gnome installations are in the office,
and I
wouldn't want them all responding to p2p requests
through
my network, for example) this would be a good idea.
A natural evolution of what happened with git...
-Iwao
I failed to remark that *forced* updates, of any kind, are
wrong. Just bad wrong. Always.
What I meant above was that a p2p storage and distribution
model makes good sense and should be explored. After all,
several of us have implemented local repositories to speed
things for similar reasons -- why not extend that speed to
the rest of the neighborhood (so to speak).
The activity of distributing package data can be separated
from the actual update action -- so there is no reason to
force updates. I can serve update package data I don't
have installed.
-Iwao
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
6:33 a.m.
--- S Mathias <smathias1972(a)yahoo.com> wrote:
Are there any active project about it?
like:
http://www.camrdale.org/apt-p2p/
for Debian.
Why doesn't it have viability? Why does it have?
What are the security issues regarding it?
So long as it is easily configurable for the user/admin
(many of my Gnome installations are in the office, and I
wouldn't want them all responding to p2p requests through
my network, for example) this would be a good idea.
A natural evolution of what happened with git...
-Iwao
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
6 a.m.
On Sunday 26 December 2010 22:11:17 you wrote:
On 12/26/2010 02:40 PM, Marko Vojinovic wrote:
> The only permanent solution to usability of p2p in general is IPv6, where
> all addresses will be public and thus accessible from outside. And IPv6
> would fix other protocols broken by introduction of NAT, not just p2p
> stuff.
Why would anyone want all internal machines public anyway ?
Historically, we used nat for 2 purposes:
(1) to shield inside machines
(2) free up ipv4 (was an accidental consequence of (1)
There was a quite large thread on the CentOS list recently about this.
In a nutshell, the conclusion is that (1) is an urban legend --- NAT does
not (and moreover, should not ) shield your inside machines from outside
attacks. You still need to use the proper firewall for shielding.
The only benefit of NAT is (2), ie. artificially enlarging the scope of
available v4 IP numbers, at the price of breaking functionality. And this is
not a consequence of (1), but rather the primary reason why NAT was introduced
in the first place.
After IPv6 gets introduced, the number of available IP addresses will be more
than enough to eliminate any need for NAT, while for security you'll still use
the same firewall as you needed to do with IPv4. The net gain is that protocols
that were broken by NAT will not be broken anymore, in addition to the larger
address space.
Of course, some people will remain dense forever and keep implementing NAT
even in IPv6, with an illusion that it will improve their security. Those
people cannot be helped, unfortunately... ;-)
Best, :-)
Marko
5:58 a.m.
On Sunday 26 December 2010 22:11:17 you wrote:
On 12/26/2010 02:40 PM, Marko Vojinovic wrote:
> The only permanent solution to usability of p2p in general is IPv6, where
> all addresses will be public and thus accessible from outside. And IPv6
> would fix other protocols broken by introduction of NAT, not just p2p
> stuff.
Why would anyone want all internal machines public anyway ?
Historically, we used nat for 2 purposes:
(1) to shield inside machines
(2) free up ipv4 (was an accidental consequence of (1)
There was a quite large thread on the CentOS list recently about this.
In a nutshell, the conclusion is that (1) is an urban legend --- NAT *does*
*not* (and moreover, *should* *not* ) shield your inside machines from outside
attacks. You still need to use the proper firewall for shielding.
The only benefit of NAT is (2), ie. artificially enlarging the scope of
available v4 IP numbers, at the price of breaking functionality. And this is
not a consequence of (1), but rather the primary reason why NAT was introduced
in the first place.
After IPv6 gets introduced, the number of available IP addresses will be more
than enough to eliminate any need for NAT, while for security you'll still use
the same firewall as you needed to do with IPv4. The net gain is that protocols
that were broken by NAT will not be broken anymore, in addition to the larger
address space.
Of course, some people will remain dense forever and keep implementing NAT
even in IPv6, with an illusion that it will improve their security. Those
people cannot be helped, unfortunately... ;-)
Best, :-)
Marko
1:26 a.m.
On Sun, 2010-12-26 at 17:11 -0500, Genes MailLists wrote:
Why would anyone want all internal machines public anyway ?
Not so much *made* public, but directly connected in a way that doesn't
block access. Various internet activities require two-way
communication, and NAT gets in the way. Either in a way that's simply
annoying to have to work around, or next to impossible to do so.
Historically, we used nat for 2 purposes:
(1) to shield inside machines
(2) free up ipv4 (was an accidental consequence of (1)
Not from many users' point of view. Historically, we've used NAT
because we wanted a multi-PC LAN when our ISP only allows us one public
IP. With your (1) being an accidental consequence, or advantage,
depending on your point of view.
And from an ISP's point of view, NAT's were used because they didn't
have enough real IPs for their clients, as a main reason. Likewise for
using them internally, to not waste their precious public IPs. They
didn't do it to give users a pseudo-firewall, either.
I need to read about ipv6 - but can I keep (1) with ipv6 ? i.e.
machines inside access to internet similar to what they have now via
firewall/nat ... but no way for those ipv6 addresses to be seen SYN'd
from outside.
You can use IPv4 and IPv6 concurrently. Indeed, for some time, you'll
have to have both. And you have the fun and games of maintaining
firewall rules for both, independently.
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
4:57 p.m.
theoretically there are Unique Local Addresses (ULAs)
http://www.ripe.net/ipv6-address-types/
but i think when ipv6 will be widely used [don't know when:D we got about: 49 days?
hmmm... - https://ipv6.he.net/statistics/ ] "they" want that, that every
computer must have a public ipv6 address, so that it can be natively accessible by the
"outside world" [fixme] - so computers must have good firewalls... i hope that
all the distributions, linux, bsd, everything will come with these default firewall
settings in the future, to ensure security, e.g.:
http://pastebin.com/raw.php?i=UNLPSECr
--- On Sun, 12/26/10, Joe Zeff <joe(a)zeff.us> wrote:
From: Joe Zeff <joe(a)zeff.us>
Subject: Re: Let's talk about yum and p2p in Fedora
To: "Community support for Fedora users" <users(a)lists.fedoraproject.org>
Date: Sunday, December 26, 2010, 10:28 PM
On 12/26/2010 02:11 PM, Genes
MailLists wrote:
> I need to read about ipv6 - but can I
keep (1) with ipv6 ? i.e.
> machines inside access to internet similar to what
they have now via
> firewall/nat ... but no way for those ipv6 addresses
to be seen SYN'd
> from outside.
AIUI, there are IPv6 address ranges designated for
that. And, even
better, there's no reason that your LAN can't still be on
IPv4 on a
non-routable range while you're router's on IPv6 to the
rest of the world.
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
4:53 p.m.
On 12/26/2010 05:28 PM, Joe Zeff wrote:
On 12/26/2010 02:11 PM, Genes MailLists wrote:
> I need to read about ipv6 - but can I keep (1) with ipv6 ? i.e.
> machines inside access to internet similar to what they have now via
> firewall/nat ... but no way for those ipv6 addresses to be seen SYN'd
> from outside.
AIUI, there are IPv6 address ranges designated for that. And, even
better, there's no reason that your LAN can't still be on IPv4 on a
non-routable range while you're router's on IPv6 to the rest of the world.
Cool thanks - its time .. i need to learn ipv6 ;-) its almost upon me ..
4:28 p.m.
On 12/26/2010 02:11 PM, Genes MailLists wrote:
I need to read about ipv6 - but can I keep (1) with ipv6 ? i.e.
machines inside access to internet similar to what they have now via
firewall/nat ... but no way for those ipv6 addresses to be seen SYN'd
from outside.
AIUI, there are IPv6 address ranges designated for that. And, even
better, there's no reason that your LAN can't still be on IPv4 on a
non-routable range while you're router's on IPv6 to the rest of the world.
4:11 p.m.
On 12/26/2010 02:40 PM, Marko Vojinovic wrote:
The only permanent solution to usability of p2p in general is IPv6,
where all
addresses will be public and thus accessible from outside. And IPv6 would fix
other protocols broken by introduction of NAT, not just p2p stuff.
But until then, p2p can never be completely reliable/available to everyone, as
http is now.
Why would anyone want all internal machines public anyway ?
Historically, we used nat for 2 purposes:
(1) to shield inside machines
(2) free up ipv4 (was an accidental consequence of (1)
I need to read about ipv6 - but can I keep (1) with ipv6 ? i.e.
machines inside access to internet similar to what they have now via
firewall/nat ... but no way for those ipv6 addresses to be seen SYN'd
from outside.
5:16 p.m.
On Monday 27 December 2010 18:14:25 Tom H wrote:
On Mon, Dec 27, 2010 at 12:41 PM, Joe Zeff <joe(a)zeff.us>
wrote:
> On 12/27/2010 09:15 AM, Patrick O'Callaghan wrote:
>> Actually IIRC you have that the wrong way round. NAT was invented to
>> deal with address space exhaustion, and had the side-effect of hiding
>> machines behind the router.
>
> Before somebody steps in again to point out that NAT isn't a firewall,
> I'd like to give my perspective on it. If your router uses NAT and only
> forwards those ports you've told it to (and then, each port only goes to
> one machine) port scanners can't find your machines because nothing
> responds to their attempts to connect.
Oh, but the scanner *will* get a response, that's the whole point of port-
forwarding. A scanner sends out a bait, NAT forwards it to appropriate server,
the server responds, NAT forwards the response back to the scanner.
This way the scanner can find out about all your open ports on all servers
behind your NAT, by scanning only one machine (the one facing the internet).
This is actually an added benefit for the scanner, courtesy of NAT. :-)
> And, of course, even if you have
> malware trying to act as some sort of server it won't do any good unless
> your machine initiates the connection.
If malware has infected one of your machines, it typically *will* initiate the
connection (calling-home), and the NAT will do nothing to prevent
communication in that case.
> No, this isn't a firewall, but
> it's better than having your box sitting on the net completely exposed.
If you have a firewall (and you need one both with and without NAT), the
machine is never completely exposed. NAT doesn't add any security beyond the
firewall.
> Consider NAT as one layer of protection in a properly designed
and
> implemented defense in depth.
As I heard somewhere, NAT is usually compared to Japanese paperwall, defense-
wise. IOW, zero protection.
NAT doesn't have anything to do with security.
In your example above, what's the difference between scanning your NAT
box for open ports and having them forwarded by the NAT box to a box
on your internal network or scanning a publicly accessible box on your
internal network directly?
The firewall's the only defense in both cases.
Well, there is a slight difference, which makes NAT even *less* secure than the
non-NAT solution. :-)
Namely, in the case of having several servers with public IP's behind a
firewall (ie. no NAT), the attacker needs to know the IP of each particular
machine he wants to attack.
However, in the case of having several servers with local IP's behind a NAT
and a firewall (with appropriate port-forwarding to each server), the attacker
needs to know *only* your single public IP, and he can successfully attack all
of the servers behind a NAT through that one.
So, the attacker has a (slightly) easier job if you do have NAT than if you
don't. Other than that, there is absolutely no difference, and the firewall is
the only true line of defense, as you remarked.
Best, :-)
Marko
4865
days inactive
4868
days old
22 comments
10 participants
participants (10)
-
Bill Davidsen -
Chris Adams -
Genes MailLists -
Joe Zeff -
Marko Vojinovic -
Patrick O'Callaghan -
S Mathias -
Tim -
Tom H -
夜神 岩男