NAT is not a mechanism for securing a network.. but.. HELP! - Page 3

Archived from groups: comp.security.firewalls (More info?)

Leythos wrote:

> And you can have a firewall without NAT, but having a NAT does not mean
> you have a firewall.

Iam glad you mentioned that so to be able to clear if the unsolicted
inboud traffic nlocking ability of NAT router hs to do soemthing with
NAT or not.

As me and Moe Trin agreed in another thread we simplistically acceptes
that

NAT/IP Masquerading = Source NAT
NAT/Port Forwarding = Destination NAT

So we see that NAT doea and stands for Network Address Translation
which mean actually IP adress translation. I think its only this and
nothing more.
Changing the source ip address of an internbal host to routers external
and then changinf the replys dest ip address from routers external to
an inside host ip address.

For me thats NAT.

The ability of blocking ALL uninvited incoming traffic request is being
implementing by an entity/characteristic of the router different than
NAT.
And i beleive that this is actually the job of a firewall.

Correct me if iam wrong but i think we need to seperate in a clear way
these 2 consepts because there is a huge discussion concernign them
about what helps in security and whats not.

Also i would like somene to tell me if SPI is a part of NAT or a
differnet procedure/function

Thank you.

> I suppose you've never seen NAT setup as 1:1 mode? How about NAT that
> defaults to 1:1 all ports passed inbound?

Can you tell me a bit more on this please?

Archived from groups: comp.security.firewalls (More info?)

Volker Birk wrote:
> Nicky <hackeras@gmail.com> wrote:
> > > Just try it yourself. Take a simple masquerading device, send from outside
> > > a spoofed packet, which seems to come from inside,
> > Ummm, how can a packeta send directly from the internet could have as
> > source address an ip address of an internal lan host?
>
> It can have it, if you spoof the address.

But if a remote host will try to send a packet with a valid destination
ip (for example my external routers one) but a source ip address of
lets say 10.0.0.1 then the packet will be rejected from the first isp
router it meets(if properly configures) because although the packet can
be routed to reach its final destination, yet a reply wont be able to
come back to the sender since he is using a private non-routable ip
address!

> > The source address of the packet would be the one that the sending
> > remote host would have!
> > Can you please explain?
>
> Yes. The operating system usually creates the IP packages. The operating
> system's implementation of the TCP/IP protocol family inserts a correct
> source address automatically.
>
> But you also can use a so called raw socket. This is a technic, with wich
> you can build your own packages, and have influence on anything they
> consist of. So you can build your own packages with a spoofed IP address
> as the source address.

Yes, but same as above, how you will send that packet to its
destination?

> Or you can use packet generator software, which already can do this for
> you, and you don't need to program. A sample for such a software is
> hping.
>
> > > So getting no information back is a sure sign, that there _is_ a computer
> > > on the other side, and it's running braindead "security" software like
> > > Zonealarm ;-)
> > Well yes, but what if a router also doesnt exist at the specific ip
> > address and in generally there is no host at all?
> > Then we will have no reply back at all sicne there is nonone to respond
> > as RFC suggests.
>
> Oh yes, we have. We have it from the router before then.

You mean that just the previous hop(router) will notify that there is
no network after him, so the intruder will still get back a response?

Its logical yes, buth i wonder doesn the companies know that this
reason its too apparent to claim otherwise?

Archived from groups: comp.security.firewalls (More info?)

Nicky <hackeras@gmail.com> wrote:
> But if a remote host will try to send a packet with a valid destination
> ip (for example my external routers one) but a source ip address of
> lets say 10.0.0.1 then the packet will be rejected from the first isp
> router it meets

Usually not. Try it out. Most ISPs don't filter this way.

> > > Well yes, but what if a router also doesnt exist at the specific ip
> > > address and in generally there is no host at all?
> > > Then we will have no reply back at all sicne there is nonone to respond
> > > as RFC suggests.
> > Oh yes, we have. We have it from the router before then.
> You mean that just the previous hop(router) will notify that there is
> no network after him, so the intruder will still get back a response?

Yes. Just read the RFCs I referenced.

> Its logical yes, buth i wonder doesn the companies know that this
> reason its too apparent to claim otherwise?

Sorry, I really don't know, if the "Personal Firewall" manufacturers
are incompetent or if they're lying.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

Archived from groups: comp.security.firewalls (More info?)

Nicky <hackeras@gmail.com> wrote:
> NAT/IP Masquerading = Source NAT
> NAT/Port Forwarding = Destination NAT

I'd agree with those definitions.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

Archived from groups: comp.security.firewalls (More info?)

In article <1125067607.593621.114260@z14g2000cwz.googlegroups.com>,
hackeras@gmail.com says...
> For me thats NAT.
>
> The ability of blocking ALL uninvited incoming traffic request is being
> implementing by an entity/characteristic of the router different than
> NAT.
> And i beleive that this is actually the job of a firewall.

Blocking is part of a firewall, but it can also be part of other things
that are not firewalls. So, just because something is blocked, that does
not mean the blocker is a firewall.

> Correct me if iam wrong but i think we need to seperate in a clear way
> these 2 consepts because there is a huge discussion concernign them
> about what helps in security and whats not.

NAT doesn't have to block anything in either direction. You can have a
1:Many NAT solution (like the Linksys, D-Link, etc...) where all ports
inbound are forwarded to a specific IP - which means there is no
blocking in either direction.

> Also i would like somene to tell me if SPI is a part of NAT or a
> differnet procedure/function

SPI can be added to NAT devices, it's not included just because the
device does NAT, the vendor has to include it.


--

spam999free@rrohio.com
remove 999 in order to email me

Archived from groups: comp.security.firewalls (More info?)

In article <ileug1lacnddq9ibu578ldrj4ek0uo43f7@news.easynews.com>,
CyberDroog@ClockworkOrange.com says...
> Yes, I believe that a simple NAT router is a basic attempt at firewalling a
> system. About as much as the average home user will ever do. It's *their*
> firewall, whether you like it or not.

So, lets call the users Toaster a firewall, since it technically can
produce enough heat to create a fire near a wall in the house. See, if
we don't educate users they will continue to think those devices are
firewalls, and they will continue to allow the sales/marketing types to
get away with it.

--

spam999free@rrohio.com
remove 999 in order to email me

Archived from groups: comp.security.firewalls (More info?)

Volker Birk wrote:

> "In computer networking, tunneling means the transmission of one data
> protocol encapsulated in another using a tunneling protocol. This technique
> often occurs in combination with encryption."
> (http://en.wikipedia.org/wiki/Tunnelling)

Too technical, perhaps soemone might put it in simples words or by
giuving an example.

Archived from groups: comp.security.firewalls (More info?)

So it has nothing to do with proxying?

A(me)-> proxy A-> proxy B-> B(dest)

Archived from groups: comp.security.firewalls (More info?)

On Fri, 26 Aug 2005 16:53:40 GMT, Leythos <void@nowhere.lan> wrote:

>In article <ileug1lacnddq9ibu578ldrj4ek0uo43f7@news.easynews.com>,
>CyberDroog@ClockworkOrange.com says...
>> Yes, I believe that a simple NAT router is a basic attempt at firewalling a
>> system. About as much as the average home user will ever do. It's *their*
>> firewall, whether you like it or not.
>
>So, lets call the users Toaster a firewall, since it technically can
>produce enough heat to create a fire near a wall in the house. See, if
>we don't educate users they will continue to think those devices are
>firewalls, and they will continue to allow the sales/marketing types to
>get away with it.

What is the difference if the S&M types (heh) get away with it? As far as
the home user in concerned, a NAT router is *their* firewall. It restricts
access somewhat.

By your, and Duane's, strict definition of a firewall, a home user is
rarely going to have one.

Note, I do see your point and understand why you want a strict definition.
So now maybe you see my point in not thinking it's all that important. For
the good of the net, at least many home users are using *something*.

--
Giving government money and power is like giving car keys and whiskey to a
teenage boy.

- P.J. O'Rourke

Archived from groups: comp.security.firewalls (More info?)

In article <cssug1tg85b854jg9uv74undtnl56df7cg@news.easynews.com>,
CyberDroog@ClockworkOrange.com says...
> What is the difference if the S&M types (heh) get away with it? As far as
> the home user in concerned, a NAT router is *their* firewall. It restricts
> access somewhat.
>
> By your, and Duane's, strict definition of a firewall, a home user is
> rarely going to have one.

And why is that a bad thing - the only reason they call them Firewalls
is to that ignorant people will purchase them. In the days when they
first came out they called them CABLE/DSL ROUTERS, then, without any
change in the firmware or functions, about 6 months later, they started
packaging them as "Firewalls".... See the history here.... Poeple will
buy it if you sell it as some BUZZ word they think they need.

Don't get me wrong, I recommend NAT Routers to ALL home users with DSL
or Cable, and I was installing "LAN MODEMS" long before there ever was
DSL or CABLE service - LAN Modems are single unit boxes with a NAT
router and a modem and a 1 or more port HUB - 3COM use to make them and
they did great to protect Dial-Up users from inbound (as do the
Cable/DSL routers), but they were not and are not firewalls.

> Note, I do see your point and understand why you want a strict definition.
> So now maybe you see my point in not thinking it's all that important. For
> the good of the net, at least many home users are using *something*.

You seem to think I want a "stricter" definition when in reality, until
those lamers started calling NAT devices firewalls, it was always
understood that NAT does not make a device a firewall. It's those
supporters of NAT being a firewall that are "watering down" the
definition of what a Firewall is.

The real problem is that people think these devices ARE firewalls and
that they are getting the same protection that their company firewall
give them - even though they have no idea what kind of protection that
is.

If you don't object to a Yugo being called a Space Shuttle I can see why
you don't object to a NAT Router being called a Firewall.


--

spam999free@rrohio.com
remove 999 in order to email me

Archived from groups: comp.security.firewalls (More info?)

<PLANK> to you too.

Duane

Archived from groups: comp.security.firewalls (More info?)

"Volker Birk" <bumens@dingens.org> wrote in message news:430edb3f@news.uni-ulm.de...
> Stuart McGraw <smcg4191zz@friizz.rimoovallzzs.com> wrote:
> [NAT attack]
> > > Just try it yourself. Take a simple masquerading device, send from outside
> > > a spoofed packet, which seems to come from inside, and sniff inside, if the
> > > packet is routed. There is enough spoofing software in the wild, so you
> > > can hack this simple task with BSD sockets yourself, or you could use
> > > ready-made software to generate the packets.
> > I'll try if I can, but the only outside network I have access to right now
> > is my ISPs and I think they do ingress/egress filtering so I may not be able
> > to.
>
> Most ISPs don't.

FWIW, I came across this, according to which about 25% of the internet
is spoofable.
http://spoofer.csail.mit.edu/summary.php
http://www.mit.edu/~rbeverly/paper [...] ruit05.pdf

Archived from groups: comp.security.firewalls (More info?)

>>
>> >If you don't object to a Yugo being called a Space Shuttle I can see why
>> >you don't object to a NAT Router being called a Firewall.
>>
>> The Yugo and the Space Shuttle are both forms of transportation. They
>> serve, to a greater or lesser degree, in the process of getting from
>> point
>> A to point B.
>>
>> No one would insist that a Yugo isn't a "vehicle". They are both
>> vehicles.
>
> And that's the point - they both can do some things in common, but no
> one would ever make the false assumption that the Yugo is a space
> capable vehicle - which is the point about NAT Routers and Firewall
> Appliances. The common point is Routing, not protection.
>

You might as well be talking to a brick wall.

Duane

Archived from groups: comp.security.firewalls (More info?)

Nicky <hackeras@gmail.com> wrote:
> > "In computer networking, tunneling means the transmission of one data
> > protocol encapsulated in another using a tunneling protocol. This technique
> > often occurs in combination with encryption."
> > (http://en.wikipedia.org/wiki/Tunnelling)
> Too technical, perhaps soemone might put it in simples words or by
> giuving an example.

Hm... ;-)

For example, an IP packet is data only, as everything, a computer works
with, is just data.

So, if I can send data and receive data, I can send and receive IP
packages. For example, I can send IP packages with simple email.

This works, because IP packages are binary data, which can be stored
in a file. And the file can be an attachement to an email, for example.

So what we need are two tunnel endpoints, two tunneling gateways. Each one
must be a software program, which "listens" on a usual network interface
for IP packages, stores every packet in a file, and sends this as an
attachement to the other side. If it receives an email with such an
attachement then reads the file, and sends such an IP packet through the
usual network interface.

By this example, you have a simple tunnel for IP packets ("Internet
connection" ) through common email.

You can tunnel everything through everything. Alexander's wwwsh for
example tunnels a simple terminal protocol (remote shell) through
Windows messages and HTTP.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

Archived from groups: comp.security.firewalls (More info?)

Sorry but still tunneling is not clear to me, only proxying is clear.

Archived from groups: comp.security.firewalls (More info?)

"Nicky" <hackeras@gmail.com> wrote:
>Sorry but still tunneling is not clear to me, only proxying is clear.

With a proxy, each packet is modified to change the IP addresses
and ports but uses the same protocol (e.g., TCP, UDP, etc).

With a tunnel, each packet is used as the data load to form a
packet for a different protocol. A trivial (and unlikely)
example would be if we have the TCP protocol but not the UDP
protocol and want to be able to run programs that use UDP. We
build a "tunnel", where UDP packets are actually sent using the
TCP protocol.

A tunnel fakes one protocol, and instead uses a mutually
exclusive alternate protocol.

To understand why that is done, perhaps understanding the
layered approach to networking is required. All communications
links have various layers of protocols...

You've probably heard of the "OSI Layered Model" that labels 7
layers? And you've probably seen comparisons with TCP/IP, which
doesn't really have all 7 of those layers because it combines
some of them? Here is a comparison chart:


OSI Model Typical Internet Implementation

Application 7 --+
|
Presentation 6 |-- Application
|
Session 5 --+

Transport 4 ----- TCP / ICMP / RAW / UDP / OTHER

Network 3 ----- IPv4 / IPv6

Datalink 2 ----- Device Driver

Physical 1 ----- Hardware

Notice that each layer can have multiple /different/ protocols.
For example we have several "Transport" layer protocols to
choose from, and any given application might use TCP or ICMP or
UDP or one of the other (not listed) protocols. Some
applications may even allow the user to choose which protocol is
used.

At each layer the connection to the next layer is to one
specific protocol selected from the several that are available.

Here is a diagram of a typical example, which in this case is
the connection between a web client and a web server that are on
an Ethernet LAN.

Client Server
Host Host

Application Protocol
Web Client <- - - - - - - - - - -> Web Server Applications Layer
| |
| TCP Protocol |
TCP <- - - - - - - - - - -> TCP Transport Layer
| |
| IPv4 Protocol |
IP <- - - - - - - - - - -> IP Network Layer
| |
| Ethernet Protocol |
Ethernet <- - - - - - - - - - -> Ethernet Datalink Layer
Driver Driver
| |
| 10baseT Protocol |
Ethernet <- - - - - - - - - - -> Ethernet Physical Layer
NIC & Cable NIC & Cable
| (CAT5 cable) |
+----------------------------------+


Note that each "stack" of protocols is the same on both the
client and the server hosts. The dashed horizontal lines
represent "virtual connections" between the layers on each host,
and ideally the layers above any given dashed line do not know,
or care, about what is below that line. (That ideal situation
doesn't always exist though!)

Okay, so that is the way it is *supposed* to happen. Each layer
should be *totally* isolated from anything more than one layer
away from it. Hence an application would select TCP (as opposed
to UDP or ICMP etc) and then would not know or care what the
datalink layer actually was. The fact that it is Ethernet
rather than Token Ring or PPP is not supposed to make any
difference.

However, the fact is it *does* make a difference, and sometimes
we can't control that. Lets say you have an existing
implementation of protocol 'A' (in any of those layers), and
purchase a program that is fine tuned to run *only* when used
with protocol 'B', which is not available. That would be one
instance where a "tunnel" might be used. Rather than add a
/real/ protocol 'B', the program is provided with something that
looks like it comes from 'B', but it actually connects to your
existing 'A' protocol.

A really simple example would be if for some reason UDP was not
available (perhaps a mid-link firewall does not allow UDP
packets). No problem, just write a UDP to TCP tunnel for each
end of the connection. The program expects UDP, so it thinks
the virtual connection will look like this:

Client Server
Host Host

Application Protocol
Client <- - - - - - - - - - -> Server Applications Layer
| |
| |
UDP <- - - - - - - - - - -> UDP Transport Layer
| |
| |
IP <- - - - - - - - - - -> IP Network Layer
| |
~ ~

But since there is no usable UDP protocol available, but the TCP
protocol does work, a "tunnel" is put into place, and it ends up
looking like this:


Client Server
Host Host

Application Protocol
Client <- - - - - - - - - - -> Server Applications Layer
| |
| UDP Virtual connect |
UDP--+ <- - - - - - - - - - -> +--UDP
| | \
| | \
UDP-TCP TUNNEL UDP-TCP TUNNEL > Transport Layer
| | /
| TCP Virtual connect | /
TCP--+ <- - - - - - - - - - -> +--TCP
| |
| IP Virtual connect |
IP <- - - - - - - - - - -> IP Network Layer
| |
~ ~

What the tunnel actually does is _connect_ _between_ _two_ _protocols_
_in_ _the_ _same_ _layer_, and encapsulate the data from one into
appropriate data for the other. That usually means taking a
packet from the first protocol and using the entire packet as
the data load for a packet suitable for the second protocol.

A tunnel looks like one protocol to the layer above it, and like
a different protocol to the layer below it. In the above
example the Application Layer is dealing with UDP, while the
Network Layer below is talking to a TCP protocol.

The example of tunneling UDP through a TCP connection is perhaps
a bit far fetched, and probably is never done. But examples
where a tunnel actually is used are available for each layer.

For example, if we want to encrypt all of our data, regardless
of what program is used, we might replace the entire transport
layer with a tunnel. Each protocol would be available, but
instead of connecting directly to the Network Layer below, every
packet would then be encrypted, put into a TCP packet, and sent
on its way.

Another example is PPPoE, where we have an Ethernet, but want
the Network Layer to deal with certain Ethernet frames as if
they come from a PPP connection.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

Archived from groups: comp.security.firewalls (More info?)

Floyd L. Davidson wrote:
[tunnel explnataion]

Thanks a lot Floyd!
Indeed is a very intersting subject!

Archived from groups: comp.security.firewalls (More info?)

In article <hh51h15ff406mnepiak046rglc527ah367@news.easynews.com>,
CyberDroog@ClockworkOrange.com says...
> On Sat, 27 Aug 2005 00:30:06 GMT, Leythos <void@nowhere.lan> wrote:
>
> >And that's the point - they both can do some things in common, but no
> >one would ever make the false assumption that the Yugo is a space
> >capable vehicle - which is the point about NAT Routers and Firewall
> >Appliances. The common point is Routing, not protection.
>
> Routing does offer a small measure of protection. Better than just
> plugging the cable modem into the back of the PC.

I've never disputed that, and encourage users to have at least a NAT
Router, but I never mistake a NAT router as a firewall.

--

spam999free@rrohio.com
remove 999 in order to email me

Archived from groups: comp.security.firewalls (More info?)

CyberDroog <CyberDroog@clockworkorange.com> wrote:
> >> Routing does offer a small measure of protection.
> >I cannot see that - could you explain, please?
> I was referring to a NAT router blocking unsolicited inbound traffic.

Ah, OK. You mean filtering.

Thanx,
yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

Archived from groups: comp.security.firewalls (More info?)

CyberDroog <CyberDroog@clockworkorange.com> wrote:
> As I said, since there is no legal definition of the term firewall (as
> there is for, say, a hamburger in the U.S.) the word will obviously be used
> to refer to the process of limiting access in one way or another.

There are standards:

A "firewall" is an agent which screens network traffic in some way,
blocking traffic it believes to be inappropriate, dangerous, or both.
(RFC 2979, Behavior of and Requirements for Internet Firewalls)

A NAT router with filtering capabilities is a firewall following this
definition.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

Archived from groups: comp.security.firewalls (More info?)

In article <4310f61c@news.uni-ulm.de>, bumens@dingens.org says...
> CyberDroog <CyberDroog@clockworkorange.com> wrote:
> > As I said, since there is no legal definition of the term firewall (as
> > there is for, say, a hamburger in the U.S.) the word will obviously be used
> > to refer to the process of limiting access in one way or another.
>
> There are standards:
>
> A "firewall" is an agent which screens network traffic in some way,
> blocking traffic it believes to be inappropriate, dangerous, or both.
> (RFC 2979, Behavior of and Requirements for Internet Firewalls)
>
> A NAT router with filtering capabilities is a firewall following this
> definition.

And if you don't believe my other post following this, then a Switch
with VLAN's is also a firewall - which we all know is not true.

--

spam999free@rrohio.com
remove 999 in order to email me

Archived from groups: comp.security.firewalls (More info?)

Leythos <void@nowhere.lan> wrote:
> > A "firewall" is an agent which screens network traffic in some way,
> > blocking traffic it believes to be inappropriate, dangerous, or both.
> > (RFC 2979, Behavior of and Requirements for Internet Firewalls)
> ...
> And if you don't believe my other post following this, then a Switch
> with VLAN's is also a firewall - which we all know is not true.

I cannot see that a Switch with VLAN is blocking any traffic. If I configure
port filtering on a device, this device definitly is blocking traffic.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

Archived from groups: comp.security.firewalls (More info?)

In article <1125241169.849282.176000@g44g2000cwa.googlegroups.com>,
hackeras@gmail.com says...
>
> Leythos wrote:
> > In article <1125227897.433705.252900@g44g2000cwa.googlegroups.com>,
> > hackeras@gmail.com says...
> > > Why did they add into NAT this "dont route inbound traffic capability"
> > > that makes people beleive that NAT is a firewall?
> >
> > They didn't "Add" anything to NAT, that's how it's suppose to work - if
> > it doesn't know where to send the packets, they just die.
>
> Aaah, yes....
> That makes veen cleared the fast that NATing isnt blocking anything but
> instead isnt routing.
>
> If the data coming to the router is a response to a previosuly
> initiated connection from an internal host (and NAT sees that by
> checking with its own NAT table, i guess by looking the incoming
> source iport of the packet if it matches the previously outgoing dest
> iport of the packet that send) then translste the dest ip and
> redirect the packet. Thats one case of routing.
>
> If an incoming packets comes as requesting a connection(meaning no NAT
> entry record) then look the port forwarding rules. if you find that we
> redirect such a port that the inbound packet wants then also route.
> Thats 2nd case of routing
>
> And third if NO NAT Entrry Record and NO Port forwarding rule also then
> NAT dont know wht to do with the packet and thus it doenst route it but
> simply ignore it. Thats what most people including me mistakenly used
> to beleive thats this is blocking the inbound traffic when it just is
> NOT ROUTING the incoming packet. Correct?

Yes, basically that's the idea.

> > NAT has several modes, one of them is 1:1 NAT, meaning no port blocking,
> > just map everything from 1 IP to another 1 IP, the method used in the
> > NAT Routers you purchase for home use doesn't even include the ability
> > to route multiple WAN IP's.
>
> 1:1 NAT = Static NAT = means 1 public ip address to 1 internal right?
> No needs for ports here.

it can be many WAN IP to MANY internal IP as long as it's mapped 1:1

> Dynamic NAT = 1 public ip address to many internal hosts. Here we need
> port seperations.
>
> I would like to ask about the source port of the originatin packet.
> lets say 10.0.0.1 want to communicate with soem wremote web server and
> we have Dynamic NAT cause we have a lot of hosts in our lan.
>
> how does tha NAT table looks like(in my case)?

You setup FORWARDING so that inbound port 80 goes to some location in
your LAN - you manually set this up, there is not automatic setup for
it.

The source outbound port doesn't mean anything, only the port the source
wants to connect to.

--

spam999free@rrohio.com
remove 999 in order to email me

Archived from groups: comp.security.firewalls (More info?)

On 28 Aug 2005 01:24:12 +0200, Volker Birk <bumens@dingens.org> wrote:

>CyberDroog <CyberDroog@clockworkorange.com> wrote:
>> As I said, since there is no legal definition of the term firewall (as
>> there is for, say, a hamburger in the U.S.) the word will obviously be used
>> to refer to the process of limiting access in one way or another.
>
>There are standards:
>
>A "firewall" is an agent which screens network traffic in some way,
>blocking traffic it believes to be inappropriate, dangerous, or both.
>(RFC 2979, Behavior of and Requirements for Internet Firewalls)
>
>A NAT router with filtering capabilities is a firewall following this
>definition.

That was my point. The side effect of NAT is packets not being routed if
there is nowhere to which to route them. The filtering may be minimal, but
it provides some degree of protection. Enough for the home users to which
the devices are marketed.

--
REPORTER, n. A writer who guesses his way to the truth and dispels it
with a tempest of words.

- Ambrose Bierce

Archived from groups: comp.security.firewalls (More info?)

Nicky <hackeras@gmail.com> wrote:
> > > 1:1 NAT = Static NAT = means 1 public ip address to 1 internal right?
> > > No needs for ports here.
> > Many implementations of static NAT allow to assign port/IP address pairs
> > each with another, not only IP addresses. This is why I asked, what our
> > friend meant with "1:1", because this usually means n*m : l*k.
> Why the need of a pair in Static NAT when we just need to translate one
> public ip address to an internal one?

It's uncommon to map just an IP address to another. Usually, you're
just mapping the ports for the services you want to be seen "outside".

> > > Dynamic NAT = 1 public ip address to many internal hosts. Here we need
> > > port seperations.
> > Usually, a port range on the masquerading interface is used as a reservoir
> > for assigning port/IP address pairs dynamically to them
> Why it doesnt use the same random port as 10.0.0.1 picked?

Because this perhaps will run into trouble, if 10.0.0.2 is connecting
at the same time.

> > together with some
> > connection tracking algorithms or even heuristics, so that those ports can
> > be deallocated again if not needed any more.
> I though the ability of the NAT router to detect if a packet from a
> remote host was a response to a previously initiated connection
> attempt from inside the lan was SPI.

If you mean stateful inspection with SPI here, yes. This is what I'm
referencing.

Of course, for protocols which use simple TCP sockets, no stateful
inspection is needed for connection tracking.

> Why doesnt both 10.0.0.1 and 217.0.116.71 use the same port number?

Because, if there are many hosts inside, then this could lead into
trouble.

> i assume 217.0.116.71 is the gateway of the router(the lan ip) but
> maybe you are mistaken cause this is not on the same subnet as 10.0.0.1

217.0.116.71 here is the address of the "outside" interface, and
10.0.0.1 is one of the addresses in the "inside" network.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"