W2-1/3 Identifying Applications in Network Traffic (7/3)

The 2nd week has been kind of slow due to the fourth of July. Many people are taking off the entire week or at least the rest of the week. Because of this the week was not very eventful, none the less it still included good experience and lessons related to cyber security.

   On Tuesday I learned about identifying applications in network traffic. There is a number of ways to identify applications in network traffic. Identification can occur via port numbers (1), banner grabbing & OS fingerprinting (2), by behavior (3), and by ancillary site(s) (4). Softwares like NTA and Wiresharks allow a user to watch network traffic activity and look over incoming packets. Traffic should be monitored and possibly recorded in cases of investigation and data analysis. Network analysis is really important to understand the norms of a network and its evolving ebb and flow due to various changes that can occur (addition/removal of previous equipment, lack of employee traffic, increased employee traffic, etc.). In the end the goal is to block malicious and or unauthorized traffic (i.e. cyber security breaches).

     (1) TCP/IP (Transmission Control Protocol/Internet Protocol) are protocols used to interconnect network devices whether that be to the internet (TCP/IP) or in the case of private networks, intranet and extranet (TCP). Intranet is a private network created using World Wide Web software (WWW) it may be local or restricted to nonpersonnel. Extranet is intranet that is partially accessible to authorized exterior personnel. Intranet and extranet are used in tandem to exchange information safely over the internet. Think of the extranet as a permeable membrane that lets in vehicles of wanted data (authorized exterior personnel). It is used to try and keep out hackers and their bots. Port numbers are the original and simplest way to check although there is no real technical requirement for all applications to where they are allotted only common conventional practices, few are reserved. Which won't always be followed to a "T" whether malicious or not, yet it should raise some suspicion. Traffic on reserved and conventional ports usually acts in a predictable and consistent manner. If you start finding inconsistencies, you can't explain then there is a decent possibility it is the signs of a hacker at work. Other ports are dangerous if any traffic occurs on them. Any services on port 23/tcp (Telnet) or 21/tcp (FTP) should be cut out as both are obsolete in the first place. SSH and SFTP should replace them respectively. Port 20/tcp is also suspicious considering it is FTP data. When using SFTP, anything that uses SSH, or any other protocol that allows for port configuration should be adjusted to fit the conventional port (SFTP port 22, by adjusting what port the daemon [a type of Unix-like program that runs in the background and is commonly used as a sensor] listens to). This will make tracking easier and help with managing clutter. 80/tcp (HTTP) is commonly used to evade the firewall in all environments and is a critical service so it needs to be monitored well, as should other critical service ports like 25/tcp (SMTP) & 53/udp (DNS). Client use in ports below 1024 is very suspicious (and should be avoided) considering these are not conventional client ports and include root access. Network analysts should compare the results of their analysis tools with vertical machine scans (looking through all stages of the cyber supply chain) in order to be completely sure of their findings. Any successful cyber security traffic related personnel should understand the norms of the network. When does traffic spike? When does traffic fall? When should traffic be coming through a port? Unusual activity can be signs of a security breach. For example, is you see traffic on your network late at night when no one is supposed to be on a port then you probably have a bot or hacker at work.

   (2) Banner grabbing & OS finger printing is also based on convention (most applications identify themselves right after being opened). Banners can be grabbed actively (e.g. netcat) or passively (e.g.tcpdump). The challenge is to decipher banners which are very different across the spectrum of applications. Some banners and OS's are on lists of known malware these lists are commonly used by cyber security employees and softwares. These malicious applications can then be blacklisted or investigated further by looking up the banner as information on them maybe somewhere around the web.

   (3) Identification via behavior is done by watching for cues usually related to fumbling, control traffic, chatter (subMTU packets), and file transfer. Fumbling alarms in general should check failures to connect (e.g. TCP sessions lacking ACK flags) then repeated fumbles should set off an alarm based off a rigid value, sequential hypothesis testing phenomena success rate, or whenever a user visits the dark address (unused routable address space). Repeated FtCs can be a sign of brute force hacking. Control packets usually follow a template, so packet size can be used to identify chatting. This \can be roughly asymmetrical with packets usually bigger than 40 bytes a piece and FT will be closer to MTU. Control packets that do not fit this description are suspicious, perhaps they are the vehicle for a payload of malicious content.

 (4) The home addresses of AVs need to be checked routinely since this activity is commonly disabled by malware in any environment. Tracker ID should be used. Magnet links (commonly used in phishing) and activity should be analyzed (e.g. torrent site links and huge file downloads are common among bitTorrent users). BitTorrent can be used to scan for vulnerabilities, a common activity of hackers (white hat/benevolent actors/pentesters or black hat/malicious actors). Huge file downloads can also be signs of someone trying to steal source code (if that is the only large file that big then what else would they be downloading). AVs are similar to critical service ports since they are common targets for attack and thus, they should be watched and protected.

 While this feels like a lot, I feel confident in its theoretical application. I'm not as confident with it when it comes to its hands-on application since I yet to have a lot of experience with its physical application. I feel like my biggest need out of this internship and in my experience internships in general, is physical application of relevant concepts. There's no utility in this knowledge if I never get to apply it. Without physical application it is very difficult for somebody to get a full understanding of a concrete concept. That being said, I really like how much I am learning here and I'm thankful for this opportunity. I will try my best to get some physical application in any of the concepts I am given, and I am currently taking notes down of things I can do on my own time (i.e. Freeware I can learn how to use and implement these concepts upon).