i have win7 operating system without any services or program sending stream at background,firewall inbound connection set to none, sharing disabled, and i am behind NAT. Today i just start wireshark, then i see these STUN protocols, i cannot find any process send the stream because the stream doesn't show in resmon,taskmgr,or processhacker.
below is the screenshot of wireshark
how to see which program/service which sending/accept STUN protocols ?
STUN is Session Traversal Utilities for NAT. Originally designed for VOIP apps.
Something is using it on your Windows, and I would scan for malware/viruses as those have been known to use STUN as an exploit:
http://en.wikipedia.org/wiki/STUN
http://researchcenter.paloaltonetworks.com/2014/09/malware-trending-stun-awareness/
Related
Would like to know is there any proxy available for intercepting tcp/udp traffic.
We have the tcp and udp traffic that cannot be intercepted via any other web debugging proxy.
Appreciate if anyone can suggest right solution for the same.
Thanks
Umesh Narayanan
Since you mention tcp and udp packets, and then later a "debugging proxy", I assume that you would like to make all network traffic go though a device for analysis.
There are such devices. This is usually a firewall, a more sophisticated firewall which embarks packet analysis (enterprise firewalls often have such modules available, Checkpoint comes to mind for instance) or a Intruder Detection/Protection System (IDS/IPS) which analysis traffic to uncover malicious elements.
There are open source firewalls (iptables on Linux for instance) and IDSes (Suricata for instance) but you will probably quickly hit the encryption wall (data which is encrypted between the client and server)
Can anyone tell me which Communication Protocol is used by hyperterminal connecting via Tcp/Ip ?
Protocol here means UDP, Socket/Server, other(If any).
Actually, I need to design an application (in QT, Linux as OS) to communicate to a machine (basically a printer) via Ethernet. I need to send request to the printer as well as receive response, if any, from the printer.
It can be communicated via Hyperterminal using Tcp/IP.
So I wonder which protocol should i use for the communication. As Printer simply supports ethernet therefore I have no idea, if I can use Socket/Server for communication.
Need suggestion over this. All idea/suggestion are welcome.
Thanks in Advance
You need to get your terminology right. TCP/IP and UDP are transport layers. A protocol refers to the application data that is transmitted over a transport. A socket is a programming API that allows an application to gain access to a transport so it can send/receive protocol data.
Now, to answer your question - HyperTerminal typically uses the Telnet protocol over TCP/IP. Many protocols in existence are text-based, and Telnet is largely compatible with simple ASCII text, which makes it convenient for allowing users to use Telnet UI clients, like HyperTerminal, to manually send text commands to network-connected devices. However, most devices/protocols do not use the actual Telnet protocol. But if you can communicate with a device using HyperTerminal, you can code your app to send/receive the same text commands.
I want to remote dial from my pc using a simple non SIP client program which I wrote and wchich sends commands to a proprietary SIP client that accepts remote commands via a TCP connection. The proprietary SIP client will then dial the remote party using my PC's IP and port number in SDP for RTP. Is this possible in principle? Are there any opensource clients available that use this concept? Is there any documentation (IETF RFCs, blogs etc) that is available.
Appreciate any help in this matter.
Check out pjsip, it's an open-source cross-platform SIP client for all major platforms and with API in C and an API wrapper for python, whichever you prefer. There are also examples on their site. Link your TCP parsing code to pjsip and call its functions to initiate a call, you can find how to do it on their site
If I understand correctly, here is what you want to do:
TCP SIP/SDP/RTP
PC <===> SIP client <===========> softswitch
Actually, TCP between PC and SIP client will probably be accurate for signalling but not for media as RTP media stream is often sent over UDP.
In my opinion, the first step is to make sure that your softswitch will accept sending RTP packets to an IP address which is not the same as SIP client (I think most of them refuse for security reasons). If it accepts and if you have no NAT between your SIP client and your PC, you should be able to send RTP stream directly to your PC. In this case, you have to retrieve RTP packets, eventually rearrange them, decompress their payload and feed them to your speakers.
If your softswitch does not want to send RTP packets to an IP address different from SIP IP address, then you have to forward your RTP packets from your SIP client to your PC. But if you can't modify your SIP client to do this (and it's probably the case as it's a proprietary software), you're probably stuck.
To test whether your softswitch accepts sending RTP packets to an unintended IP address, you can use sipp and specify a remote media ip address different from SIP signalling IP address.
I'm writing a piece of P2P software, which requires a direct connection to the Internet. It is decentralized, so there is no always-on server that it can contact with a request for the server to attempt to connect back to it in order to observe if the connection attempt arrives.
Is there a way to test the connection for firewall status?
I'm thinking in my dream land where wishes were horses, there would be some sort of 3rd-party, public, already existent servers to whom I could send some sort of simple command, and they would send a special ping back. Then I could simply listen to see if that arrives and know whether I'm behind a firewall.
Even if such a thing does not exist, are there any alternative routes available?
Nantucket - does your service listen on UDP or TCP?
For UDP - what you are sort of describing is something the STUN protocol was designed for. It matches your definition of "some sort of simple command, and they would send a special ping back"
STUN is a very "ping like" (UDP) protocol for a server to echo back to a client what IP and port it sees the client as. The client can then use the response from the server and compare the result with what it thinks its locally enumerated IP address is. If the server's response matches the locally enumerated IP address, the client host can self determinte that it is directly connected to the Internet. Otherwise, the client must assume it is behind a NAT - but for the majority of routers, you have just created a port mapping that can be used for other P2P connection scenarios.
Further, you can you use the RESPONSE-PORT attribute in the STUN binding request for the server to respond back to a different port. This will effectively allow you to detect if you are firewalled or not.
TCP - this gets a little tricky. STUN can partially be used to determine if you are behind a NAT. Or simply making an http request to whatismyip.com and parsing the result to see if there's a NAT. But it gets tricky, as there's no service on the internet that I know of that will test a TCP connection back to you.
With all the above in mind, the vast majority of broadband users are likely behind a NAT that also acts as a firewall. Either given by their ISP or their own wireless router device. And even if they are not, most operating systems have some sort of minimal firewall to block unsolicited traffic. So it's very limiting to have a P2P client out there than can only work on direct connections.
With that said, on Windows (and likely others), you can program your app's install package can register with the Windows firewall so your it is not blocked. But if you aren't targeting Windows, you may have to ask the user to manually fix his firewall software.
Oh shameless plug. You can use this open source STUN server and client library which supports all of the semantics described above. Follow up with me offline if you need access to a stun service.
You might find this article useful
http://msdn.microsoft.com/en-us/library/aa364726%28v=VS.85%29.aspx
I would start with each os and ask if firewall services are turned on. Secondly, I would attempt the socket connections and determine from the error codes if connections are being reset or timeout. I'm only familiar with winsock coding, so I can't really say much for Linux or mac os.
I'm developing a SIP mobile softphone, customer needs a complete hiding of SIP messages from softphones to SIP servers as VOIP calls are regionally prohibited, however using TLS connection was not sufficient since the message headers are easily recognized as a SIP message. What are the best common alternative?
what about openvpn, IPSec tunneling?
Transmitting SIP over TLS means the SIP headers will only be viewable if someone is able to compromise your TLS keys, i.e. it's highly unlikely unless some national security agency is on your case.
What you might be encountering is port 5061 being blocked since it's the default and therefore well known SIP TLS port. To get around that simply use a different port for your SIP TLS connection. As far as anyone viewing the traffic goes if it's not suing port 5061 they won't have any idea that SIP is being used in your TLS stream.
Of course you also need to consider the RTP traffic which is what will carry the audio part of the call once SIP has set it up. There are no standardised ports for RTP but some popular VoIP softswitches do use certain ranges by default. For example Asterisk uses UDP 10,000 to 20,000. To work around that you'd really need to use SRTP but that's going to be harder to set up since not that many SIP user agents and servers support it. It will also be easier to detect for someone watching your traffic since even without knowing the contents the profile of RTP packets would be detectable. Still it's likely to need a sophisticated entity monitoring your traffic to detect a VoIP call using SIP over TLS on a non-standard port and SRTP call amongst the general noise of internet traffic.