Difference between revisions of "Distributed OS: Winter 2011"

From Soma-notes
Jump to navigation Jump to search
Line 37: Line 37:
*Stopping DDoS against files, services, programs, etc
*Stopping DDoS against files, services, programs, etc
**Have file replication built into the system (similar to OceanStore) so that files are always available from different servers
**Have file replication built into the system (similar to OceanStore) so that files are always available from different servers
**If files are not replicated then we could have a tiered messaging system (at the top level would be OS messages) and servers could then prioritize the incoming traffic. If a given server is experiencing an overload, it could send out a distress signal to its neighbours and then distribute what it is has to them. This would then mean that any DDoS attack would result in the service being more available.
**If files are not replicated then we could have a tiered messaging system (at the top level would be OS messages) and servers could then prioritize the incoming traffic. If a given server is experiencing an overload, it could send out a distress signal to its neighbours and then distribute what it is has to them. The system should have a built-in mechanism to re-balance the overall load after something like this happens. This would then mean that any DDoS attack would result in the service being more available.


*Stopping DDoS against specific machines
*Stopping DDoS against specific machines

Revision as of 19:40, 19 January 2011

Readings

January 13, 2011: CCR (two papers)

January 18, 2011: OceanStore and Pond

Internet Governance

Problems to Solve

  • Attack computers with almost no consequences
    • DDoS
    • botnets
    • capture and analyze private traffic
    • distribute malware
    • tampering with traffic
    • Unauthorized access to data and resources
    • Impersonate computers, individuals, applications
    • Fraud, theft
    • regulate behavior

Design Principles

  • subjects of governance: programs and computers
  • bind programs and computers to humans & human organizations, but recognize binding is imperfect
  • recognize that "bad" behavior is always possible. "good" behavior is enforced through incentives and sanctions.
  • rules will change. Even rules for rule changes will change. Need a "living document" governing how rules are chosen and enforced.

Scenarios

1: Stopping DDoS

Group members: Seyyed, Andrew Schoenrock, Thomas McMahon

  • Have the machine routing packets(could be ISP provider) detect suspicious packets, if the packets are signed, then those suspicious packets could be blocked,

the sender could be put on a black list.


  • Stopping DDoS against files, services, programs, etc
    • Have file replication built into the system (similar to OceanStore) so that files are always available from different servers
    • If files are not replicated then we could have a tiered messaging system (at the top level would be OS messages) and servers could then prioritize the incoming traffic. If a given server is experiencing an overload, it could send out a distress signal to its neighbours and then distribute what it is has to them. The system should have a built-in mechanism to re-balance the overall load after something like this happens. This would then mean that any DDoS attack would result in the service being more available.
  • Stopping DDoS against specific machines
    • I don't think that this should be specifically addressed. I think measures introduced to guard against this will ultimately negatively impact the overall system in terms of performance.

2: Stopping phishing

Group members: Waheed Ahmed, Nicolas Lessard, Raghad Al-Awwad

  • A way of automatically checking the signature of a message to make sure it really is from a trusted source.
    • ie: "Nation of Banks, did your member TD send me a message to reset my password?"

3: Limiting the spread of malware

Group members: keith, Andrew, David Barrera


4: Bandwidth hogs

Group members: Mike Preston, Fahim Rahman, Michael Du Plessis

  • limit bandwidth for each user
  • if user has significant bandwidth demands for a certain period of time
    • add them to a watch list
    • monitor their behaviour