1 / 14

Intro to Internet-services from Security Standpoint

Intro to Internet-services from Security Standpoint. SOEN321-Information-Systems Security Revision 1.3 Date: November 13, 2003. Connectivity. As you know: Networked computer are more open to the attacks Attacks may come from an unknown source (if there is a number of access points)

Download Presentation

Intro to Internet-services from Security Standpoint

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Intro to Internet-services from Security Standpoint SOEN321-Information-Systems Security Revision 1.3 Date: November 13, 2003 Serguei A. Mokhov, mokhov@cs.concordia.ca

  2. Connectivity • As you know: • Networked computer are more open to the attacks • Attacks may come from an unknown source (if there is a number of access points) • Even over the phone lines connectivity matters. • A connected system as secure as it’s most far-reaching point. Serguei A. Mokhov, mokhov@cs.concordia.ca

  3. Disconnect! • To lock a computer in a safe and cut all the wires, including power supply is often not a solution. • The Internet is now a mission critical network for many businesses and research facilities. • The Internet is a bar of good and bad peeps, with the former outnumbering the latter; however, the latter do usually posses tools to use the Internet to attack remotely, anonymously, etc. the interconnected computers. Serguei A. Mokhov, mokhov@cs.concordia.ca

  4. Connecting Trusted Computers to an Untrustworthy Network • How can we do it safely? • One way use a firewallto separate trusted stuff from the untrusted one. • A firewall can be either hardware (PC or router) or software or both, which sits in between the two stuffs. • It limits network access between the two security domains, and monitors and logs connections. • Filters out connections based on source/destinations addresses, ports, direction, etc. Serguei A. Mokhov, mokhov@cs.concordia.ca

  5. Firewall • Example, you you run a web server, you can set the firewall to let only the incoming HTTP connections through to communicate with the web browsers. • The Morris Worm used finger protocol to spread, obviously you really wan to filter it out (in case you do use fingerd in your LAN at all). Serguei A. Mokhov, mokhov@cs.concordia.ca

  6. Firewall • Can split a network into more than two domains • The Internet is untrusted domain • Demilitarized zone (DMZ) – a semitrusted domain • Local domain Serguei A. Mokhov, mokhov@cs.concordia.ca

  7. Firewall Serguei A. Mokhov, mokhov@cs.concordia.ca

  8. Firewall • Sometimes it is possible to for a special DMZ computer to connect to a local one: example a web server accessing an application or DB servers. But this connection is controlled. • The firewall still sort of protects company’s machines even when DMZ is broken into. Serguei A. Mokhov, mokhov@cs.concordia.ca

  9. Firewall • What about its security? • It must be secure and attack proof, as much as possible; otherwise, what’s a point? • DoS attacks are still very possible. • Firewalls do not prevent tunneled attacks (that travel within allowed traffic) • E.g. distributed COM objects can be used over HTTP. • RPC (e.g. Win32 Blast) • A buffer overflow in the web server will NOT be stopped by a firewall, because HTTP is allowed. • Spoofing – pretending of an unauthorized host be an authorized one (e.g. IP ident and spoofing). • Inside attacks are not guarded against. Serguei A. Mokhov, mokhov@cs.concordia.ca

  10. Firewall Types • Packet Filters • Stateless • Stateful • Application-level Gateways (proxies) Serguei A. Mokhov, mokhov@cs.concordia.ca

  11. Packet Filters • Real-time decisions are made to drop or forward a packet. • Based on raw packet data, such as source and/or destination IP, port ##, headers, sizes, etc. and sometimes even application data (won’t always work). • A: Very efficient, no buffering and assembly of packets; real-time. Totally transparent; easier to administer since no knowledge needed of the client and server software. Widely available. • D: Rules are difficult to state and to test. Limited # of policies, and from rules it’s hard to see what exactly the policy is enforced. Serguei A. Mokhov, mokhov@cs.concordia.ca

  12. Application Level Gateways • Proxies • Understanding of services being proxied (look at the application data within packets). • Stubs, client, server. • AC decisions made by the proxy. • Decisions are at much more finer granularity. • More extensive and accurate logging. • Caching. • NOT transparent: alteration of client software required to be able to talk to proxy vs. a server. Proxy versions of server software have to written as well, hence a lot of effort required to administer such firewalls. Performance penalties are pertinent. Serguei A. Mokhov, mokhov@cs.concordia.ca

  13. Firewall vs. Sandbox • Firewall protects network perimeter from adversarial input and all application and system software behind. • Sandboxing mechanisms are at the level of computer security perimeter and protects System Software (e.g. OS) from untrusted applications. Serguei A. Mokhov, mokhov@cs.concordia.ca

  14. Firewall vs. Intrusion-Detection System • Firewalls are active entities, filtering packets according to some rules (active in a sense deciding to “allow or disallow” certain packets). • Network-level access control policy • IDS in a general way is a passive entity observing ALL the traffic and logging it, but not stopping it (some IDS do take counteractions). • Auditing Serguei A. Mokhov, mokhov@cs.concordia.ca

More Related