Re: (NIS/NPF) Event log and other issues.

From: Joseph V. Morris (jvmorris@erols.com)
Date: 07/01/02 

From: "Joseph V. Morris" <jvmorris@erols.com>
Date: Mon, 1 Jul 2002 13:45:57 -0400

Tack,

Okay, this one just deals with the nmain.exe question.

"Tack" <nospam@tack.flyer.co.uk> wrote in message
news:MPG.178805f5b66c572a9896d0@news.cis.dfn.de...
| In n/g comp.security.firewalls, Joseph V. Morris says...
. . . .
| It seems that Symantec keeps truncating the beginning of thread to
| save space, hence the link changes almost every time I
| check it. I have posted a copy here...
|
| (begin link)
|
http://www.tack.flyer.co.uk/Why%20does%20nmain_exe%20bypass%20NIS-NPF%20(T
ack).htm
| (end link)

Okay, went to your site (much easier to find! <g> )

. . . .

| The above may best be re-summarised if you can get to that elusive
| link, but I will add that, in my instalation, NMain.exe will connect
| to the internet (without having to set any rules or permissions),
| when I click on 'NIS>Personal Firewall>Internet Access Control' with
| a live connection.

Hmmm, Tack, I remain a bit confused. How can you assert that it is, in
fact, connecting to the internet if you don't have any log entries? Are
you referring to your statement (from your site) that:

"No logs are recorded for nmain.exe except for the usual...

'An instance of "C:\PROGRAM FILES\COMMON FILES\SYMANTEC
SHARED\NMAIN.EXE" is preparing to access the Internet for the first
time' "

If so, that doesn't indicate an actual internet connection; it's basically
just a notification that an Internet-enabled application has been loaded
(indeed, you should see that for LOTS of applications in your firewall
event log). (That's a very poorly worded event log entry because it's not
always true for all applications.)

Now, there ARE rules for nmain.exe in the NIS Rules Settings (especially
if you're running at High Security -- which you should be -- and allowed
Automatic Firewall Rule Creation (or whatever they're calling it today)).
Here's one:
**********
Rule nnn Norton Program Integrator HTTP Rule
Category: General
Rule in use: YES
Logging: NO
Protocol: TCP
Action: Permit
Direction: Outbound
Application: (Symantec Norton Program Integrator)
..........Path: c:\...\nmain.exe
Local service: Any Service
Local Address: Any Address
Remote Service:
..........Port: 80
..........Port: 81
..........Port: 82
..........Port: 83
..........Port: 443
..........Port: 1080
..........Port: 8080
..........Port: 8088
..........Port: 11523
Remote Address: Any Address
**********

You'll note that this rule has absolutely nothing to do with DNS lookup
(port 53). If you want to see if this rule is actually being invoked,
then ENABLE logging on it. If you find any such events (after enabling
logging), you might want to check on just where they're going. I would
suspect (assuming you actually find anything) that it's only connecting to
one or two remote IP addresses; so, you might want to consider changing
that Remote Address: field above to those _specific_ (and legitimate) IP
addresses that you find in the event log.

But then, Symantec went on (finally!) to say:

| Symantec say this is for DNS look-up.

Okay, well, that would more than likely be handled by a couple of rules up
in your System-Wide settings area: With NIS 2002 on a Win 2000 Pro box,
these would typically look like:
------------------------------------------------------
Rule a Default Inbound DNS
Category: NIS System Keeping
Rule in use: YES
Logging: NO
Protocol: UDP
Action: Permit
Direction: Inbound
Application: Any Application
Local service: Any Service
Local Address: Any Address
Remote Service:
..........Port: 53
Remote Address: Any Address
------------------------------------------------------
Rule b Default Outbound DNS
Category: NIS System Keeping
Rule in use: YES
Logging: NO
Protocol: TCP or UDP
Action: Permit
Direction: Outbound
Application: Any Application
Local service: Any Service
Local Address: Any Address
Remote Service:
..........Port: 53
Remote Address: Any Address
------------------------------------------------------

If what they say is true, then all you have to do is ENABLE logging on
these two rules and then look for DNS events in the firewall event log
that are associated with nmain.exe.

Okay, here's what I get when I do what you said you've done and with
logging enabled on the above two rules:

13:15:46:238 Alert Tracker An instance of "C:\...\NMAIN.EXE" is
preparing to access the Internet for the first time C:\...\NMAIN.EXE
                          Local Local IP Remote Remote IP Action
    Time Direction Prot Port Address Port Address
Process Name
13:15:46:238 Outbound UDP 4503 0.0.0.0 53 xxx.yyy.3.10 PERMIT Outbound
DNS C:\...\NMAIN.EXE
13:15:46:413 Inbound UDP 4503 0.0.0.0 53 xxx.yyy.3.10 PERMIT Inbound
DNS C:\...\NMAIN.EXE
13:15:52:442 Outbound UDP 4504 0.0.0.0 53 xxx.yyy.3.10 PERMIT Outbound
DNS C:\...\NMAIN.EXE
13:15:52:672 Inbound UDP 4504 0.0.0.0 53 xxx.yyy.3.10 PERMIT Inbound
DNS C:\...\NMAIN.EXE
13:15:58:681 Outbound UDP 4505 0.0.0.0 53 xxx.yyy.3.10 PERMIT Outbound
DNS C:\...\NMAIN.EXE
13:15:58:906 Inbound UDP 4505 0.0.0.0 53 xxx.yyy.3.10 PERMIT Inbound
DNS C:\...\NMAIN.EXE
13:16:04:910 Outbound UDP 4506 0.0.0.0 53 xxx.yyy.3.10 PERMIT Outbound
DNS C:\...\NMAIN.EXE
13:16:05:085 Inbound UDP 4506 0.0.0.0 53 xxx.yyy.3.10 PERMIT Inbound
DNS C:\...\NMAIN.EXE

(I've truncated the display from Sven Schaefer's Log Viewer a bit above to
make it fit a bit better in this forum.) So, basically what I'm trying to
say is that you _aren't_ seeing logging on NMAIN.EXE for the simple reason
that you _don't_ have logging enabled on the appropriate rules. With me
on this?

[Incidentally, I wouldn't leave logging on for the two DNS Rules as that
will likely fill up your firewall event log faster than anything else;
everytime you use your browser to access a new website, it probably does a
DNS lookup on your ISP's DNS servers.]

| Thanks Joseph.

Any time. 

--
Regards,
    Joseph V. Morris
    jvmorris@erols.com
    ICQ #29438199

This is a NEWSGROUP message; except for privacy reasons, please respond
therein; an e-mail COPY is always appreciated, of course.
Almost all electrons used in the creation of this message were recycled.
No electrons used in the production of this message were harmed or
mistreated in any manner.

Relevant Pages

  • Re: Event ID: 4000
    ... Based on the text of your event log, it appears that DNS is working fine. ... The problem may happen when your server attempts to connect to the remote ...
    (microsoft.public.exchange2000.protocols)
  • Active Directory in a mess
    ... and as I'm no Windows ... justified when one of the admins re-connected a previous DC after it ... my event log is "Kerberos - PAC authentication failure". ... DNS error on the main DC, "DNS received a critical failure from the ...
    (microsoft.public.win2000.active_directory)
  • Re: Cant find DC
    ... PC gets DNS from DHCP; it points to our ISP's DNS servers. ... In the Server System Event Log ... >>I have a network with only one server and about 25 workstations. ...
    (microsoft.public.windows.server.networking)
  • Re: DC Event warning 13508
    ... DNS returns the IP address of the wrong computer. ... Check if FRS is currently running on the target server. ... Check if Ntfrs is registered with the End-Point-Mapper on target ... >> This event log message will appear once per connection. ...
    (microsoft.public.win2000.active_directory)
  • Re: Challenge for the great troubleshooters!
    ... Other physical symptoms are not there at the moment. ... There are no errors in the DNS server event log ...
    (microsoft.public.windows.server.general)