ITX8080: erinevus redaktsioonide vahel

Allikas: Lambda
Mine navigeerimisribale Mine otsikasti
← Vanem muudatus
Anttix (arutelu | kaastöö)
218 muudatust
Anttix (arutelu | kaastöö)
218 muudatust
 
(ei näidata sama kasutaja 72 vahepealset redaktsiooni)
2. rida: 2. rida:
== Schedule ==
== Schedule ==


Lecture TH 12:00 - 13:30
Lecture TH 17:45 - 21:15 (odd weeks)


Practice FR 14:00 - 17:30
Practice TH 17:45 - 21:15 (even weeks)


== Communication ==
== Communication ==


Discussinons will be held at: itx8080 atatat googlegroups.com
Discussinons will be held at course forum in Moodle.


Send e-mail to hannesa at-no-spam-please gmail.com for an invitation.
https://moodle.e-ope.ee/course/view.php?id=4319
 
All scenario proposals must be posted to their own respective forums.
 
Please register your account today at http://moodle.e-ope.ee


The lecturers can be reached via the course coordinator:  
The lecturers can be reached via the course coordinator:  
16. rida: 20. rida:
antti.andreimann only-people-please eesti.ee
antti.andreimann only-people-please eesti.ee


== Points awarded so far ==
= Grading =
 
Best of the bunch will score points.


Arnis : 2 points - ab testing solution, best countermeasure proposed for 4
Points will be awareded for the:


Igor : 2 points - wordpress virtualization solution, lab 3 report
* Best simulation proposal
* Best result obtained in the lab environment
* Best lab report


Kaarel : 2 points - lab 1 report and conclusions, lab 3 solution
In total it is possible to score three points for every two weeks.


Märt : 3 points - wordpress testing procedure, best wordpress optimization (wp-cache + php-apc), best lab 2 report.
Maximum score is 3, nobody will be awareded more.


Roland: 1 point - best Lab 4 report
Minimum score to pass is 1.


= Scenarios =
For those who can not score a single point, an
examination proposals will received from those
of you who scored 3 and voted.
 
== Points scored so far ==
 
Margus - 3pts (lecture 1 vote, lab 2 testing method, lab 3 result)


== Scenario 1 ==
Andres - 1pts (best lab 1 report)
There is a Wordpress based blog.


The client is worried: How many visitors can they handle before they die.
Michal - 1pts (best lab 1 result)


Establish a baseline: How many page displays per second AT LEAST we can handle.
Alexandre - 1pts (best lab 2 result)
Disruption of the site operation is NOT acceptable.


Minimal budget!
Roman - 1pts (best lab 2 report)


Be as detailed and technical as You possibly can.
Allan - 3pts (best lab 3 proposal with Predrag, lucky SOB scenario 4 proposal, best scenario 5 proposal)


Post to the discussion group the following information:
Predrag - 2pts (best lab 3 proposal with Allan, best scenario 5 proposal)


# Detailed description of the simulation of the site. eg. if You're going to virtualize it then how? If You are running it as a process, then how You separate it from the real machine?
Mauno P - 3pts (best lab 3 report, best lab 4 report, best scenario 7 proposal)
# Detailed description of the attack / benchmark tools picked. Where You are going to run them? What tools? How many copies? How you are going to collect the results?!!!


=== Proposals ===
Robert P - 3 pts (best scenario 4 proposal, best lab 4 result, best lab 5 result)
Benchmarking:
* AB - Discussed in lecture
* http://tsung.erlang-projects.org - Jérémy
* wget + AB - Arnis
* http://jakarta.apache.org/jmeter/ - Roland, Jérémy
* http://grinder.sourceforge.net/ - Märt
* http://httpd.apache.org/test/flood/ - Hannes
* Normal monitoring software on live server - Urmas


Simulation of the system:
Anis - 1 pts (best lab 4 result)
* VirtualBox - Roland, Jérémy
* VMWare ESX - Igor
* VMWare Player - Marina
* Amazon EC2 - Märt
* KVM - Siim
* Original hardware - Hannes


=== Lab 1 ===
Mart - 1 pts (best lab 5 report)
We will need to create two different virtual machines, one is going to be the wordpress server and the 2nd one is the client which is used to attack the server. It's probably easiest to install only one image and then clone it.


Hard disk image cloning is best done with
Ronny - 1 pts (best lab 7 report)


Linux:
Mikheil - 1 pts (best lab 6 report)
VBoxManage clonehd FirstUbuntu.vdi SecondUbuntu.vdi


Windows:
Jan - 1pts (best lab 8 result)
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" clonehd FirstUbuntu.vdi SecondUbuntu.vdi


After cloning the image create another virtual machine and attach the 2nd disk to that machine. As the result there will be two different virtual machines with two different virtual hard disks.
Franck - 1pts (best lab 8 report)


To be able to connect between the two virtual machines, You need to add an
= Scenarios =
additional network adapter to both hosts. It can be either "Host Only" or
"Internal" type.


To enable the new adapters in Ubuntu edit the file: /etc/network/interfaces
== Scenario 1 ==


== Scenario 2 ==
There is a Wordpress based blog.
Design a method for evaluating any speedup solutions for the wordpress.
A repeatable process to evaluate the claims.
Whatever optimizations.
The process must be detailed enough so that somebody else can get the same results when applying that.
The @other person@ is expected to have IT knowledge sufficient to install and run a Linux desktop.
The method must specify the level performance
at which the site is considered DEAD.
Budget requirements: Low - Dedicated machine + dedicated tester.


=== Lab 2 ===
The client is worried: How many visitors can they handle before they die.
* Get Virtual machine disk image and instructions from: http://www.tud.ttu.ee/~anttix/lab2/ <br /> '''NB! DO NOT DOWNLOAD IMAGE FROM THE LINK NOTED IN INSTRUCTIONS PDF, IT WILL BE SLOW'''
* Fix bug in image (see below)
* Measure the effect of these wordpress plugins:
** [http://wordpress.org/extend/plugins/wp-super-cache/ WP Super Cache]
** [http://wordpress.org/extend/plugins/wp-cache/ WP-Cache]
* Devise Your own optimizations for the site


Bug in image: the ip address of the VM is saved in WP database as 192.168.56.3
Establish a baseline: How many page displays per second AT LEAST we can handle.
It is advised tu run the Target VM first and run the "sudo dhclient" command first in Target VM.
Disruption of the site operation is NOT acceptable.
Then check active IP of target by command "ifconfig".  If it is not 192.168.56.3, then situation can be fixed by running:
In Target VM: "sudo ifconfig eth2 192.168.56.3"
In Client VM: "sudo ifconfig eth2 192.168.56.4"


==== A note to Windows users ====
Minimal budget!
Use this command line to access VBoxManage program


"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe"
Assume upstream bandwidth can cope...


==== Wordpress Admin access ====
Be as detailed and technical as You possibly can.
Username: admin
Password: QIaTemvskSeM


=== Proposals ===


==== Note to Ubuntu users ====
* Install a similar system on test hardware
VirtualBox with WiFi Does NOT work properly http://ubuntuforums.org/showthread.php?t=782936
** Test hardware is smaller than
* Extrapolate from current system logs
** Must have some load ...
** It may NOT be linear (it usually isn't!)
* Generate some load (without breaking it) and extrapolate from logs
* Find existing performance graphs for wordpress ... (highly unlikely)


== Scenario 3 ==
=== Simulation environment ===
Your client is worried about some stuff posted on a blog. They ask You to take care of it.
They have a throwaway "script kiddie" in a third world country, who will mount the attack
so You don't need to worry about hiding the attackers identity.


Devise a way to attack a wordpress (default installation) based site to render it
* Real hardware
unusable (page view times over 60 seconds).
* Virtualization platform


Attack resources: one PC, a script kiddie, internet connection of 2Mbit/s.
Pick what is closer to the real system.


How are we going to evaluate the solutions?
=== Benchmarking tools ===
* Easy to use instructions
* The most efficient use of available resources


Defacing will count, IF it works for the latest version of wordpress.
* httpPerf
* pagetop
* htop
* AB - apache bench
* curl / wget + custom scripts
* JMeter
* Grinder
* wpscan - wordpress specific


=== Lab 3 ===
=== How to separate benchmark tools from the server? ===
Possible attacks:


* Brute force overload (AB or other benchmark), bang the slowest page possible.
* Use to VMs, Use CPU allocation in virtualization environment to allocate different CPUs for different VMs
* Connection flood (slowloris)
* Put VM disk images on different disks (probably an overkill)?
* SYN Flood (eg. with hping)
* Monitor process table and make sure that test tools consume significantly less than web server processes. Lower the priority of the test tools.
* Banging expensive operations (eg. adding big comments)
* Start monitoring load and page views. Generate some load on real system. How?
* etc.


== Scenario 4 ==
How do we define the system is dead?
Develop countermeasures for the attacks simulated in Lab 3.


Limitations:
Page view takes longer than 10sec.
* No additional hardware
* No reactive measures


=== Lab 4 ===
=== Determining if referenced content has an effect on results ===
* Make a list of all references the main page has
* Measure the performance of all the URLs
* Disregard the ones that load at least two magnitudes faster.


Evaluate the countermeasures against attacks.
=== How to measure the results? ===
The countermeasures must not have negative effects
on "normal usage pattern".


Normal usage pattern is defined as:
* Measure response times and number of parallel requests using the benchmarking tool itself
* Bursts of 10 connections per IP address in 1 second
* Deduct the numbers from server logs
* Page load times not over 20 seconds
* Put the system under load, test with a normal browser if the load time is reasonable.


== Scenario 5 ==
=== What to document? ===
Create a solution and instructions for testing IDS
systems against the wordpress site and attacks
tried in lab 3.


A repeatable process to evaluate the claims.
* Exact configuration of the benchmarking tool (command line, scripts, config files etc. for EACH test performed)
Whatever passive IDS system delivered as a VM or a dedicated box.
* The version of the benchmarking tool used
* Virtualization platform
* Hardware specification
* URL of the page tested
* Wordpress configuration
* Wordpress content !!!
* Wordpress version
* Web server configuration
* Web server version (apache, php, sql, etc)
* The measurement results (page load times under each different test)
* Web browser used to measure response time (type, version, operating system)
* Operating system configuration (version, software installed, customizations etc).
* The AUTHOR! and the DATE!


Creating the IDS system itself is out of scope.
Write evertyhing down at ONCE.
if using VM-s save the image.


The process must be detailed enough so that somebody else can get the same results when applying that.
=== Lab1 ===
The "other person" is expected to have IT knowledge sufficient to install and run a Linux desktop.


Budget requirements: Modest - 2 Dedicated machines + dedicated tester + networking equipment to connect these together.
* Virtualization platform: VirtualBox
** 512M memory, 1 CPU for each VM
* Wordpress 3.2.1 with default settings (no extra plugins, no performance tweaks, default skin) and default home page
* Ubuntu Server 10.04 LTS 32bit
* Web server: Apache2, SQL: MySQL (default versions bundled with OS)
* Point will go to the person that can produce the most dense graph showing the number of concurrent connections against the response time. Individual tests used to plot the data must be repeated at least 3 times.


The process must test at least the following:
* Port scan
* SYN flood
* slowloris/pyloris
* Ab overwhelming attack


=== Lab 5 ===
You will need to create two different virtual machines, one is going to be the wordpress server and the 2nd one is the client which is used to attack the server.
Instructions for installing Snort IDS and its web GUI called 'acidbase': https://help.ubuntu.com/community/SnortIDS


== Scenario 6 ==
To be able to connect between the two virtual machines, You need to add an additional network adapter to both hosts. It can be either "Host Only" or "Internal" type.


Develop/download/find/whatever a SNORT configuration (rulesets, preprocessors, whatever)
To enable the new adapters in Ubuntu edit the file: /etc/network/interfaces
that performs better than the default configuration in lab 5 tests.
By better we mean:
* Less false positives
* Less false negatives
* The objectives are contradictory so the rule of thumb is one false negative per 10 false positives eg. solution with 10 false positives and 2 false negatives is better than the solution with 100 false positives and 1 false negatives, but the solution with 10 false positives and 1 false negative is better than the solution with 1 false positive and 2 false negatives.
* Attack is defined by a single invocation of the test script.

Viimane redaktsioon: 21. detsember 2011, kell 01:55

General Information

Schedule

Lecture TH 17:45 - 21:15 (odd weeks)

Practice TH 17:45 - 21:15 (even weeks)

Communication

Discussinons will be held at course forum in Moodle.

https://moodle.e-ope.ee/course/view.php?id=4319

All scenario proposals must be posted to their own respective forums.

Please register your account today at http://moodle.e-ope.ee

The lecturers can be reached via the course coordinator:

antti.andreimann only-people-please eesti.ee

Grading

Best of the bunch will score points.

Points will be awareded for the:

  • Best simulation proposal
  • Best result obtained in the lab environment
  • Best lab report

In total it is possible to score three points for every two weeks.

Maximum score is 3, nobody will be awareded more.

Minimum score to pass is 1.

For those who can not score a single point, an examination proposals will received from those of you who scored 3 and voted.

Points scored so far

Margus - 3pts (lecture 1 vote, lab 2 testing method, lab 3 result)

Andres - 1pts (best lab 1 report)

Michal - 1pts (best lab 1 result)

Alexandre - 1pts (best lab 2 result)

Roman - 1pts (best lab 2 report)

Allan - 3pts (best lab 3 proposal with Predrag, lucky SOB scenario 4 proposal, best scenario 5 proposal)

Predrag - 2pts (best lab 3 proposal with Allan, best scenario 5 proposal)

Mauno P - 3pts (best lab 3 report, best lab 4 report, best scenario 7 proposal)

Robert P - 3 pts (best scenario 4 proposal, best lab 4 result, best lab 5 result)

Anis - 1 pts (best lab 4 result)

Mart - 1 pts (best lab 5 report)

Ronny - 1 pts (best lab 7 report)

Mikheil - 1 pts (best lab 6 report)

Jan - 1pts (best lab 8 result)

Franck - 1pts (best lab 8 report)

Scenarios

Scenario 1

There is a Wordpress based blog.

The client is worried: How many visitors can they handle before they die.

Establish a baseline: How many page displays per second AT LEAST we can handle. Disruption of the site operation is NOT acceptable.

Minimal budget!

Assume upstream bandwidth can cope...

Be as detailed and technical as You possibly can.

Proposals

  • Install a similar system on test hardware
    • Test hardware is smaller than
  • Extrapolate from current system logs
    • Must have some load ...
    • It may NOT be linear (it usually isn't!)
  • Generate some load (without breaking it) and extrapolate from logs
  • Find existing performance graphs for wordpress ... (highly unlikely)

Simulation environment

  • Real hardware
  • Virtualization platform

Pick what is closer to the real system.

Benchmarking tools

  • httpPerf
  • pagetop
  • htop
  • AB - apache bench
  • curl / wget + custom scripts
  • JMeter
  • Grinder
  • wpscan - wordpress specific

How to separate benchmark tools from the server?

  • Use to VMs, Use CPU allocation in virtualization environment to allocate different CPUs for different VMs
  • Put VM disk images on different disks (probably an overkill)?
  • Monitor process table and make sure that test tools consume significantly less than web server processes. Lower the priority of the test tools.
  • Start monitoring load and page views. Generate some load on real system. How?

How do we define the system is dead?

Page view takes longer than 10sec.

Determining if referenced content has an effect on results

  • Make a list of all references the main page has
  • Measure the performance of all the URLs
  • Disregard the ones that load at least two magnitudes faster.

How to measure the results?

  • Measure response times and number of parallel requests using the benchmarking tool itself
  • Deduct the numbers from server logs
  • Put the system under load, test with a normal browser if the load time is reasonable.

What to document?

  • Exact configuration of the benchmarking tool (command line, scripts, config files etc. for EACH test performed)
  • The version of the benchmarking tool used
  • Virtualization platform
  • Hardware specification
  • URL of the page tested
  • Wordpress configuration
  • Wordpress content !!!
  • Wordpress version
  • Web server configuration
  • Web server version (apache, php, sql, etc)
  • The measurement results (page load times under each different test)
  • Web browser used to measure response time (type, version, operating system)
  • Operating system configuration (version, software installed, customizations etc).
  • The AUTHOR! and the DATE!

Write evertyhing down at ONCE. if using VM-s save the image.

Lab1

  • Virtualization platform: VirtualBox
    • 512M memory, 1 CPU for each VM
  • Wordpress 3.2.1 with default settings (no extra plugins, no performance tweaks, default skin) and default home page
  • Ubuntu Server 10.04 LTS 32bit
  • Web server: Apache2, SQL: MySQL (default versions bundled with OS)
  • Point will go to the person that can produce the most dense graph showing the number of concurrent connections against the response time. Individual tests used to plot the data must be repeated at least 3 times.


You will need to create two different virtual machines, one is going to be the wordpress server and the 2nd one is the client which is used to attack the server.

To be able to connect between the two virtual machines, You need to add an additional network adapter to both hosts. It can be either "Host Only" or "Internal" type.

To enable the new adapters in Ubuntu edit the file: /etc/network/interfaces

Pärit leheküljelt "http://www.lambda.ee/w/index.php?title=ITX8080&oldid=8433"