hack book hack proofing your network internet tradecraft phần 8 docx

sonal judgment and quality analysis skills of another: themselves! Even those who devote themselves to their own evaluations still increase the pool of experts available to provide informed opinions; a cadre of trusted third parties eventually sprouts up to provide information without the financial conflict of interest that can color or suppress truth—and thus trustworthiness. Philosophy, Psychology, Epistemology, and even a bit of Marketing Theory—what place does all this have in a computer security text? The answer is simple: Just because something’s Internet related doesn’t mean it’s neces- sarily new. Teenagers didn’t discover that they could forge their identities online by reading the latest issue of Phrack; beer and cigarettes have taught more people about spoofing their identity than this book ever will. The ques- tion of who, how, and exactly what it means to trust (in the beer and cigarettes case, “who can be trusted with such powerful chemical substances”) is ancient; far more ancient than even Descartes. But the paranoid French philosopher deserves mention, if only because even he could not have imag- ined how accurately computer networks would fit his model of the universe. The Evolution of Trust One of the more powerful forces that guides technology is what is known as network effects, which state that the value of a system grows exponentially with the number of people using it. The classic example of the power of net- work effects is the telephone: one single person being able to remotely contact another is good. However, if five people have a telephone, each of those five can call any of the other four. If 50 have a telephone, each of those 50 can easily call upon any of the other 49. Let the number of telephones grow past 100 million. Indeed, it would appear that the value of the system has jumped dramatically, if you measure value in terms of “how many people can I remotely contact.” But, to state the obvious question: how many of those newly accessible people will you want to remotely contact? Now, how many of them would you rather not remotely contact you? Asymmetric Signatures between Human Beings At least with voice, the worst you can get is an annoying call on a traceable line from disturbed telemarketers. Better yet, even if they’ve disabled caller ID, their actual voice will be recognizable as distinctly different from that of your friends, family, and coworkers. As a human being, you possess an extraordi- narily fine-grained recognition system capable of extracting intelligible and identifying content from extraordinarily garbled text. There turns out to be enough redundancy in average speech that even when vast frequency bands are removed, or if half of every second of speech is rendered silent, we still can understand most of what we hear. 314 Chapter 11 • Spoofing: Attacks on Trusted Identity www.syngress.com 95_hack_prod_11 7/13/00 11:57 AM Page 314 NOTE We can generally recognize the “voiceprint” of the person we’re speaking to, despite large quantities of random and nonrandom noise. In technical termi- nology, we’re capable of learning and subsequently matching the complex nonlinear spoken audio characteristics of timbre and style emitted from a single person’s larynx and vocal constructs across time and a reasonably decent range of sample speakers, provided enough time and motivation to absorb voices. The process is pointedly asymmetric; being able to recognize a voice does not generally impart the ability to express that voice (though some degree of mimicry is possible). Speech, of course, isn’t perfect. Collisions, or cases where multiple individ- uals share some signature element that cannot be easily differentiated from person to person (in this case, vocal pattern), aren’t unheard of. But it’s a system that’s universally deployed with “signature content” contained within every spoken word, and it gives us a classical example of a key property that, among other things, makes after-the-fact investigations much, much simpler in the real world: Accidental release of identifying information is normally common. When we open our mouths, we tie our own words to our voice. When we touch a desk, or a keyboard, or a remote control, we leave oils and an imprint of our unique fingerprints. When we leave to shop, we are seen by fellow shoppers and possibly even recognized by those we’ve met before. However, my fellow shoppers cannot mold their faces to match mine, nor slip on a new pair of fingerprints to match my latest style. The information we leave behind regarding our human identities is substantial, to be sure, but it’s also asymmetric. Traits that another individual can mimic successfully by simply observing our behavior, such as usage of a “catch phrase” or possession of an article of clothing, are simply given far less weight in terms of identifying who we are to others. Deciding who and who not to trust can be a life or death judgment call—it is not surprising that humans, as social creatures, have surprisingly complex systems to determine, remember, and rate various other individuals in terms of the power we grant them. Specifically, the facial recognition capabilities of infant children have long been recognized as extraordinary. However, we have limits to our capabilities; our memories simply do not scale, and our time and energy are limited. As with most situations when a core human task can be simplified down to a rote procedure, technology has been called upon to repre- sent, transport, and establish identity over time and space. That it’s been called upon to do this for us, of course, says nothing about its ability to do so correctly, particularly under the hostile conditions that this book describes. Programmers generally program for what’s known as Murphy’s Spoofing: Attacks on Trusted Identity • Chapter 11 315 www.syngress.com 95_hack_prod_11 7/13/00 11:57 AM Page 315 Computer, which presumes that everything that can go wrong, will, at once. Seems appropriately pessimistic, but it’s the core seed of mistaken identity from which all security holes flow. Ross Anderson and Roger Needham instead suggest systems be designed not for Murphy’s Computer but, well, Satan’s. Satan’s Computer only appears to work correctly. Everything’s still going wrong. Establishing Identity within Computer Networks The problem with electronic identities is that, while humans are very used to trusting one another based on accidental disclosure (how we look, the prints we leave behind, etc.), all bits transmitted throughout computer networks are explicitly chosen and equally visible, recordable, and repeatable, with perfect accuracy. This portability of bits is a central tenet of the digital mindset; the intolerance for even the smallest amount of signal degradation is a proud stand against the vagaries of the analog world, with its human existence and moving parts. By making all signal components explicit and digital, signals can be amplified and retransmitted ad infinitum, much unlike the analog world where excess amplification eventually drowns whatever’s being spoken under- neath the rising din of thermal noise. But if everything can be stored, copied, repeated, or destroyed, with the recipients of those bits none the wiser to the path they may or may not have taken… Suddenly, the seemingly miraculous fact that data can travel halfway around the world in milliseconds becomes tempered by the fact that only the data itself has made that trip. Any ancillary signal data that would have uniquely identified the originating host—and, by extension, the trusted identity of the person operating that host—must either have been included within that data, or lost at the point of the first digital duplicator (be it a router, a switch, or even an actual repeater). This doesn’t mean that identity cannot be transmitted or represented online, but it does mean that unless active measures are taken to establish and safeguard identity within the data itself, the recipient of any given message has no way to identify the source of a received request. NOTE Residual analog information that exists before the digital repeaters go to work is not always lost. The cellular phone industry is known to monitor the transmission characteristics of their client’s hardware, looking for instances where one cellular phone clones the abstract data but not the radio fre- quency fingerprint of the phone authorized to use that data. The separation 316 Chapter 11 • Spoofing: Attacks on Trusted Identity www.syngress.com 95_hack_prod_11 7/13/00 11:57 AM Page 316 between the easy-to-copy programmable characteristics and the impossible- to-copy physical characteristics makes monitoring the analog signal a good method for verifying otherwise cloneable cell phone data. But this is only feasible because the cellular provider is always the sole provider of phone service for any given phone, and a given phone will only be used for one and only one cell phone number at a time. Without much legitimate reason for transmission characteristics on a given line changing, fraud can be deduced from analog variation. Return to Sender But, data packets on the Internet do have return addresses, as well as source ports that are expecting a response back from a server. It says so in the RFCs, and shows up in packet traces. Clients provide their source address and port to send replies to, and send that packet to the server. This works perfectly for trusted clients, but if all clients were trusted, there’d be no need to implement security systems. You’d merely ask the clients whether they think they’re authorized to view some piece of data, and trust their judgment on that matter. Since the client specifies his own source, and networks only require a des- tination to get a packet from point Anywhere to point B, source information must be suspect unless every network domain through which the data traveled is established as trusted. With the global nature of the Internet, such judg- ments cannot be made with significant accuracy. Spoofing: Attacks on Trusted Identity • Chapter 11 317 www.syngress.com Appropriate Passwording You’d be surprised how many systems work this way (i.e., ask and ye shall receive). The original UNIX systems, as they were being built, often were left without root passwords. This is because the security protecting them was of a physical nature—they were protected deep within the bowels of Bell Labs. Even in many development environments, root passwords are thrown around freely for ease of use; often merely asking for access is enough to receive it. The two biggest mistakes security administrators make when dealing with such environments is 1) Being loose with passwords when remote access is easily available, and 2) Refusing to be loose with passwords when remote access is sufficiently restricted. Give developers a playground— they’ll make one anyway; it might as well be secure. For IT Professionals 95_hack_prod_11 7/13/00 11:57 AM Page 317 The less the administrator is aware of, though, the more the administrator should be aware of what he or she has understanding of. It’s at this point—the lack of understanding phase—that an admin must make the decision of whether to allow any users networked access to a service at all. This isn’t about selective access; this is about total denial to all users, even those who would be authorized if the system could a) be built at all, and b) secure to a reasonable degree. Administrators who are still struggling with the first phase should generally not assume they’ve achieved the second unless they’ve iso- lated their test lab substantially, as security and stability are two halves of the same coin. Most security failures are little more than controlled failures that result in a penetration, and identity verification systems are certainly not immune to this pattern. Having determined, rightly or wrongly, that a specific system should be made remotely accessible to users, and that a specific service may be trusted to identify whether a client should be able to retrieve specific content back from a server, two independent mechanisms are (always) deployed to imple- ment access controls. In the Beginning, There Was…a Transmission At its simplest level, all systems—biological or technological—can be thought of as determining the identities of their peers through a process I refer to as a capability challenge. The basic concept is quite simple: There are those whom you trust, and there are those whom you do not. Those whom you do trust have specific abilities that those whom you do not trust, lack. Identifying those differences leaves you with a trusted capabilities index. Almost anything may be used as a basis for separating trustworthy users from the untrusted masses—provided its existence can be and is transmitted from the user to the authenticating server. In terms of spoofing, this essentially means that the goal is to transmit, as an untrusted user, what the authenticating agent believes only a trusted user should be able to send. Should that fail, a compromise against the trusted capabilities index itself will have devastating effects on any cryptosystem. I will be discussing the weaknesses in each authentication model. There are six major classifications into which one can classify almost all authentication systems. They range from weakest to strongest in terms of proof of identity, and simplest to most complicated in terms of simplicity to implement. None of these abilities occur in isolation—indeed, it’s rather use- less to be able to encode a response but not be able to complete transmission of it, and that’s no accident—and in fact, it turns out that the more compli- cated layers almost always depend on the simpler layers for services. That being said, I offer in Tables 11.1 and 11.2 the architecture within which all proofs of identity should fit. 318 Chapter 11 • Spoofing: Attacks on Trusted Identity www.syngress.com 95_hack_prod_11 7/13/00 11:57 AM Page 318 Table 11.1 Classifications in an Authentication System Ability English Examples Transmit “Can it talk to me?” Firewall ACLs (Access Control Lists), Physical Connectivity Respond “Can it respond to me?” TCP Headers, DNS (Domain Name System) Request IDs Encode “Can it speak my NT/Novell Login Script Initialization, language?” “Security through Obscurity” Prove “Does it share a secret Passwords, TACACS+ (Terminal Access Shared with me?” Controller Access Control System) Keys Secret Prove “Does it match my PGP (Pretty Good Privacy), S/MIME (Secure Private public keypair?” Multipurpose Internet Mail Extensions) Keypair Prove “Is its identity inde- SSH (Secure Shell), SSL (Secure Sockets Identity pendently represented Layer) through Certificate Authority (CA), Key in my keypair?” Dynamically Rekeyed OpenPGP This, of course, is no different than interpersonal communication (Table 11.2). No different at all Table 11.2 Classifications in a Human Authentication System Ability Human Human “Capability Challenge” “Trusted Capability Index” Transmit Can I hear you? Do I care if I can hear you? Respond Can you hear me? Do I care if you can hear me? Encode Do I know what you just said? What am I waiting for some- body to say? Prove Shared Do I recognize your password? What kind of passwords do I Secret care about? Prove Private Can I recognize your voice? What exactly does this “chosen Keypair one” sound like? Prove Identity Is your tattoo still there? Do I have to look? Key Spoofing: Attacks on Trusted Identity • Chapter 11 319 www.syngress.com 95_hack_prod_11 7/13/00 11:57 AM Page 319 Capability Challenges The following details can be used to understand the six methods listed in Tables 11.1 and 11.2. Ability to Transmit: “Can It Talk to Me?” At the core of all trust, all networks, all interpersonal and indeed all intraper- sonal communication itself, can be found but one, solitary concept: Transmission of information—sending something that could represent any- thing somewhere. This does not in any way mean that all transmission is perfect. The U.S. Department of Defense, in a superb (as in, must read, run, don’t walk, bookmark and highlight the URL for this now) report entitled Realizing the Potential of C4I, notes the following: The maximum benefit of C4I [command, control, communications, computers, and intelligence] systems is derived from their interop- erability and integration. That is, to operate effectively, C4I systems must be interconnected so that they can function as part of a larger “system of systems.” These electronic interconnections multiply many-fold the opportunities for an adversary to attack them. —Realizing the Potential of C4I www.nap.edu/html/C4I The only way to secure a system is not to plug it in. —Unknown A system entirely disconnected from any network won’t be hacked (at least, not by anyone without local console access), but it won’t be used much either. Statistically, a certain percentage of the untrusted population will attempt to access a resource they’re not authorized to use, a certain smaller percentage will attempt to spoof their identity. Of those who attempt, an even smaller but nonzero percentage will actually have the skills and motivation necessary to defeat whatever protection systems have been put in place. Such is the envi- ronment as it stands, and thus the only way to absolutely prevent data from ever falling into untrusted hands is to fail to distribute it at all. It’s a simple formula—if you want to prevent remote compromise, just remove all remote access—but also statistically, only a certain amount of trusted users may be refused access to data that they’re authorized to see before security systems are rejected as too bulky and inconvenient. Never forget the bottom line when designing a security system; your security system is much more likely to be forgotten than the bottom line is. Being immune from an attack is invisible, being unable to make payroll isn’t. As I said earlier, you can’t trust everybody, but you must trust somebody. If the people you do trust all tend to congregate within a given network that 320 Chapter 11 • Spoofing: Attacks on Trusted Identity www.syngress.com 95_hack_prod_11 7/13/00 11:57 AM Page 320 you control, then controlling the entrance (ingress) and exit (egress) points of your network allows you, as a security administrator, to determine what ser- vices, if any, users outside your network are allowed to transmit packets to. Firewalls, the well-known first line of defense against attackers, strip the ability to transmit from those identities communicating from untrusted domains. While a firewall cannot intrinsically trust anything in the data itself, since that data could have been forged by upstream domains or even the actual source, it has one piece of data that’s all its own: It knows which side the data came in from. This small piece of information is actually enough of a “network fingerprint” to prevent, among (many) other things, untrusted users outside your network from transmitting packets to your network that appear to be from inside of it, and even trusted users (who may actually be untrustable) from transmitting packets outside of your network that do not appear to be from inside of it. It is the latter form of filtering—egress filtering—that is most critical for preventing the spread of Distributed Denial of Service (DDoS) attacks, as it prevents packets with spoofed IP source headers from entering the global Internet at the level of the contributing ISP (Internet Service Provider). Egress filtering may be implemented on Cisco devices using the command ip verify unicast reverse-path; further information on this topic may be found at www.sans.org/y2k/egress.htm. Ability to transmit ends up being the most basic level of security that gets implemented. Even the weakest, most wide open remote access service cannot be attacked by an untrusted user if that user has no means to get a message to the vulnerable system. Unfortunately, depending upon a firewall to strip the ability to transmit messages from anyone who might threaten your network just isn’t enough to really secure it. For one, unless you use a “military-style firewall” (read: air firewall, or a complete lack of connection between the local network and the global Internet), excess paths are always likely to exist. The Department of Defense continues: The principle underlying response planning should be that of “graceful degradation”; that is, the system or network should lose functionality gradually, as a function of the severity of the attack compared to its ability to defend against it. Ability to Respond: “Can It Respond to Me?” One level up from the ability to send a message is the ability to respond to one. Quite a few protocols involve some form of negotiation between sender and receiver, though some merely specify intermittent or on-demand proclama- tions from a host announcing something to whomever will listen. When negoti- ation is required, systems must have the capability to create response transmissions that relate to content transmitted by other hosts on the net- work. This is a capability above and beyond mere transmission, and is thus separated into the ability to respond. Spoofing: Attacks on Trusted Identity • Chapter 11 321 www.syngress.com 95_hack_prod_11 7/13/00 11:57 AM Page 321 Using the ability to respond as a method of the establishing the integrity of the source’s network address is a common technique. As much as many might like source addresses to be kept sacrosanct by networks and for spoofing attacks the world over to be suppressed, there will always be a network that can claim to be passing an arbitrary packet while in fact it generated it instead. To handle this, many protocols attempt to cancel source spoofing by trans- mitting a signal back to the supposed source. If a response transmission, con- taining “some aspect” of the original signal shows up, some form of interactive connectivity is generally presumed. This level of protection is standard in the TCP protocol itself—the three-way handshake can essentially be thought of as, “Hi, I’m Bob.” “I’m Alice. You say you’re Bob?” “Yes, Alice, I’m Bob.” If Bob tells Alice, “Yes, Alice, I’m Bob,” and Alice hasn’t recently spoken to Bob, then the protocol can determine that a blind spoofing attack is taking place. In terms of network-level spoofs against systems that challenge the ability to respond, there are two different attack modes: blind spoofs, where the attacker has little to no knowledge of the network activity going in or coming out of a host (specifically, not the thus-far unidentified variable that the pro- tocol is challenging this source to respond with), and active spoofs, where the attacker has at least the full capability to sniff the traffic exiting a given host and possibly varying degrees of control over that stream of traffic. I’ll discuss these two modes separately. Blind Spoofing In terms of sample implementations, the discussions regarding connection hijacking in Chapter 10 are more than sufficient. From a purely theoretical point of view, however, the blind spoofer has one goal: Determine a method to predict changes in the variable (predictive), then provide as many possible transmissions as the protocol will withstand to hopefully hit the single correct one (probabilistic) and successfully respond to a transmission that was never received. One of the more interesting results of developments in blind spoofing has been the discovery of methods that allow for blind scanning of remote hosts. In TCP, certain operating systems have extremely predictable TCP header sequence numbers that vary only over time and number of packets received. Hosts on networks with almost no traffic become entirely dependent upon time to update their sequence numbers. An attacker can then spoof this quiet machine’s IP as the source of his port scan query. After issuing a query to the target host, an unspoofed connection is attempted to the quiet host. If the target host was listening on the queried TCP port, it will have ACKnowledged the connection back to the (oblivious) quiet host. Then, when the unspoofed connection was made by the attacker against the target host, the header sequence numbers will have varied by the amount of time since the last query, 322 Chapter 11 • Spoofing: Attacks on Trusted Identity www.syngress.com 95_hack_prod_11 7/13/00 11:57 AM Page 322 plus the unspoofed query, plus the previously spoofed response back from the target host. If the port wasn’t listening, the value would only vary by time plus the single unspoofed connection. Active Spoofing Most variable requests are trivially spoofable if you can sniff their release. You’re just literally proving a medium incorrect when it assumes that only trusted hosts will be able to issue a reply. You’re untrusted, you found a way to actively discover the request, and you’ll be able to reply. You win, big deal. What’s moderately more interesting is the question of modulation of the existing datastream on the wire. The ability to transmit doesn’t grant much control over what’s on the wire—yes, you should be able to jam signals by overpowering them (specifically relevant for radio frequency based media)—but generally transmission ability does not imply the capability to understand whatever anyone else is transmitting. Response spoofing is something more; if you’re able to actively determine what to respond to, that implies some advanced ability to read the bits on the wire (as opposed to the mere control bits that describe when a transmission may take place). This doesn’t mean you can respond to everything on the wire—the ability to respond is generally tapped for anything but the bare minimum for transmis- sion. Active bit-layer work in a data medium can include the following subca- pabilities: Ability to sniff some or all preexisting raw bits or packets Essentially, you’re not adding to the wire, but you’re responding to transmissions upon it by storing locally or transmitting on another wire. Ability to censor (corrupt) some or all preexisting raw bits or packets before they reach their destination Your ability to transmit within a medium has increased—now, you can scrub individual bits or even entire packets if you so choose. Ability to generate some or all raw bits or packets in response to sniffed packets The obvious capability, but obviously not the only one. Ability to modify some or all raw bits or packets in response to their con- tents Sometimes, making noise and retransmitting is not an option. Consider live radio broadcasts. If you need to do modification on them based on their content, your best bet is to install a sufficient signal delay (or co-opt the existing delay hardware) before it leaves the tower. Modulation after it’s in the air isn’t inconceivable, but it’s pretty close. Ability to delete some or all raw bits or packets in response to their con- tents Arbitrary deletion is harder than modification, because you lose sync with the original signal. Isochronous (uniform bitrate) streams require a delay to prevent the transmission of false nulls (you’ve gotta be sending something, right? Dead air is something.). Spoofing: Attacks on Trusted Identity • Chapter 11 323 www.syngress.com 95_hack_prod_11 7/13/00 11:57 AM Page 323 [...]... Server: ns1.internettradecraft.COM www.syngress.com 95 _hack_ prod_12 7/13/00 9:45 AM Page 349 Server Holes • Chapter 12 Address: 10.10.10.3 > ls internettradecraft.com [ns1.internettradecraft.COM] $ORIGIN internettradecraft.com @12H IN SOA ns1.internettradecraft.com hostmaster.internettradecraft.com ( 2000012100 ; serial 4H ; refresh 30M ; retry 5w6d16h ; expiry 12H ) ; minimum 1D IN NS ns1.internettradecraft.com... IN NS ns2.internettradecraft.com 12H IN MX 10 internettradecraft.com 12H IN A 10.10.10.9 localhost 12H IN A 127.0.0.1 mail 12H IN CNAME internettradecraft.com www 12H IN CNAME @ userservices 12H IN CNAME userservices.internettradecraft.com www.userservices 12H IN CNAME userservices.internettradecraft.com stats 12H IN CNAME stats.internettradecraft.com www.stats 12H IN CNAME stats.internettradecraft.com... ryan@SECURITYFOCUS.COM Security-Focus.com 1660 S Amphlett Blvd Suite 1 28 San Mateo, CA 94402 650-655-2000 x29 (FAX) 650-655-2099 Technical Contact, Zone Contact: DNS, Administrator (DA573-ORG) dom@internettradecraft.COM internettradecraft Communications (Canada) Inc #1175 - 555 West Hastings Street Vancouver BC CA (604) 688 -89 46 Fax- - - - - - - (604) 688 -89 34 Record last updated on 20-Jan-2000 Record expires on... and Registrars % whois -h whois.networksolutions.com internettradecraft.com The Data in Network Solutions’ WHOIS database is provided by Network www.syngress.com 347 95 _hack_ prod_12 3 48 7/13/00 9:45 AM Page 3 48 Chapter 12 • Server Holes Solutions for information purposes, and to assist persons in obtaining information about or related to a domain name registration record Network Solutions does not guarantee... different competing registrars Go to http://www.internic.net for detailed information Domain Name: INTERNETTRADECRAFT.COM Registrar: NETWORK SOLUTIONS, INC Whois Server: whois.networksolutions.com Referral URL: www.networksolutions.com Name Server: NS2.internettradecraft.COM Name Server: NS1.internettradecraft.COM Updated Date: 20-jan-2000 >>> Last update of whois database: Tue, 6 Jun 00 06:31:56 EDT... 06: 58: 22 EDT Domain servers in listed order: NS1.INTERNETTRADECRAFT.COM NS2.INTERNETTRADECRAFT.COM 10.10.10.3 10.10.10.4 Using the whois utility, we’re able to find the authoritative name servers for a given domain Using this information, we may be able to find out more information about the domain we’re looking at % nslookup Default Server: ns1.internal Address: 10.200.204.7 > server ns1.internettradecraft.COM... remote host or network has already been discussed Defining a goal is key in deciding how to proceed If you’re a would-be attacker, think about just what you’re after If you’re someone looking to assess the security of your machines, consider just what things you care to protect, and define those things as your goal Can’t figure out why anyone would want to compromise your network? Just make your goal that... enable high volume, automated, electronic processes that apply to Network Solutions (or its systems) Network Solutions reserves the right to modify these terms at any time By submitting this query, you agree to abide by this policy Registrant: Ryan Russell (INTERNETTRADECRAFT-DOM) 1000 Crescent Way El Cerrito, CA 94530 US Domain Name: INTERNETTRADECRAFT.COM Administrative Contact, Billing Contact: russell,... on the Public Key Infrastructure (PKI) signing chain If you were able to slip your special copy of Netscape in when someone was auto-updating, you could include your own signing key for “Verisign,” and pretend to be just about any HTTPS Web server in the world www.syngress.com 337 95 _hack_ prod_11 7/13/00 11:57 AM Page 3 38 95 _hack_ prod_12 7/13/00 9:45 AM Page 339 Chapter 12 Server Holes Solution in this... argument for being proactive with security on your own systems Merely keeping up with patches may not be enough to defend against the latest attacks For IT Professionals Tips for Admins Reduce goals! Again! If there’s no obvious goal, maybe an attacker won’t bother with your network at all Don’t think you’re uninteresting Just because you think your machines or network are boring, and that no one would . information is actually enough of a network fingerprint” to prevent, among (many) other things, untrusted users outside your network from transmitting packets to your network that appear to be from. entrance (ingress) and exit (egress) points of your network allows you, as a security administrator, to determine what ser- vices, if any, users outside your network are allowed to transmit packets. which all proofs of identity should fit. 3 18 Chapter 11 • Spoofing: Attacks on Trusted Identity www.syngress.com 95 _hack_ prod_11 7/13/00 11:57 AM Page 3 18 Table 11.1 Classifications in an Authentication