Re: Norton Personal Firewall 2003

From: Alsvik Ture (ture@alsvik.dk)
Date: 12/10/02 

From: "Alsvik Ture" <ture@alsvik.dk>
Date: Tue, 10 Dec 2002 00:57:10 +0100

Sorry if you thought i was rude in my last post. I wasn't ...! Just
misunderstood your comment about the 12 posts!

Ture :o)
"Alsvik Ture" <ture@alsvik.dk> wrote in message
news:119J9.63061$HU.4620588@news010.worldonline.dk...
> Thanks for your concern and interest in my matters.
> It has now evolved to a quite long post, and i will try to answer your
> questions.
> First, NPF2003 has an intrusion detection feature called "port scan" - but
> it hasn't detected any portscans yet. Even if i disable home networking
and
> scans it from a computer within the network, it doesn't detect it!
>
> I have a router, and i hasnt been changed since i installed it and plugged
> it into the wall. I routes all traffic to the server.
> So the setup for the router is the same and has always been, whether i've
> been using NPF2002 or NPF2003.
> GRC and sygate's port scanner validates my external ip-adress, so it's the
> correct ip it's scanning.
>
> If X decides to scan my ports he will have the same result as grc.com.
> And when NPF2003 doesn't detect grc's scan it wont detect X's scan either.
>
> When uninstalling NAV or NPF i have always (during this period since the
> problems occured) removed the programs using add/remove in contro panel,
and
> after that i've used the Symantec removal tool and then to be total secure
> it wasn't any thing in the registry that messed it up, i manually removed
> entries like "symantec" and "norton" with regedit.
>
> I cannot uncheck "port scan detection" in NPF2003 (as i can in NPF2002)
but
> i can exclude the intrusion detection called "port scan".
>
> When installing NPF2003 i decided not to run liveupdate, not to do program
> scan and not to create any rules before a reboot.
> After the reboot it will ask me to allow programs like ftp, iis, p2p and
so
> on. Where possible i will pick "automatic" since it then is a know
program.
> Where it's not possible i will choose "permit all". This is just the
> programs and services starting automatically when windows boots to
desktop.
> After that i changed the security level to HIGH. Autoblock is default on.
> Then i ran program scan and i checked the programs i know needs internet
> access, and i choose automatic where possible.
>
>
> I have no sites added under autoblock! I have from time to time, when some
> kind of intrusion is detected., Often it's a ip that have accessed my port
> 80 with some kind of invalid "cgi script" attempt!
>
> I never created any custom rules for my services, as NPF2002 would detect
> them automatically and just ask me if i would permit or deny them access
to
> the internet. For all my services/servers i can choose "automatic" - which
> is recommended by NPF. This is the same with NPF2003.
>
>
>
> Just deleted all programs in the list and re-did the program scan.
> Everything is set to high. Even alerting.
> I set up a rule to monitor internetacess on the local ports 21, 25, 80,
110,
> 443 and 8080 and did a port scan from grc.com.
> It adds a monitoring event to the log. Two for each port. One with the
> destination of my internal ip adress, and one for ip adress 0.0.0.0.
> It creates entries for the ports i'm not using saying " unused port
> blocking"
> So it detects the access attempt, but it doesn't recognize it as a port
> scan!
>
>
> Going through the automatically created rules for programs, i see that
they
> are created as follows:
> allow connections from any computer on any port on any nic to program
>
> That is a pretty loose rule.
> Can i change these so that the webserver only allow traffic on port 80,
and
> the ftp-server only allows traffic on port 21 and so on?
>
> ?
>
> Ture
>
> Again: Thank you for your interest and concern. I really appreciate it!
>
> >
>
> > . . . .
> >
> > "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 t
he
> > 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: OT: Trend Micro WFBS beta starting soon
    ... Trend firewall, even set to High, has inbound NetBIOS ports open. ... default 3389 port, web browsing, email, etc. ... it opens inbound NetBIOS connections until the laptop is rebooted. ...
    (microsoft.public.windows.server.sbs)
  • Re: keeping ports open
    ... If a port is open, it means that 1) a software or service is running on your ... and 2) you're not using a firewall or your firewall isn't ... Use firewall software and hardware and antivirus software that is ... Follow the instructions for hardening Windows and IIS at ...
    (microsoft.public.security)
  • Re: How to Maintain an IIS Server?
    ... > server running on a Windows 2000 server. ... before a firewall and antivirus have been installed]. ... open ports; however, this will not identify which program is using the port. ...
    (microsoft.public.inetserver.iis.security)
  • Re: CEICW fails at firewall config
    ... ISA Server prevents connection to a remote desktop when you connect through ... Remote Web Workplace on a Windows Small Business Server 2003-based computer ... Acceleration Server as a firewall. ... connection uses TCP port 4125. ...
    (microsoft.public.windows.server.sbs)
  • RE: Concepts: Security and Obscurity
    ... First I have to state an assumption of a single firewall in the cases mentioned as I fail to see why adding SPA to a dual layered authenticated system would be adding anything at all other than trouble with users. ... Subject: Concepts: Security and Obscurity ... You send me a SYN to a given port ... "If I take a letter, lock it in a safe, hide the safe somewhere in New ...
    (Security-Basics)