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