Hackerwacker setup and NIS

You guys...I am just mystified how to translate these instructions from www.hackerwhacker.com to prepare my firewall for a comprehensive scan. Maybe you can have a look at this and see how it translates to what I need to do in Norton Internet Security 2003:

From HACKYOURSELF (www.hackerwhacker.com):

<<BEGIN EXCERPT>>
Warning: If your computer is firewalled, UDP Scanning can take a LONG time (6-8 hours common and days rarely). We recommend you try the following:

If you change your firewall packet filtering method from DENY to REJECT, you will allow UDP scanning in GREATLY reduced time. On a fast connection, an entire 65534 UDP port scan can finish in under a minute. By REJECT we mean, "send back an ICMP unreacheable message to the scanner". By DENY we mean, "Simply drop the packet without informing the scanner". DENY causes LONG scans. REJECT makes for short scans. BOTH give you equal blockage of hackers.

There is a common misconception floating around the net that DENY gives you "stealth" ports, meaning, you don't show up on hacker scans, but this is not true. Current scanning methods very clearly show when a computer is trying to hide itself. A truly absent computer will cause the internet provider's router to send back a "node unreacheable" ICMP message to the scanner but a stealthed computer doesn't do that and is painfully obvious to even a beginner hacker.
<<END EXCERPT>>

I don't really see where I can go about controlling my packet filtering method from DENY to REJECT in NIS 2003...maybe it is a hidden or default firewall rule that I can't seem to get to...I see no references by such name in the "Options" set of tabs...particularly "Firewall" that relates to this, unless it is by another name.

Can somebody help? Thanks so much.

 

Hi dsteve54

Unfortunately there is no setting in NIS2003 that I am aware of that will allow you to select how the firewall handles/responds to unsolicited inbound packets. NIS will basically stealth your system to these packets (drop them with no reply).

While I and others have tested the various settings available that suggest/imply they may do this, none have proved to completely "unstealth" the firewall (provide a closed response).

This is not a feature available in most (any?) software firewalls, but is something you will see in hardware devices. It is, however, a feature some user would like to see implemented in software firewalls. Stealth just seems to win out these days and is more marketable.

Regards,

CrazyM

 

Thanks for giving me a confirmation that this stuff is not readily (if at all) mappable to NIS 2003. I tried fooling around with some of the custom settings, but that was using probably one millioneth of the knowledge that you have...the right hand didn't know what the left was doing.


I may try to ask symantec about it, if there is some way I can get to their tech support that does not cost me a mortgage payment.

 

Steve,

Stand by one. CrazyM is off (on assignment). Let me take a look at this; I've got an idea as to how this might be accomplished, especially for UDP using NIS.

 

Okay, it just got a bit more complicated than I had expected. Apparently, I'd have to resubscribe to be able to run and test the following approach. . . .

As CrazyM notes, you really can't make this configuration change in NIS/NPF. (The instructions are more likely to be relevant to a hardware firewall or a NAT-based router.)

Yeah, that can be true, also. (The method of doing this is occasionally repeated on the USENET NNTP newsgroups.)

Okay, what I'm going to suggest requires that you put two temporary rules at the very beginning of your NIS firewall ruleset. And, by that, I mean at the very beginning of the System-Wide Rules. Do you know how to accomplish this? If you do this, don't forget to remove these rules when you're finished!

Code:

Rule 1          [b]PERMIT ALL UDP[/b]      
Rule in use:           YES
Logging:                [b]YES[/b]
Protocol:                [b]UDP[/b]
Action:                   [b]Permit[/b] 
Direction:               [b]Inbound[/b]
Local  service:        Any Service
Local  Address:      Any Address
Remote service:     Any Service
Remote Address:   Any Address

Rule 2                    [b]PERMIT ICMP Destination Unreachable[/b]      
Rule in use:           YES
Logging:                [b]YES[/b]
Protocol:                [b]ICMP[/b]
Action:                   [b]BLOCK[\b] 
Direction:               [b]Outbound[/b]
Local  service:        ICMP Message Type 3    (Destination Unreachable)
Local  Address:      Any Address
Remote service:     Any Service
Remote Address:   Any

Okay, got that? You want now to run four tests in all. The first test has the two rules as specified above. The remaining tests require that you modify the above rules for the other three combinations (between the two rules) of PERMIT and BLOCK.

For example, Run 2 might be
Rule 1 Action: PERMIT
Rule 2 Action: PERMIT

Run 3 might be
Rule 1 Action: BLOCK
Rule 2 Action: PERMIT

and, finally, Run 4 might be
Rule 1 Action: BLOCK
Rule 2 Action: BLOCK

Note the time at which you begin each set of runs. (You'll need that later to find the associated log entries in the NIS/NPF firewall event log tab.) (And you're gonna need to use a big log file size for the NIS firewall event log to accomplish this, probably at least 1 MB.)

Now, why are you doing this? Simple. Hackerwhacker will tell you what it sees (from its website); but, to correctly interpret what HackerWhacker tells you, you also need to know what you see from your side. If Hackerwhacker tells you that it's probing your IP address, but you don't see any corresponding NIS/NPF firewall log entries, then it isn't. (It might simply be probing your ISP or possibly an inline router.)

Again, Remove these two rules when you've finished your tests.