Prev: Pazera Free Audio Extractor 1.3.
Next: [UPDATE] Thunderbird v3.1.2
From: HTH on 10 Aug 2010 06:44
"za kAT" wriggled and squirmed and then posted this bollix:

>"A NAT router ... is a stand-alone device..."

Wrong again, boyo.

Whilst a NAT router has nowt directly to do with AV as I have previously
explained to you, it hasn't stopped you from trying to muddy the functions
of each to change the subject of debate, as you dig yerself deeper into
the hole you've dug. Dear oh dear.

A NAT router sits between your Internet connection and your LAN (or
single PC), so is NOT a "stand-alone device" as you now assert.
Didn't they teach you that at "PC Support Primary School For IT Dorks"?

Go ask for your money back...


[slime binned]

HTH

From: HTH on 10 Aug 2010 12:20
BB wrote:
>To be honest, I am trying to understand. The only difference I see at
>this point is the front door analogy.

That's fine.

>That all seems reasonable to me, and I agree most people have very
>little confidence to configure NAT. I understand it as all uncalled
>incoming packets are blocked by default.
...
>
>When you call (as in go to) a website or IP address. NAT allows a
>response.


Eggsactly. Here's a simplified sequence of actions that occur when you
use a browser with a NAT router to make a "solicited" request:

1.user issues a browser request from (eg) LAN IP <198.2.0.2:1267> to
load www.whathappened.com, which then goes to the router. The LAN IP
will usually be fixed but the port used by the browser will vary, but
this is not important.

2.the router checks to see if the domain requested matches any entry
in its 'blocked list' maintained by user admin. If it does, the
requesting packet is dropped and an error screen sent back to
LAN IP <198.2.0.2:1267> by the router. No further action is taken.

Example of adding domains to NAT router blocked list:
<http://safe.webhop.net:8080/NAT_router_block.jpg>

Example of error screen issued when user requests a blocked domain:
<http://safe.webhop.net:8080/Website_Blocked.jpg>

3.otherwise, the router sends www.whathappened.com to the DNS server
loaded into its configuration by user admin, requesting the IP
address of the domain being requested by the user.

4.upon receipt, the router creates an entry in its NAT table containing
LAN IP <198.2.0.2:1267> PLUS the IP address the user has requested to
load. Router then fires off the request to the remote server with the
router's External IP address attached for use by the remote server
when responding.

5.when the remote server responds, the router matches where it's come
from to its NAT tables and passes the packet to the LAN machine that
requested it, in this case IP <198.2.0.2:1267>. If no positive match
is found in the NAT table, the incoming packet is dropped, never to
be seen again. Either way, no further action is taken.


Port Forwarding is an addition to this process which allows the user to
receive "unsolicited" packets from external users, necessary if you're
running a server of some sort (eg: FTP, WEB, File). It simply amounts
to configuring the router so that all incoming packets for Port:XXXX
should be forwarded to LAN IP:XXXX, where your server s/w is sitting
ready and waiting to serve up stuff.

The two URLs above are examples of port forwarding being used. The file
server here sits on port 8080 so all incoming packets requesting that
port number will be forwarded to our local file server LAN machine.
But of course the NAT router allows lists of IP addresses to be blocked
from accessing that LAN port (and all other ports come to that). The
exact process for setting up port forwarding on a NAT router will vary
from one box to another but is not difficult.

The server s/w also allows blocking IP addresses. But IMHO it's better
to block them at router level than leave them for the server s/w to do
it, although the server s/w is pretty darned bombproof - nobody has
ever got through its native security, many have tried.

>Which makes sense and is like the front door analogy I made. Although
>I'm not sure about how incoming or outgoing traffic eludes the PFW.

It *does* and *can* happen. Afaik it usually involves malware shutting
down the PFW or otherwise deactivating it, thereby leaving the host
machine vulnerable. OTOH I am not aware of any instance of a NAT router
being bypassed or deactivated.

>Yes, I understand language. Bypassing a PFW still eludes me a bit, and
>Robin Keir calls it FireHole. Even so, I don't see how a NAT router
>would prevent even this. According to my understanding of what Robin
>says, is he still goes through the PFW, just tricks it into thinking
>it is reliable traffic. http://keir.net/firehole.html

That's a good article but relates to PFWs, not NAT routers. In fact it
actually refers to a browser being hijacked by malware. If your browser
is hijacked by that method, the router won't help you any more than a
PFW, so it's not a safety comparison between a PFW and a NAT router.

It has everything to do with being vigilant in disallowing malware to
run on your system. An important comment in the article is:

"This, and all similar techniques rely on a rogue program getting
onto your system and executing."

>Sorry...no. Only because I don't understand enough about bypassing the
>PFW. My thoughts are still both do about the same thing...which is
>block all unwanted inbound traffic and block outbound traffic via
>rules you set up...which means you have to identify it. That part is
>what is blurry for me when you say calls are made out /around/ a PFW
>that I would never know about, but not so with a router. I suppose it
>makes sense because your ethernet cable goes into the router, then out
>to your computer and the PFW sits a bit away from that....but I don't
>actually understand that part.

See above. Afaik no reported instances of routers being bypassed exist.
I'm not sure how it could be given that all incoming/outgoing packets
have to pass thru it and its firmware. But I accept that nothing is
100% secure and some malware author may find a way of taking control
of a NAT router. But for what purpose?...you shouldn't have malware
running on your machine in the first place! See Kier's comment above.
The most likely situation is that you install and run malware on your
system which (eg) hijacks your browser, and all bets are off.

>I get enough of this diatribe to agree that a NAT router is likely
>better than a PFW though I'm not convinced the difference is greatly
>significant and considering the lack of knowledge or willingness to
>apply the effort (little as it may be) of many to actually configure
>outbound calls on a NAT router with the techniques you state which is
>where the major resistance to all of this is I think.

Fair comment. My view is that every additional piece of s/w you have
running on a machine adds to its complexity and potential for crashing
etc. PFWs are notorious for crashing (ZA anybody?) and can be just as
complex to configure as a NAT router. There is also the issue raised by
Kier's article in that if a malware program adopts the same name/CRC as
the genuine module, it may fool the PFW into letting it through. Then
there is the issue of malware bypassing the PFW! I put more trust in a
NAT router than a PFW.

>Many PFW's offer a simple way to block the outgoing call with an alert
>and a click.

Providing the malware doesn't bypass the PFW.

>Calls that are disguised as Robin speaks of, would go through a NAT
>router also wouldn't they?

Yes.


HTH

From: HTH on 11 Aug 2010 11:12
BB wrote:
>I understand now what you mean when you say 'bypass' is not that it
>goes around it, but shuts it down/disables it.

AFAIK that's what usually happens.

>If that happened, I would get a security alert from my system eh? I
>would then know something happened.

I'm not sure where an alert would come from. Real time AV s/w maybe?

>OK, I get it and at this point have to agree that a NAT router would be
>a better tool than a PFW. I am using a NAT router (wireless Linksys)
>but hard wired to it most of the time. I have no configured and
>outbound call restrictions and get no alerts of the attempts from it.
>I would have to always use the techniques you describe to always
>monitor for such, then identify and set up a rule. I'll experiment
>with it.

I think on incoming packets a NAT does a better job and it doesn't make
a lot of sense to duplicate by using a PFW. On outgoings, it's really
a matter of personal choice. Many people do feel comfortable getting a
pop-up alert when a program tries to call home. Both can control them
using different techniques but both have weaknesses when malware enters
the equation. In the case of a PFW, it may happen w/o the user even
knowing about it if the malware bypasses the PFW. In the case of a NAT,
it can be prevented by running a prog like Active Ports and hitting the
kill button for any unexpected connection process that's going on.
But the rule is: keep malware of the machine!

In 5 months without PFWs we have had no bad experiences on 4 machines
running two file servers etc, hard wired to a NAT router. Plenty of
attacks/accesses taking place all the time but all dealt with perfectly
by the router. Experimentation is certainly something to consider.


HTH

From: za kAT on 11 Aug 2010 15:24
On Wed, 11 Aug 2010 17:12:13 +0200, HTH wrote:

> Both can control them
> using different techniques but both have weaknesses when malware enters
> the equation. In the case of a PFW, it may happen w/o the user even
> knowing about it if the malware bypasses the PFW. In the case of a NAT,
> it can be prevented by running a prog like Active Ports and hitting the
> kill button for any unexpected connection process that's going on.

Yes, of course it can. Laughable.

--
zakAT(a)pooh.the.cat - Sergeant Tech-Com, DN38416.
Assigned to protect you. You've been targeted for denigration!
From: Ari Silverstein on 11 Aug 2010 15:25
On Wed, 11 Aug 2010 17:12:13 +0200, HTH wrote:

> In 5 months without PFWs we have had no bad experiences on 4 machines
> running two file servers etc, hard wired to a NAT router. Plenty of
> attacks/accesses taking place all the time but all dealt with perfectly
> by the router.

Then you are lucky. A request to a malware infected site will lay you
out, no doubt about it. There is no way to keep morons on server
systems from doing exactly that unless you are restricting them to
Intranet and Milnet only and no Internet access.

Which is how the much of the US military accomplishes their security.

> Experimentation is certainly something to consider.

It's an absolute must.

Hummer, you and Stubbo are arguing the wrong side of the equation. the
primary concern is always in handling user activity. If you can't
handle/restrict, then you have to define it. Once defined, the choice
of PFW, router constraints or both becomes obvious.

Typically, it is both or some variation of both.
--
Ari Silverstein, C.T.A; C.T.A.S, FREE Cruise Travel Advisory Services
Sign up for special email deals @ www.CruiseQuick.com - Sells more
cruises than 99% of the agencies in America. (not affiliated)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Pazera Free Audio Extractor 1.3.
Next: [UPDATE] Thunderbird v3.1.2