I don't know what's the matter with people: they don't learn by understanding, they learn by some other way — by rote or something. Their knowledge is so fragile! (Feynman)
IP class A addresses have first octets with a decimal number from 1 to 127. Example: 27.x.y.z 102.x.y.z
IP class B addresses have first octets with a decimal number from 128 to 191.Example: 128.x.y.z 151.x.y.z
IP class C addresses have first octets with a decimal number from 192 to 223.Example: 192.x.y.z 223.x.y.z
IP class D addresses have decimal values from 224 to 239 in the first octet, and the 4 leftmost bits are 1110.Example: 224.x.y.z 239.x.y.z
The last IP address class of addresses is IP class E. IP class E addresses range from 240 to 255 in the first octet, and the 4 leftmost bits are 1111. Example: 240.x.y.z 255.x.y.z
A Hub is a multiport repeater in which a signal introduced at the input of any port appears at the output of the all available ports.
A Switch is a tele-communication device which receives a message from any device connected to it and then transmits the message only to the device for which the message is intended.
A router reads the header of incoming packet and forward it to the port for which it is intended there by determines the route. It can also perform filtering and encapsulation.
4.
Hub is not an intelligent device that may include amplifier on repeater.
A Switch is an intelligent device as it passes on the message to the selective device by inspecting the address.
A route is more sophisticated and intelligent device as it can read IP address and direct the packets to another network with specified IP address. Moreover routers can built address tables that helps in routing decisions.
5.
At least single network is required to connect.
At least single network is required to connect.
Router needs at least two networks to connect.
6.
Hub is cheaper as compared to switch and router.
Switch is an expensive device than hub.
Router is a relatively much more expensive device than hub and switch.
An Ethernet hub acts as a multiport repeater that receives an incoming electrical signal (data) on a port. It then immediately forwards a regenerated signal out all other ports. Hubs use physical layer processing to forward data. They do not look at the source and destination MAC address of the Ethernet frame. Hubs connect the network into a star topology with the hub as the central connection point. When two or more end devices connected to a hub send data at the same time, an electrical collision takes place, corrupting the signals. All devices connected to a hub belong to the same collision domain. Only one device can transmit traffic at any given time on a collision domain. If a collision does occur, end devices use CSMA/CD logic to avoid transmission until the network is clear of traffic. Due to the low cost and superiority of Ethernet switching, hubs are seldom used today.
Bridges have two interfaces and are connected between hubs to divide the network into multiple collision domains. Each collision domain can have only one sender at a time. Collisions are isolated by the bridge to a single segment and do not impact devices on other segments. Just like a switch, a bridge makes forwarding decisions based on Ethernet MAC addresses. Bridges are seldom used in modern networks.
LAN switches are essentially multiport bridges that connect devices into a star topology. Like bridges, switches segment a LAN into separate collision domains, one for each switch port. A switch makes forwarding decisions based on Ethernet MAC addresses. The figure shows the Cisco series of 2960-X switches that are commonly used to connect end devices on a LAN.
IPTables is a very powerful firewall that allows you to protect your Linux servers. I have been looking for some best practices to protect a server from the Internet and after collecting some examples here and there I came up with the following rules. This will block all the bad stuff, allow inbound SSH and also allows outgoing traffic from the server itself.
Don’t just copy and paste this script as there is always a change to block some legitimate traffic, look at the example and then decide for yourself what you want to use. Having said that, let’s take a look:
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# ACCEPT LOOPBACK
-A INPUT -i lo -j ACCEPT
# FIRST PACKET HAS TO BE TCP SYN
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP
# DROP FRAGMENTS
-A INPUT -f -j DROP
# DROP XMAS PACKETS
-A INPUT -p tcp --tcp-flags ALL ALL -j DROP
# DROP NULL PACKETS
-A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# DROP EXCESSIVE TCP RST PACKETS
-A INPUT -p tcp -m tcp --tcp-flags RST RST -m limit --limit 2/second --limit-burst 2 -j ACCEPT
# DROP ALL INVALID PACKETS
-A INPUT -m state --state INVALID -j DROP
-A FORWARD -m state --state INVALID -j DROP
-A OUTPUT -m state --state INVALID -j DROP
# DROP RFC1918 PACKETS
-A INPUT -s 10.0.0.0/8 -j DROP
-A INPUT -s 172.16.0.0/12 -j DROP
-A INPUT -s 192.168.0.0/16 -j DROP
# DROP SPOOFED PACKETS
-A INPUT -s 169.254.0.0/16 -j DROP
-A INPUT -s 127.0.0.0/8 -j DROP
-A INPUT -s 224.0.0.0/4 -j DROP
-A INPUT -d 224.0.0.0/4 -j DROP
-A INPUT -s 240.0.0.0/5 -j DROP
-A INPUT -d 240.0.0.0/5 -j DROP
-A INPUT -s 0.0.0.0/8 -j DROP
-A INPUT -d 0.0.0.0/8 -j DROP
-A INPUT -d 239.255.255.0/24 -j DROP
-A INPUT -d 255.255.255.255 -j DROP
# ICMP SMURF ATTACKS + RATE LIMIT THE REST
-A INPUT -p icmp --icmp-type address-mask-request -j DROP
-A INPUT -p icmp --icmp-type timestamp-request -j DROP
-A INPUT -p icmp --icmp-type router-solicitation -j DROP
-A INPUT -p icmp -m limit --limit 2/second -j ACCEPT
# ACCEPT SSH
-A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
# DROP SYN-FLOOD PACKETS
-A INPUT -p tcp -m state --state NEW -m limit --limit 50/second --limit-burst 50 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -j DROP
# ALLOW ESTABLISHED CONNECTIONS
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
Explanation of Rules
Accept Loopback Traffic
-A INPUT -i lo -j ACCEPT
We should permit local traffic on the server.
First TCP segment requires SYN bit
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP
When TCP establishes a connection it will perform a 3 way handshake. The first TCP packet always has the SYN bit set. If it doesn’t have this, we will drop the traffic.
No Fragments allowed
-A INPUT -f -j DROP
We don’t allow fragmented IP Packets.
XMAS Packets
-A INPUT -p tcp --tcp-flags ALL ALL -j DROP
A TCP packet that has all the flags set is called a XMAS packet and should never be accepted.
Null Packets
-A INPUT -p tcp --tcp-flags ALL NONE -j DROP
A Null packet is a TCP packet without any flags. This is never used in legitimate traffic so it should be dropped.
The TCP RST (Reset) is used to abort a TCP connection so we shouldn’t see many of these at the same time. They are accepted but limited to 2 per second with a burst of 2.
Invalid Packets
-A INPUT -m state --state INVALID -j DROP
-A FORWARD -m state --state INVALID -j DROP
-A OUTPUT -m state --state INVALID -j DROP
When using stateful packet inspection, a packet can be new, established or related. When it’s not one of these, it is considered invalid and should be dropped.
RFC 1918 Packets
-A INPUT -s 10.0.0.0/8 -j DROP
-A INPUT -s 172.16.0.0/12 -j DROP
-A INPUT -s 192.168.0.0/16 -j DROP
On the Internet we should never see IP packets from private IP addresses so we’ll drop them.
Spoofed Packets
-A INPUT -s 169.254.0.0/16 -j DROP
-A INPUT -s 127.0.0.0/8 -j DROP
-A INPUT -s 224.0.0.0/4 -j DROP
-A INPUT -d 224.0.0.0/4 -j DROP
-A INPUT -s 240.0.0.0/5 -j DROP
-A INPUT -d 240.0.0.0/5 -j DROP
-A INPUT -s 0.0.0.0/8 -j DROP
-A INPUT -d 0.0.0.0/8 -j DROP
-A INPUT -d 239.255.255.0/24 -j DROP
-A INPUT -d 255.255.255.255 -j DROP
We shouldn’t see the ranges above so when we do, they are considered as spoofed and dropped.
ICMP Smurf Attack and Rate Limit
-A INPUT -p icmp --icmp-type address-mask-request -j DROP
-A INPUT -p icmp --icmp-type timestamp-request -j DROP
-A INPUT -p icmp --icmp-type router-solicitation -j DROP
-A INPUT -p icmp -m limit --limit 2/second -j ACCEPT
We allow most ICMP traffic but it is rate-limited.
SSH Connections
-A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
SSH is allowed for remote access.
SYN Flood Protection
-A INPUT -p tcp -m state --state NEW -m limit --limit 50/second --limit-burst 50 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -j DROP
A SYN flood is a DOS attack where the attacker sends a lot of SYN packets but never completes the 3 way handshake. As a result the server will have a lot of “half open” connections and might not be able to serve new connections. Be careful with this setting as this is a global limit.
Established Connections
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Packets with the “new” state are checked with our first rule, we drop “invalid” packets so at the end we can accept all “related” and “established” packets.
Hopefully this iptables example gives you a template to work on. If you want to protect your device even more you might want to consider looking at the hashlimit module. This allows you to rate-limit traffic based on IP addresses and port numbers, which might be helpful to combat some DOS attacks.
IoT applications suffer from various vulnerabilities that put them at risk of being compromised, including:
Weak or hardcoded passwords. Many passwords are easy to guess, publicly available or can’t be changed. Some IT staff don’t bother changing the default password that shipped with the device or software.
Lack of an update process or mechanism. IT admins unintentionally exclude many IoT apps and devices from updates because they are invisible on the network. Also, IoT devices may not even have an update mechanism incorporated into them due to age or purpose, meaning admins can’t update the firmware regularly.
Unsecured network services and ecosystem interfaces. Each IoT app connection has the potential to be compromised, either through an inherent vulnerability in the components themselves or because they’re not secured from attack. That includes any gateway, router, modem, external web app, API or cloud service connected to an IoT app.
Outdated or unsecured IoT app components. Many IoT applications use third-party frameworks and libraries when built. If they’re obsolete or have known vulnerabilities and aren’t validated when installed in a network, they could pose security risks.
Unsecured data storage and transfer. Different data types may be stored and transmitted between IoT applications and other connected devices and systems. All must be properly secured via Transport Layer Security or other protocols and encrypted as needed.
Threats to IoT applications
Threats to IoT applications fall into several general categories: spoofing, information disclosure, distributed denial of service (DDoS), tampering and elevation of service. Attackers typically use these threats as an entry point to a network and then move on to other areas to cause problems, such as stealing data, blocking connections or releasing ransomware.
Four threats that target IoT app vulnerabilities.
Spoofing threats. Attackers intercept or partially override the data stream of an IoT device and spoof the originating device or system, which is also known as a man-in-the-middle attack. They intercept shared key information, control devices or observe sent data.
Information disclosure threats. Attackers eavesdrop on broadcasts to obtain information without authorization, jam the signal to deny information distribution or partially override the broadcast and replace it with false information. They then threaten to release or sell the data.
Tampering threats. Attackers can gain access to the firmware or OSes of the devices running an IoT app and then partially or completely replace it on the device. They then use the genuine device and application identities to access the network and other connected services. For example, SQL or XML injection attacks and DDoS attacks are tampering threats for IoT apps.
Elevation of privilege threats. Attackers use unsecured IoT apps to change the access control rules of the application to cause damage. For example, in an industrial or manufacturing environment, an attacker could force a valve to open all the way that should only open halfway in a production system and cause damage to the system or employees.
How to protect IoT applications
Protecting IoT applications isn’t a one-and-done activity. It requires planning, action and regular monitoring. Get started with these nine ways.
1. Learn the most likely threats
Threat modeling can identify, assess and prioritize the potential IoT app vulnerabilities. A model can suggest security activities that will ensure IT admins include IoT apps in overall security strategies. The model should continue to evolve and grow to reflect the state of the IoT app accurately.
2. Understand the risks
Not all risks are the same when it comes to IoT apps and an organization. Prioritize risks in order of concern and act accordingly. Many tech teams forget to align the risk with business scenarios and outcomes. A failure or breach in one IoT app may seem innocuous to IT but have serious financial implications for the company.
3. Update apps regularly
IT admins must deploy updates to IoT apps as quickly as possible to ensure the safety of the entire network. Use only approved and authenticated updates and, if updating apps over the air, use a VPN to encrypt all update data streams. Secure public key infrastructures (PKIs) can also authenticate devices and systems.
4. Secure the network
Firewalls, encryption and secure communication protocols protect IoT apps from unauthorized access. Regularly review the various standards, devices and communication protocols used on the network to ensure adequate security. Add IoT apps to any application security testing.
5. Enable strong authorization
Strong password protection is essential for IoT applications and that includes developing a secure password process for those creating passwords. Change the default passwords on IoT devices and apps and ensure they’re changed regularly. Deploying a two- or three-way authentication model with TLS communication protocols reduces the chances that authentication data can be compromised at any point.
6. Secure communication
Encrypting data between IoT devices, apps and back-end systems keeps data safe from attackers. That includes encrypting data at rest and in transit and adopting PKI security models to ensure both senders and receivers get authenticated on the system before transmitting.
7. Secure control applications
Applications and systems that have access to IoT apps should also be secured. When they are secure, it stops the client IoT system from being compromised by outside attacks and prevents it from propagating attacks downstream.
Not applying the same level of security measures to each component of IoT deployments can lead to problems beyond the individual device or application.
8. Secure API integrations
APIs are often used to push and pull data between applications and systems. They are another way for attackers to connect to IoT apps and cause problems. Only authorized devices and applications must communicate with APIs, making it easier to detect threats and attacks immediately. IT admins must also use API version management with old or redundant versions identified and removed regularly.
9. Monitor IoT apps
Monitoring IoT apps is the final step in protecting them. Ensure they’re tested and scanned like the rest of the network to get alerts and address IoT security issues quickly.
IoT devices and applications pose a significant risk to organizations today. With hundreds or even thousands of devices connected to an enterprise network, not applying the same level of security measures to each component of IoT deployments can lead to problems beyond the individual device or application.
S.No
Vulnerability
Exploit
1.
Vulnerability is a weakness in a system that can be exploited.
Exploit is a tool that can be used to take advantage of a vulnerability.
2.
Vulnerabilities can exist without being exploited.
Exploits are created through the use of vulnerabilities.
3.
Vulnerabilities can be exploited for a variety of purposes.
Exploits are often used to execute malicious code.
4.
Vulnerabilities can remain open and potentially exploitable.
Exploits are often patched by software vendors once they are made public.
5.
Vulnerability can allow the attacker to manipulate the system
Exploits take the form of software or code which helps us to take control of computers and steal network data
6.
Vulnerability can cause by complexity, connectivity, poor password management, Operating system flaws, Software Bugs, etc.
Exploits are designed to provide super user-level access to a computer system.
Analysis of a cyberattack.
a. Who were the victims of the attacks?
b. What technologies and tools were used in the attack?
c. When did the attack happen within the network?
d. What systems were targeted?
e. What was the motivation of the attackers in this case? What did they hope to achieve?
f. What was the outcome of the attack? (stolen data, ransom, system damage, etc
A malware attack is a common cyberattack where malware (normally malicious software) executes unauthorized actions on the victim’s system. The malicious software (a.k.a. virus) encompasses many specific types of attacks such as ransomware, spyware, command and control, and more.
Criminal organizations, state actors, and even well-known businesses have been accused of (and, in some cases, caught) deploying malware. Like other types of cyber attacks, some malware attacks end up with mainstream news coverage due to their severe impact.
There are three main types of malware attack vectors:
Trojan Horse: This is a program which appears to be one thing (e.g. a game, a useful application, etc.) but is really a delivery mechanism for malware. A trojan horse relies on the user to download it (usually from the internet or via email attachment) and run it on the target.
Virus: A virus is a type of self-propagating malware which infects other programs/files (or even parts of the operating system and/or hard drive) of a target via code injection. This behavior of malware propagation through injecting itself into existing software/data is a differentiator between a virus and a trojan horse (which has purposely built malware into one specific application and does not make attempts to infect others).
Worm: Malware designed to propagate itself into other systems is a worm. While virus and trojan horse malware are localized to one infected target system, a worm actively works to infect other targets (sometimes without any interaction on the user’s behalf).
Security Operations Center (SOC)
The major elements of a SOC, are people, processes, and technologies.
Tier 1 Alert Analyst – These professionals monitor incoming alerts, verify that a true incident has occurred, and forward tickets to Tier 2, if necessary.
Tier 2 Incident Responder– These professionals are responsible for deep investigation of incidents and advise remediation or action to be taken.
Tier 3 Threat Hunter – These professionals have expert-level skill in network, endpoint, threat intelligence, and malware reverse engineering. They are experts at tracing the processes of the malware to determine its impact and how it can be removed. They are also deeply involved in hunting for potential threats and implementing threat detection tools. Threat hunters search for cyber threats that are present in the network but have not yet been detected.
SOC Manager – This professional manages all the resources of the SOC and serves as the point of contact for the larger organization or customer.
SIEM systems are used for collecting and filtering data, detecting and classifying threats, and analyzing and investigating threats.
SIEM and security orchestration, automation and response (SOAR) are often paired together as they have capabilities that complement each other.
Metrics or Key performance indicators (KPI) define SOC performance.
five metrics are commonly used as SOC metrics
Dwell Time – the length of time that threat actors have access to a network before they are detected, and their access is stopped.
Mean Time to Detect (MTTD) – the average time that it takes for the SOC personnel to identify valid security incidents have occurred in the network.
Mean Time to Respond (MTTR) – the average time that it takes to stop and remediate a security incident.
Mean Time to Contain (MTTC) – the time required to stop the incident from causing further damage to systems or data.
Time to Control – the time required to stop the spread of malware in the network.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRejectRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are as essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
