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

From:
Date: 07/04/02 

Date: Thu, 4 Jul 2002 00:32:17 +0100

Hi Joseph V. Morris,

In n/g comp.security.firewalls you remarked...

> 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.)

You may have missed this 'twig' amongst the 'branches'...

"NIS HAS NEVER PRESENTED ME WITH AN INTERNET ACCESS ALERT FOR
`SYMANTEC NORTON PROGRAM INTEGRATOR` (NMAIN.EXE), yet, according to
the Alert Tracker and the NIS Statistics window, NMAIN.EXE *is*
connecting to the internet and transmitting data without my ever
having to configure a rule to permit it."

Noticing nmain transmitting data in the statistics screen, made me
think that it *was* actually connecting.
 
> 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
> **********

As you may imagine, I have re-installed NIS many times: on occasions
with Automatic Internet Access Control enabled, on others with it
disabled, but on no occasion has a rule been created automatically
and I have never been presented with an alert to create a rule for
nmain.exe.

I did once, however, create a rule like the above with the intention
to *block* nmain, but I could still see activity in the statistics
screen.

> 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.

I have tried a screen capture, during the activity on the statistics
screen to better explain what is happening, but have been
unsuccessful due to the period being so brief; I have, however,
captured the activity using Lotus ScreenCam, and can e-mail to you,
as an attachment, a zipped copy of the .scm file or a zipped
executable that includes the player (I haven't yet learnt how to
permit others to download files from my webspace).

> 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
> ------------------------------------------------------

These rules are in my ruleset.

> 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?

I see activity similar to above when I enable logging for those
rules.

> [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.]

Noted.

Thanks again. 

-- 
Tack

Please reply via newsgroup as my reply-to e-mail address is spam-
trapped. If you must respond via e-mail, replace 'nospam' with the 
name at the head of this signature before posting.
nospam@tack.flyer.co.uk

Relevant Pages

  • Re: Please Help - Losing Internet connection
    ... How are you connecting ... Everything works fine, except that the Internet ... This is the error I got in event logs: "The DNS server could not signal the ...
    (microsoft.public.windows.server.sbs)
  • Re: pop 3 connector error event id 1036
    ... Have you run the 'Connect to the internet' wizard? ... Connecting via ADSL with verizon through ... then I run utility to update DNS. ... I assumed that this was normal due to the dynamic dns operation! ...
    (microsoft.public.windows.server.sbs)
  • Re: 2003 server and 2 network cards
    ... Our other network card is connected ... it failed after connecting to the BT ... > We are having terrible trouble with the DNS setup. ... > respond to any requests from the Internet. ...
    (microsoft.public.windows.server.setup)
  • Re: /etc/hosts (or NIS host map): official-host-name vs nicknames
    ... If you're not using DNS and not connecting to the Internet, ... you use .rhosts files, the hostname in there must be an official-host-name ...
    (comp.unix.solaris)
  • Re: Urgent! New router and big disaster
    ... Both NICs should point to his internal IP for DNS. ... forward ports to it reliably in the router. ... I should have been more clear about internet connection.. ...
    (microsoft.public.windows.server.sbs)