Discussion in 'other firewalls' started by mordor, Nov 16, 2003.
Why is my Sygate Pro 5.5 firewall listening on UDP ports 1025 & 1027 by default? Curious
If anyone could tell me what/why TCP 1026 is listening for, would also be much appreciated. I run Win2k.
Z:\openports -path -lines
DiamondCS OpenPorts v1.0 (-? for help)
Copyright (C) 2003, DiamondCS - http://www.diamondcs.com.au/openports/
Free for personal and educational use only. See openports.txt for more details.
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
UDP 0.0.0.0:1025 0.0.0.0:0 LISTENING
UDP 127.0.0.1:1027 0.0.0.0:0 LISTENING
System listening on TCP (usually a low ephemeral port) is normal for W2K and XP.
smc.exe listening on the UDP ports, is that Sygate or another app?
smc.exe is the Sygate Firewall executable.
There are Sygate users posting here, hopefully one of them may be able to shed some light on smc.exe listening on those UDP ports.
Do you have any live update options enabled? They could also be associated to some other functionality of the firewall/IDS monitoring traffic.
Hi mordor, CrazyM
I've been having a similar problem with Sygate 5.5 and Win98.
There are a couple of threads on this in the Sygate forums but I've got no joy from them so far. Things that have worked for some are making sure that the 'act as server' boxes are unchecked in the advanced options for all apps. Also that the auto update feature in options is turned off.
Interestingly AW shows the TCP listen to also be smc.exe whereas PortExplorer can only resolve it through netstat as '*system'.
Let me know if you have any luck on this one.
PS if you have got the autoupdate on you may find that turning it off closes only one of your ports
Seems to be a common issue with sygate (smc.exe), but again if I understand it correctly smc.exe listens "locally" so no ports are open to the outside, that's at least the result I get from portscanners...please correct me if I am wrong...
Thanks for the reply Karl, might be true... - with port explorer the remote address for smc.exe's listen is '*.*.*.*'.
Is '*' a wildcard or an indication of a 'local listen'? I couldn't tell from the helpfile.
Regardless, doesn't the fact that a port is listening at all increase vulnerability?
If so, it probably shouldn't be happening because of a firewall running...
Actually I understand too little about the construction of SPF to judge...maybe it's even a feature . I saw your post in the SPF-forum...let's hope the Sygate folks can shed some light on this...or maybe any of the specialists in here...?
I'm using Sygate PW Pro, and I've all ports stealth.
I may be wrong and do run SYGPro55 but isnt that listening on your loopback intranet? I believe that to be normal for any software firewall. How else could they monitor traffic?? No?
It may also be NAV if you're running that.
Good point, if you have autoupdate enabled, or run it manually, it could be what is establishing a listening udp port on localhost (much like IE and other apps do).
If an application or service is listening (holding a port open), it would be a concern if there was nothing in place to control traffic to that service/applicaiton.
Are you asking if the open ports should not be happening with a firewall running?
Services and applications will establish connections or listen - open ports. With a firewall in place you can control what network traffic is permitted to reach your system and any listening services/ports and those firewalls with application control, what apps/services can access the network. The firewall itself does control ports (as in opening/closing), just what traffic will be permitted.
Glad to see that it's not just me that has this happening with Sygate 5.5 - some others have also showed up on th Sygate forum.
Thanks for all the responses.
CrazyM - from your recent post on the PortExplorer forum ('Open UDP' thread) it sounds like a remote address & port of *.*.*.*/* is an indication of a listen as a server rather than another way of denoting 0.0.0.0 (alias for a loopback - 127.0.0.1).
If this is the case then the sygate executable smc.exe is running a listen as a server on 1025 or another dynamically assignable port using UDP while a "*system" application has a loopback from localhost (127.0.0.1/0.0.0.0) port 1025 to remote localhost/port 0 with TCP.
I appreciate that a firewall manages network traffic to other apps. The thing that worried me was that this listen can only be seen with Port Explorer, netstat etc and is not shown in the info on applications or connections in the Sygate window.
Spitnyri - The TCP connection appears to be a loopback - I'll freely admit to not knowing enough to know whether this loop is necessary for a firewall to monitor traffic.
Unfortunately Port Explorer can only detect the connection through netstat & doesn't record bytes sent/received otherwise I'd have a better idea of what was going on.
Also, I've yet to see it shown as an established connection with netstat, just a listen.
The UDP listen to '*.*.*.*/*' surely isn't a necessary part of a firewall though...
Sir Carew - external tests I've done do show this port as stealth which means that Sygate is doing a reasonable job of not showing the open port that it has created. Despite this it is still (I think) an unneccesary vulnerability and hopefully just a glitch rather than something that can or is being exploited.
If anyone has any ideas of where to go from here they would be much appreciated.
I dont think its lack of logging by default is a big issue because you can create an advanced rule to log and /or control anything you desire. It should be a simple matter to set it up to log or restrict any protocol or IP you want, even to restrict any application from actring as a server, etc under applications/advanced.
My understanding of TCP/IP is basic but from my research UDP is the send and forget side of the comm between machines that is not guaranteed similar to a broadcast delivery whereas TCP is a guaranteed connection.
"I dont think its lack of logging by default is a big issue" - I assume 'it' means Sygate not Port Explorer?
The problem is "that this listen can only be seen with Port Explorer, netstat etc and is not shown in the info on applications or connections in the Sygate window"
So no Sygate rules can be made based on access of an application.
Yes it would be possible to create rules blocking 0.0.0.0 and 127.*.*.* BUT according to cam (super moderator on Sygate forum)
"Apps often bind to 127.0.0.1 to do inter process/thread communications on the local host."
So blocking this address completely would probably be a bad idea & given that it is Sygate itself that has opened the port it is unlikely that such rules would work anyway.
As I mentioned previously, the worry is the fact that smc.exe is listening as a server with UDP on 1025 and this app and connection is not recognised by the firewall...
Please let me know if I've missed something obvious.
Just to let everybody know:
I've just read the thread esperino started in the spf forum again, and the last reply confirms, this issue is a bug and will be fixed in the next release. (Let's hope that this bug will not share the fate of the loopback issue... )
Thanks Karl - beat me to it
awaiting the next build before I think about buying SG PRO...
Thanks to both of you for keeping us up to date.
Sygate Forum post for those that are interested.
Separate names with a comma.