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).

13DOS attack from the vendor’s network
i.
i.
i.
i.
i.
Set the system factors
ii. Design the decoder
iii. Design the base discovery motor
iv. Design dynamic stacked libraries
v. Design preprocessors
vi. Design yield modules
vii. Tweak Rule Set
viii. Tweak preprocessor and decoder rule set
ix. Alter shared item rule set

14DOS attack from the vendor’s network
In this fundamental setup, we will just address stages 1, 6, and 7 in that rundown (bolded
previously). With simply these three, we can get Snort running viably much of the time. As we
get to further developed designs, we will address the others(Wu, Zhang, & Yue, 2016).
Step 3 set the rules
Commonly, to get Snort to run appropriately, we have to change the standards that it depends
upon.
Once in a while, a standard or principle set will toss blunders, so we have to remark out a
standard or guideline set incidentally. On the off chance that we look down to line 504, this starts
the "Tweak your standard set" advance of the arrangement document. Notice line 511 for nearby
principles. These are decided that we can add to Snort's standard set in our altered setup(Ding,
Li, Quevedo, Dey, & Shi, 2017).

15DOS attack from the vendor’s network
To shield Snort from utilizing a standard set, essentially remark out the "incorporate" part.
Notice that there are numerous inheritance decide sets that are remarked out, however, can end
up dynamic just by expelling the # before them. When we are finished rolling out our
improvements to the setup document, we just spare the content record.
Step 5 test the configurations
Before we place Snort into creation, how about we test our new setup. We can utilize the - T
switch pursued by the setup document to test our Snort design(Wei, Fung, 2015, June).

16DOS attack from the vendor’s network
DOS attack using hping3

17DOS attack from the vendor’s network

18DOS attack from the vendor’s network
Conclusion
Any new and present day firewall will stop it and most Linux pieces are worked in with SYN
flood insurance nowadays. This guide is intended for research and learning reason. For the
individuals who are experiencing difficulty TCP SYN or TCP Connect flood, take a stab at
learning IPTables and approaches to make sense of how you can square DoS utilizing hping3 or
nping or some other apparatus. You can likewise DoS utilizing GoldenEye that is a layer 7 DoS
assault instrument to mimic comparable assaults or PHP adventure to assault WordPress sites.

19DOS attack from the vendor’s network
Reference
Yuan, Y., Yuan, H., Guo, L., Yang, H., & Sun, S. (2016). Resilient control of networked control system
under
DoS attacks: A unified game approach. IEEE Transactions on Industrial Informatics, 12(5),
1786-
1794.
Peng, C., Li, J., & Fei, M. (2017). Resilient Event-Triggering $ H_ {\infty} $ Load Frequency Control for
Multi-
Area Power Systems With Energy-Limited DoS Attacks. IEEE Transactions on Power
Systems, 32(5), 4110-4118.
Ding, K., Li, Y., Quevedo, D. E., Dey, S., & Shi, L. (2017). A multi-channel transmission schedule for
remote
state estimation under DoS attacks. Automatic, 78, 194-201.
Dridi, L., & Zhani, M. F. (2016, October). SDN-guard: DoS attacks mitigation in SDN networks. In 2016
5th
IEEE International Conference on Cloud Networking (Cloudnet) (pp. 212-217). IEEE.
Wu, Z., Zhang, L., & Yue, M. (2016). Low-rate DoS attacks detection based on network multifractal. IEEE
Transactions on Dependable and Secure Computing, 13(5), 559-567.
Wei, L., & Fung, C. (2015, June). FlowRanger: A request prioritizing algorithm for controller DoS attacks
in
5254-5259). IEEE.

20DOS attack from the vendor’s network
Gope, P., Lee, J., & Quek, T. Q. (2016). The resilience of DoS attacks in designing anonymous user
authentication protocol for wireless sensor networks. IEEE Sensors Journal, 17(2), 498-503.
Chen, B., Ho, D. W., Zhang, W. A., & Yu, L. (2017). Distributed dimensionality reduction fusion estimation
cyber-physical systems under DoS attacks. IEEE Transactions on Systems, Man, and
Cybernetics:
Systems, (99), 1-14.
Cheng, Z., Yue, D., Hu, S., & Chen, L. (2019, April). Event-based resilient H∞ fuzzy filter design under
DoS
attacks. In 2018 5th IEEE International Conference on Cloud Computing and Intelligence
Systems
(CCIS) (pp. 198-202). IEEE.
Chelladhurai, J., Chelliah, P. R., & Kumar, S. A. (2016, June). Securing docker containers from denial
of service (dos) attacks. In 2016 IEEE International Conference on Services Computing
(SCC) (pp.
856-859). IEEE.
Ormazabal, G. S., Schulzrinne, H. G., Yardeni, E., & Patnaik, S. B. (2015). U.S. Patent No. 8,966,619.
Washington, DC: U.S. Patent and Trademark Office.
Zhang, T., Zhang, Y., & Lee, R. B. (2017, April). Dos attacks on your memory in the cloud. In Proceedings
of
the 2017 ACM on Asia Conference on Computer and Communications Security(pp. 253-
265)ACM.

21DOS attack from the vendor’s network
ACM.
Mukherjee, S., Shirazi, H., Ray, I., Daily, J., & Gamble, R. (2016, December). Practical DoS attacks
embedded networks in commercial vehicles. In International Conference on Information
Systems
Security (pp. 23-42). Springer, Cham.
Fotohi, R., Ebazadeh, Y., & Geshlag, M. S. (2016). A new approach for improved security against DoS
attacks in the vehicular ad-hoc network. International Journal of Advanced Computer Science
Applications, 7(7), 10-16.