Re: Norton Personal Firewall 2003

From: Joseph V. Morris (jvmorris@erols.com)
Date: 12/09/02 

From: "Joseph V. Morris" <jvmorris@erols.com>
Date: Mon, 9 Dec 2002 16:30:37 -0500

Ture,

I don't think you quite understand what all this is about. Inline, below
. . . .

"Alsvik Ture" <ture@alsvik.dk> wrote in message
news:gZoI9.61554$HU.4262223@news010.worldonline.dk...
. . . .

| > First thing I would do is put the GRC test site into the Exclusions
List.

| That would be cheating, wouldn't it? I mean if anyone scans my computers
| ports they will not get the same result being in my blocklist, right? So
| blocking www.grc.com will not make my ports stealthed on other sites or
from
| other users, and i cant add everybody!!!

No, you've got it turned around backwards. In NIS/NPF 3/4, you find these
settings on the pane entitled "Intrusion Detection". I believe this may
be a somewhat different location in NIS/NPF 2003 (6.0x) for the simple
reason that Symantec has now introduced some serious intrusion detection
(IDS) capabilities. (Indeed, that may be part of the problem you are
experiencing.) Now, on _that_ pane in NIS/NPF 3/4, you find several
choices:
1) You can check (select) or uncheck (deselect) "Detect Port Scan
Attempts"
2) You can check (select) or uncheck (deselect) "Enable AutoBlock"
3) You can specify specific sites or URLs that would be EXCLUDED from the
    above options (assuming, of course, that you SELECTed these options).

Now, I run with both 1) and 2) CHECKED, BUT I specifically _exclude_ sites
like GRC, Sygate, PCFLANK, Symantec, the DSLR Security test site, etc.,
that I use to check my system. Now, why do I do that? Well, you have to
understand what happens if you have both of the two above options checked.

If you have BOTH of these options checked, _ANY_ web-based port testing
site that you may care to use will automatically be BLOCKed from TESTING
your system to see if you're secure (unless the site is listed in the
Exclusions list, of course). These options will shut down these (and any
other sites not in the Exclusions list) within milliseconds as soon as a
multi-port scan against your firewall is detected. How does this occur?
Well, the firewall checks unsolicited inbound communications attempts. If
it finds more than N probes of _distinct_ ports on your machine in M
milliseconds or less (at least in NIS/NPF 3/4), it treats that as a
hostile intrusion attempt. And, by default, it shuts down ALL inbound
communications from that remote IP address for something like 30 minutes.
What that means is that your ports aren't being tested AT ALL (really!) to
determine if they're OPEN, CLOSED, or STEALTHED. Indeed, the probes never
hit the NIS/NPF firewall at all -- the site is simply BLOCKED in its
entirety for the default 30 minutes. So, if you REALLY want to know if
you've got OPEN or even just CLOSED ports tested by these sites, you have
to add the testing site to the Exclusions list.

Okay, now, you're saying "Yes, but what about hostile sites? Not test
sites?" Well, if it's _not_ a test site and it's NOT in the Exclusions
list, those two options will do exactly what you expect. Only problem is
that you're unlikely to have any _hostile_ sites picked up this way.
HOSTILE sites that will set this off are rare as hen's teeth. Indeed,
since July at least of this year, I've never seen anything stopped by
these options other than my chosen test sites and my own ISP (scanning to
make sure I'm not running any services in violation of my ISP's ToS/AUP
agreements). And this, of course, is _precisely_ what I've resolved by
putting those test and my ISP's own scanning sites into my Exclusions
list. Everything else will still be auto-blocked.

There's just one problem with this wonderful solution: I WON'T HAVE ANY
INFORMATION THAT I CAN PROVIDE TO THE HOSTILE USER'S ISP AS TO EXACTLY
WHAT WAS PROBED OR WHEN. You can try filing an abuse report with
IDIOTSISP.com (yourself, directly) or with MyNetWatchman.com, or with
dShield.org in this instance -- IT WON'T MAKE ANY DIFFERENCE; YOU HAVE
_NO_ INFORMATION THAT THEY CAN THEN USE TO IDENTIFY AND BLAME THE CULPRIT.
YOU WON'T HAVE ANY DETAILS TO PROVIDE THEM. (Check your firewall event
log; you'll find out what I mean.)

Okay, now let's go back to what I meant by "scarce as hens teeth". Any
fool worth their salt knows better than to do something that will set off
these alarms in the first place. It's just begging to get cut off by
their ISP. I've got about eight instances since July in which I've seen a
REAL multi-port scan from a single remote IP address. NONE OF THESE HAVE
BEEN PICKED UP BY THESE OPTIONS. Do you know why? Probably not. It's
the N distinct local ports in less than M milliseconds criteria. Anyone
worth their salt knows better than to do this. I've seen multi-port
probes of anywhere from 4 to 8 ports in these eight instances. The
DEFAULT THRESHHOLD for a "Port Scan Detected" is TEN (distinct) ports in
NIS/NPF. Only a skiddy would be stupid enough to do THAT. (And I haven't
seen a skiddy in a long, long time.) In addition, someone who really
knows what they're doing will also space out the probes just enough to
escape the M milliseconds criteria. No, you can't simply modify the M
millisecond criteria to 'resolve' this problem (by increasing it, that
is). Even IBR from someone running a P2P file sharing program will again
ping you in three seconds. If that fails, they'll try again six seconds
later. Three seconds, in other words, is the largest increment to which
you can set the time interval (and that assumes you know how to do that)
without being bombarded with meaningless "Port Scan Detected" events in
your firewall event log.

| > Second, you should now be able to find events from the GRC port scan
in
| > your firewall event log. Do you see events for 21, 25, 80, 110, 443?
I
| > realize this is going to be a bit tedious, given the firewall event
log
| > display available in NPF 2003. In earlier versions, you could have
used
| > Sven Schaefer's NIS Log Viewer to quickly ascertain if these events
are or
| > are not present.

| There are not log entries with the adress of grc.com or their ip (at
| grc.com they write that alarms can go on in your firewall with entried
from
| ip: xxx.xxx.xx.xx ). But it doesn't report any alerts while doing a
scan -
| and i doesn't create any entries while the scan is done . That is why i
| think something is wrong!

Well, if you HAVEN'T put the GRC.COM test IP addresses into your
Exclusions List, it's bloody amazing that you see ANYTHING in the firewall
event log when running their "Probe My Ports" test -- if you've got both
of the options discussed above CHECKED.

| > Now, we get to the complications:
| > 1) Do you (or your ISP) have a proxy server between you and GRC?
| > What about a router? (That's the most common source of this
| > kind of result. If it's probing your router or even your ISP's
| > proxy server, it will most definitely report these ports as
| > open in 9 cases out of 10.)
|
| They used to be reported as stealth. I haven't changed anything but
| upgrading to NPF2003.

I'll go back and check, but I could have sworn that you said that you use
a router in one of your subsequent responses. My (first) question now
becomes: Was the router in place when running NPF 2002?

My (second) question now becomes: How do you know that you are not NOW
accessing the GRC site through a proxy server (or router) in use by your
ISP? Have you _confirmed_ that YOUR IP address (from winipcfg.exe or
ipconfig.exe, depending on your operating system) is NOW being correctly
picked up by the GRC test site (as indicated in the test results)?

| To answer another of your questions, i uninstalled NPF2002 first, and
since
| i also used NAV2002 and upgraded that product at the same time, i also
| uninstalled that. When i first noticed the problem i now seem to have, i
| uninstalled both programs and deleted all entries i could find matching
| "symantec" and "norton" in regedit.

Uh-ohhh! That may be part of the problem. There's a lot of
Symantec/Norton registry entries that can cause problems if unilaterally
removed. You have to start with Start | Programs | Control Panel |
Add/Remove Software... (and pay particular attention to any options that
may be presented). After that, you should have used Symantec's RNIS and
RNAV utilities, not scoured the registry independently and manually.

| > 2) Did you have all these multiple servers running when you had
| > NPF 2002 installed? If so, what inbound TCP rules did you
| > have in place for them at that time?

| NPF2002 created these rules on it's own. It detected the IIS5.0-service
and
| the ftp-server, and it created the rules for the mailserver. I only had
to
| choose "permit all" or "automatic" - and i choose "automatic" where
| possible.

Okay, got that. You had these services running when you had NPF 2002
installed. But you still haven't answered my questions. What WERE the
rules that NPF 2002 created for these applications? Do you have any
documentation on them, whatsoever? Did you ever off-load these rule
specifications using Albert Janssen's AtGuard NIS Rules Viewer (which is
the only way you _could_ have saved them off in a readable form)?

| > 3) What are your _current_ inbound TCP rules for these servers?
| > (Remember, the rules you had in place in NPF 2002 don't
| > automatically upgrade to NPF 2003; you have to re-enter.)
| > (I know answering that one is going to be tedious, because
| > you can't use Albert Schaefer's AtGuard NIS Rules Viewer
| > with NPF 2003.)
|
| I haven't created any rules but one, allowing any traffic from/to any
| computer to my local ports 4661-4665

Ahhh, that doesn't really answer my question (especially after reading the
response to the following question). If you started NIS/NPF 2003 with
Security set to MEDIUM (and especially with Automatic Firewall Rule
Creation, or whatever it's called in NIS/NPF 2003, invoked), then the
INBOUND PERMIT rules for these server applications were _probably_ invoked
BEFORE you set the Security Level to HIGH. So, again, when you actually
inspect your ruleset for these applications, what INBOUND PERMIT rules do
you find? There is NO way to accurately respond to this question other
than manually inspecting your rules for these services (in detail, I might
add) and manually copying them off into a response. True, in NIS/NPF
_prior_to_ NIS 4.5, you could have used Albert's utilities to do this, but
his utilities don't work with NIS 4.5 or NIS/NPF 6.0x.

| > 4) Okay, I assume you've confirmed that the firewall component
| > is actually enabled. Do you have the Security Level set
| > to HIGH?
|
| The firewall is enabled (everthing is default) except i've raised it to
| HIGH.

Hmm, exactly WHEN did you raise the security level to HIGH? (This may be
very important, in light of my response above.)

| Alert level is set to MIN. Changing this to high will not create any
alerts
| from grc.com or their ip or create any log entries from their adress /
ip.
| So the scan just isn't detected!

No, that's not quite correct. IF you had SECURITY set to MEDIUM, and
AUTOMATICALLY ENABLE FIREWALL RULE CREATION ENABLED, or if you used the
AutoScan for Internet Enabled Applications run during system setup, YOU'VE
ALREADY CREATED the PERMIT INBOUND rules -- and these rules do _not_ log
by default. You have to MANUALLY enable logging on them. If you don't do
so, the unsolicited inbound communications will simply be PERMITted and
you will have no firewall log events to indicate that this is happening.

| > 5) If you've done all of the above and still can't identify
| > the source of the problem, then you need to add a custom
| > rule to the System-Wide Settings. This would be a
| > MONITOR rule for TCP inbound for these particular ports.
| > ENABLE Logging for this rule and position it at the top
| > (beginning) of your System-Wide Rule Settings. Run GRC's
| > "Probe My Ports" again. If THIS rule doesn't generate
| > log events, then these probes are, in fact, not getting
| > to your machine. If THIS rule DOES generate log events,
| > it should also tell you what Process is accepting them.
|
| I will try that - but somehow i've lost my sense of security with NPF.
| I'll try to create a custom rule that monitores the open ports 21, 25,
80,
| 110, and 443 and see if that creates any entries in the log.

At this point, I can't say. But it rather looks to me as if you've let
NIS/NPF create the necessary PERMIT INBOUND rules automatically for these
server applications. If so, those rules don't automatically log (unless
you manually invoke logging). And, of course, if these PERMIT INBOUND
rules actually EXIST, well, sure ... GRC is going to identify these ports
as OPEN.

Now, if you _want_ these services available to others (_any_ others, I
might add) via the Internet, well, that's the way it's going to be. If, on
the other hand, you'd like to limit Internet access to these services to a
select few, then you'll need to CUSTOMIZE the automatically created rules
to restrict the PERMIT INBOUND communications to just those users (by IP
address) whom you choose to allow. You can't offer up services to the
Internet at large and get STEALTH results when running GRC, Sygate, DSLR
Security, PC Flank, or Symantec port testing sites (to name only a few). 

--
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: xp security
    ... >> I'm trying to tighten my computer security by eliminating the open ... >perspective', with your firewall running. ... >'hiding' those ports from the scan. ... >likely 'dropping' the packets sent from www grc com. ...
    (alt.computer.security)
  • Re: Firewall strealthing
    ... Please visit the experts in the Firewall newsgroup: ... authorizes the use of the site for a fake email address. ... Out of the above ports, the following are open and permitting outbound ... GRC tests firewalls but as I recalled it only tests inbound traffic. ...
    (microsoft.public.windowsxp.general)
  • Re: xp security
    ... > Shields Up web site www.grc.com shows I am running stealth. ... The ports you found to be 'listening' would be stealthed from an 'internet ... perspective', with your firewall running. ... likely 'dropping' the packets sent from www grc com. ...
    (alt.computer.security)
  • Re: Norton Personal Firewall 2003
    ... I Got Stealth results (from the GRC test site) on ALL 13 Ports Tested! ... and 5000 were even _making_ it to the firewall. ...
    (comp.security.firewalls)
  • Re: Trouble accessing Outlook Web Access from behind firewall
    ... When starting the firewall I also set ... > rejected and dropped packets are logged, however I see nothing in my log ... > # Higher ports needed to accept incoming/outgoing calls ...
    (comp.security.firewalls)