Vendor Network DOS Attack: Analysis, Solutions, and Snort IDS Config

This report provides a detailed analysis of a Denial of Service (DoS) attack originating from a vendor's network, highlighting the potential security risks and vulnerabilities. It begins by introducing the concept of DoS attacks and their impact on network resources, followed by a specific attack scenario where an attacker exploits the vendor's network access to target the organization's main server. The report outlines key assumptions related to packet fragmentation, traffic load, and anomaly detection, and proposes solutions to address the cyber attack, including identifying open ports, operating systems, IP addresses, and machine addresses. Furthermore, it discusses the evidence that can be acquired using a Snort Intrusion Detection System (IDS), including Syslog entries, alarm log sections, and database sections, emphasizing the importance of network bundles in verifying rule triggers and identifying false positives. The report also addresses current problems with Snort IDS and suggests necessary changes to improve its effectiveness, detailing the implementation steps for configuring Snort IDS, starting from running Snort as a sniffer and NIDS to setting the rules and modifying the configuration file. Finally, the document briefly touches on DOS attacks on Kali Linux, Snort IDS, and web servers, providing a comprehensive overview of the topic.

1DOS attack from the vendor’s network
DOS attack from vendor’s network
Student’s Name:
Institution Affiliation:

2DOS attack from the vendor’s network
1. Introduction …………………………………………………………………………………. 3
2. Attack scenario from the vendor’s network ………………………………………………… 3
3. Assumptions ………………………………………………………………………………… 5
4. Solution to address cyber attack described …………………………………………………. 5
5. Evidence that can be acquired using snort IDS …………………………………………….. 7
a) IDS specific and supplementary evidence ……………………………………………. 7
b) specific location ………………………………………………………………………. 9
c) Purpose of the evidence ……………………………………………………………… 9
6. Configuration of IDS ……………………………………………………………………… 9
a) Current problems with snort IDS ……………………………………………………. 10
b) Proposed changes ……………………………………………………………………. 10
7. Implementation of snort IDS configuration ……………………………………………… 11
8. DOS attack on Kali Linux, snort IDS and Web server …………………………………… 16
9. Reference ………………………………………………………………………………… 19

3DOS attack from the vendor’s network
Introduction
A denial of service attack is a security occasion that happens when an aggressor keeps genuine
clients from getting too explicit PC frameworks, gadgets, administrations or other IT assets.
Denial of service (DoS) attack regularly flood servers with traffic so as to make authentic clients
not access the resources. While an attack that crashes a server can frequently be managed
effectively by basically rebooting the framework, flooding attacks can be increasingly hard to
recoup from. Recouping from a circulated disavowal of-administration (DDoS) attack, in which
attack traffic originates from a substantial number of sources, can be significantly progressively
troublesome.
Attack scenario
Picture (1a) illustrating attack scenario on the vendor’s network

4DOS attack from the vendor’s network
Attacker launches an attack on the vendor’s network. Since the vendor’s network access all the
resources as the organization itself, the attacker will possess all the rights which are possessed
by the vendor. Whenever the security team tries to identify where the issue is, they can’t figure
out since the attacker is from the vendor’s network. The attacker can launch any type attack on
the vendor’s network. The main target of the attacker is to gain access to the main server of the
organization. Once they are in they can get personal details such as email, passwords and credit
cards. They can tamper with both vendor’s network and the main server of the organization. The
figure (1a) shows how an attack can be carried out in the vendor’s network. Figure (1b)
illustrates how the network the attacker goes through the whole network of the organization.

5DOS attack from the vendor’s network
Pic (1a) Illustrating how attack is carried out in the network
Assumptions
 Packet fragmentation. Snort can distinguish a parcel when it is complete. Therefore, on
the off chance that a parcel divided and after that goes through the network,Snort won't
almost certainly recognize them.
 Traffic Load. To coordinate the guidelines with the system's passing traffic, Snort needs

6DOS attack from the vendor’s network
to assess every one of the bundles and after that distinguish the assaults utilizing the
officially expected models.
 Rule Definition Language. The standard definition language in Snort depends on every
parcel passing the system.
 Anomaly Detection Inability In request to distinguish the assaults, the system based-
IDSs must know their interior structure .This implies that they should know the condition
of the system's inner hubs so that ,by chronicle and keeping them as a model of the
system's ordinary conduct, they can recognize and identify inconsistency if there should
arise an occurrence of changes in the system.
Solution to address cyber attack in the above scenario
1. Open ports of a hub in a system.
2. Sort of Operating framework
3. IP address
4. Machine address
5. Measure of system traffic
Evidence that can be acquired using the IDS to support the preliminary findings
Data analysis infers that there is information which can be dissected. So as to do productive and
powerful interruption investigation, it is extremely helpful to have Snort cautions, yet
additionally, other information sources to correspond with the Snort alarms. The alarm can take
one of the numerous structures. A portion of the conceivable outcomes include:
IDS specific and supplementary evidence

7DOS attack from the vendor’s network
 A Syslog passage - gives the expert a concise depiction of framework log(Zhang,
Zhang, & Lee, 2017, April).
 A full alarm log section - gives the examiner a short depiction of the occasion(Gope,
Lee, & Quek, 2016).
 A quick alarm log section - gives the expert a careless measure of data about the
occasion(Ormazabal, Schulzrinne, Yardeni, & Patnaik, 2015).
 A database section - gives the investigator a short depiction of database passage(Wu,
Zhang, & Yue, 2016).
Specific location of evidence
Snort can log cautions, yet additionally the system bundles which set off the standard or
preprocessor. The system bundles are incredibly valuable (at times, they are fundamental; recall
the thing we said about not having enough information) in checking the reason that set off a
standard, and in increasing more understanding into the conduct which set off the standard.
Bundles are likewise precious in identifying false positives. Grunt can log organize bundles in
three unique configurations: ASCII, pcap parallel arrangement, and bound together paired
organization. ASCII logs are simple for experts to peruse or to fabricate contents to parse the
yield. A case of such content is the investigation of what has were gotten to by means of
HTTP(Mukherjee, Shirazi, Ray, Daily, & Gamble, 2016, December).
Purpose of evidence
Generally, Snort isn't running in a segregated situation, but instead, other security devices are
conveyed close by it. Firewalls and defenselessness scanners are just two models. These extra

8DOS attack from the vendor’s network
devices can be extraordinary wellsprings of extra information that you can associate with the
Snort cautions. Most firewalls keeps records of all loggins to the network. Much of the time, the
firewall enables you to at any rate log blocked associations(Peng, Li, & Fei, 2017).
Configuring IDS
Current problems with snort IDS
Intrusion Detection System can be a mistaking issue for framework administrators. At the point
when an interruption discovery framework (IDS) is created, there are a few issues to manage,
including:
i. How to screen the framework for interruption endeavors.
i. What traffic ought to be checked.
i. How to log interruption endeavors.
i. What to do when an interruption endeavor is identified.
Required changes in the snort IDS
There are a few bundles accessible to mechanize and streamline the procedure of interruption
location, and Snort is a standout amongst the best. In spite of the fact that Snort has been
depicted as a "lightweight" interruption location framework, this portrayal alludes more to the
straightforwardness with which Snort might be conveyed on a little to medium-sized system than
the abilities of this profoundly adaptable utility. In this Daily Drill Down, we will cover the
methodology for introducing and designing Snort to keep running on a Linux framework.
Configuring snort IDS

9DOS attack from the vendor’s network
By plan, the/and so forth/grunt/snort.conf arrangement record holds every one of the guidelines
Snort will use for traffic correlations. While this is intelligently the situation, it isn't physically
valid.
In the event that you open the/and so on/grunt/snort.conf document in a content manager and
page down to area 6 and read the remarks. Beneath the remarks, you'll see a cluster of
incorporate articulations where different principle documents (situated in the/and so
forth/grunt/rules registry)
are incorporated into the setup record. The genuine guidelines themselves are not entered
straightforwardly into the design record to improve the executives. Note that the incorporate
explanations that have a pound image (#) before them are the debilitated standards. (Note that
you can incapacitate controls by debilitating a whole guideline document in the/and so
on/grunt/snort.conf record, or by handicapping singular standards inside a standard record as you
will see underneath.)
Any standard documents that begin with the word network are rules composed by Snort clients.
They do experience two or three checks by the Snort group to ensure they won't break your Snort
establishment, yet they don't get a similar investigation as those guidelines composed by the
Snort
group. As you'll find in the design record, many of these network rule documents are
empowered as
a matter of course. In case you're getting many false alarms identified with a particular
application, you might need to use network the second rule found in Snort's design document.

10DOS attack from the vendor’s network
In the event that you need to play around with altering or redoing rules, dependably make a
reinforcement duplicate of the first guideline record before you begin rolling out any
improvements. This will make it simple to reestablish the default activity should an errant
standard switch hose things up(Zhang, Zhang, & Lee, 2017, April).
In the event that you need to make your own standards sans preparation, add them to the
local.rules record. This document is vacant yet included as a matter of course. Try to give your
own standards a SID (see underneath) of 1000000 (one million) or higher(Chen, Ho, Zhang, &
Yu, 2017).
The standard records are content documents so you can open them up in any word processor. For
instance, open one of the standard documents with the order:
nano/and so on/grunt/rules/web-iis.rules
In the event that you page down, you'll see that the individual principles all begin with the ready
watchword. Many standards have a pound (#) character before the alarm to remark them out to
impair them. (You can remark out individual guidelines in a standard document or you can
remark
out a whole principle record in Snort's design document.)
On the off chance that your cursor down to a standard and bolt to the privilege, in the long run,
you'll see the SID catchphrase. Every individual guideline has its own special SID.
Implementing Configurations
Step 1: Start Snort

11DOS attack from the vendor’s network
Since we know the basics of its switches, how about we take a stab at running Snort; It can be
kept running as a sniffer, parcel lumberjack, or NIDS (organize interruption identification
framework). Here, we'll simply investigate the sniffer (bundle dump) and NIDS modes.
To run Snort in parcel dump mode, type:

12DOS attack from the vendor’s network
Step 2: Open the Config File
Like about each Linux application, Snort is arranged to utilize a design record that is a basic
content document. Change the content in this record, spare it, restart the application, and you
have another arrangement. How about we open the Snort setup record with any word processor; I
will utilize
Leafpad. Once more, the setup document is situated at/and so on/grunt/snort.conf(Cheng,Yue,
Hu, &
Chen,2019, April).
At the point when the snort.conf opens in your word processor, it should resemble the screen
capture above. Note that a significant number of the lines are essentially remarked starting with
the # character. On the off chance that we look down to lines 25-37, we can find in the remarks
that the setup record has nine segments(Gope, Lee, & Quek, 2016).