about outpost!!!help!!

in scan.sygate.com
1,quickscan
http://bbs.kingsoft.com/attachments/zrTDMP7MQ==_QMP1jgkN3nSw.jpg
2，stealthscan
http://bbs.kingsoft.com/attachments/zrTDMP7_0W0iAN1GM1dJ.jpg
why they different??
grc and pcflank test no problem!! all stealth!!
thanks!!

 

The stealth test on scan.sygate.com seems to be more complete than others. It seems to act as if it requires a DNS resolving. You can pass this test by specifying your DNS server in 1st and 2nd rules

 

Welcome to the forums Hello all,

You may find the Online Scans - What to do with Open and Closed Ports FAQ at the Outpostfirewall forums a useful guide to port scans generally. A key issue is your Internet connection - if you are connecting with a router or a proxy server, that will get scanned rather than your PC.

Assuming that the scan is actually of your PC, others have reported similar results with Sygate Stealth. This is likely due to it using a different network packet (such as a TCP FIN to close a connection or ACK to acknowledge a previously sent packet rather than a SYN which would be used to open a connection). You may find your results vary (did you retry the test?) as a result - but if they are consistent check to see what programs you have using these ports (they should be listed in the Open Ports section of Outpost's main window - stating which version of Outpost you are using would be a real help at this point). If any programs are listed, check that they have no rules to allow incoming traffic. Trusted Applications can certainly cause problems here - make them Partially Allowed and define a tight ruleset.

However, as the Online Scan FAQ states, having a couple of closed ports should not be a serious concern - it is open ports that pose the risk.

Alex T,

While tightening up Outpost's DNS rules is a good idea (and covered in the Secure Configuration Guide) I can't see how this can affect the outcome of an online scan using different ports (DNS uses port 53). Would you care to explain further?

 

I would appreciate a more complete explanation too, although I believe Alex T is correct and I'm fairly certain tight DNS rules caused me to pass the Sygate Stealth Scan.
http://outpostfirewall.com/forum/showthread.php?t=8656

Regards
Optigrab

 

What did your previous or default DNS rules look like?

Check your firewall event log of the Sygate stealth scan, see what source ports it used - see any source port 53?
Edit: Depending on how your rule was configured, you may not see the source port 53 in your logs. See post below.

Regards,

CrazyM

 

If your existing/previous DNS rule or default DNS rule looked like:

Allow, TCP/UDP, Direction - Either, Remote IP Any, Remote service/port 53, local service/port Any

(If your rule was like this, then you would likely not see anything with a source port of 53 in your logs. They do use other source ports including 80 for the stealth scan.)

Sygate Stealth Scan where source port 53 (from my router/firewall log):

Code:

	Dest IP/Port		Source IP/Port

TCP	142.173.xx.xxx	8	207.33.111.36	53
TCP	142.173.xx.xxx	4	207.33.111.36	53
TCP	142.173.xx.xxx	6	207.33.111.36	53
TCP	142.173.xx.xxx	5	207.33.111.36	53
TCP	142.173.xx.xxx	8080	207.33.111.36	53
TCP	142.173.xx.xxx	7 	207.33.111.36	53
TCP	142.173.xx.xxx	3	207.33.111.36	53
TCP	142.173.xx.xxx	2	207.33.111.36	53
TCP	142.173.xx.xxx	113 	207.33.111.36	53
TCP	142.173.xx.xxx	445 	207.33.111.36	53
TCP	142.173.xx.xxx	1080	207.33.111.36	53
TCP	142.173.xx.xxx	443	207.33.111.36	53
TCP	142.173.xx.xxx	139	207.33.111.36	53
TCP	142.173.xx.xxx	80	207.33.111.36	53
TCP	142.173.xx.xxx	110	207.33.111.36	53
TCP	142.173.xx.xxx	1313	207.33.111.36	53
TCP	142.173.xx.xxx	22	207.33.111.36	53
TCP	142.173.xx.xxx	79	207.33.111.36	53
TCP	142.173.xx.xxx	20	207.33.111.36	53
TCP	142.173.xx.xxx	23	207.33.111.36	53
TCP	142.173.xx.xxx	59	207.33.111.36	53
TCP	142.173.xx.xxx	25	207.33.111.36	53
TCP	142.173.xx.xxx	21	207.33.111.36	53
TCP	142.173.xx.xxx	53	207.33.111.36	53

I think you can see why you would get the results you did.

Suggestions for DNS rules:

TCP rules:
'Allow DNS Servers'
Allow My Address [1024-5000] --> [DNS Servers] [53]

UDP rules:
'Allow DNS Servers'
Allow My Address [1024-5000] <-> [DNS Servers] [53]

Your DNS rules only need to allow for TCP outbound. UDP needs to be allowed in both directions. Restrict these rules to your ISP's DNS servers, remote service/port 53 and restrict to local service/port 1024-5000.

Regards,

CrazyM

 

And there I was, thinking that Sygate Stealth scan was some mystical voodoo involving specially crafted network packets .

Hello all, any of the suggestions given above for tightening DNS rules should work in this case - although with Alex T's you will need to replace his IP addresses with yours (open a command prompt and type ipconfig /all to find out your DNS server addresses).

 

Some explanations :
I discover the origin by looking in the log of authorized events in outpost (without the thighten rule, it contains a lot "allow DNS resolving"

13:31:41 SYSTEM TCP 207.33.111.36 HTTP Allow DNS Resolving (TCP) 3
13:31:41 SYSTEM TCP 207.33.111.36 HTTP Allow DNS Resolving (TCP) PROXY:8080
13:31:41 SYSTEM TCP 207.33.111.36 HTTP Allow DNS Resolving (TCP) 8
13:31:41 SYSTEM TCP 207.33.111.36 HTTP Allow DNS Resolving (TCP) 6
13:31:41 SYSTEM TCP 207.33.111.36 HTTP Allow DNS Resolving (TCP) ECHO
13:31:41 SYSTEM TCP 207.33.111.36 HTTP Allow DNS Resolving (TCP) 5
13:31:41 SYSTEM TCP 207.33.111.36 HTTP Allow DNS Resolving (TCP) 2
13:31:41 SYSTEM TCP 207.33.111.36 HTTP Allow DNS Resolving (TCP) 4
13:31:41 SYSTEM TCP 207.33.111.36 DOMAIN Allow DNS Resolving (TCP) 3
13:31:41 SYSTEM TCP 207.33.111.36 DOMAIN Allow DNS Resolving (TCP) 2
13:31:41 SYSTEM TCP 207.33.111.36 DOMAIN Allow DNS Resolving (TCP) 4
13:31:41 SYSTEM TCP 207.33.111.36 DOMAIN Allow DNS Resolving (TCP) PROXY:8080
13:31:41 SYSTEM TCP 207.33.111.36 DOMAIN Allow DNS Resolving (TCP) ECHO
13:31:41 SYSTEM TCP 207.33.111.36 DOMAIN Allow DNS Resolving (TCP) 8
13:31:41 SYSTEM TCP 207.33.111.36 DOMAIN Allow DNS Resolving (TCP) 5
13:31:41 SYSTEM TCP 207.33.111.36 DOMAIN Allow DNS Resolving (TCP) 6

I don't understand why the steful inspection isn't sufficient to block these packets.

 

Perhaps SPI isn't employed in DNS resolving - that's the case in my Outpost configuration. I don't think SPI is useful for DNS resolving rules, though I could be wrong. I refer to the Stateful Inspection FAQ on the Outpost forum.

 

Alex T,

Optigrab is right here. Outpost's "Stateful Inspection" option is for use with applications that create multiple network connections although Outpost does apply network-level stateful inspection on every packet it processes also.

However the log entries you have posted do raise some serious questions. The first batch (listing HTTP as a remote port) should not have been allowed under the default DNS rule which suggests that you altered it (e.g. by removing the remote port restriction) - this would then result in a very wide range of traffic being permitted when it should not be. In this case I would advise either following the Secure Configuration Guide recommendations on DNS or (at the minimum) ensuring your DNS rules are set to the following:

Allow DNS Resolving (UDP): Protocol UDP, Remote Port 53, Remote Address <your DNS server>, Allow
Allow DNS Resolving (TCP): Protocol TCP, Outgoing, Remote Port 53, Remote Address <your DNS server>, Allow

The TCP rule can be set to Block instead of Allow with no ill-effect in my experience since DNS mostly uses the UDP protocol.

 

For most the UDP rules should suffice. Occassionally a UDP look up may fail and resort to outbound TCP, but should not affect the average user.

Power users who do advanced DNS look ups, will probably require the outbound TCP rule.

Regards,

CrazyM