Download PDF Zero trust networks: building secure systems in untrusted networks, 2nd edition razi ra

Page 1


Visit to download the full and correct content document: https://textbookfull.com/product/zero-trust-networks-building-secure-systems-in-untru sted-networks-2nd-edition-razi-rais/

More products digital (pdf, epub, mobi) instant download maybe you interests ...

Zero Trust Networks 2 / converted Edition Razi Rais

https://textbookfull.com/product/zero-trust-networks-2-convertededition-razi-rais/

Building Modern Networks Create and manage cutting edge networks and services 1st Edition Steven Noble

https://textbookfull.com/product/building-modern-networks-createand-manage-cutting-edge-networks-and-services-1st-edition-stevennoble/

Reliable, Secure and Resilient Logistics Networks: Delivering Products in a Risky Environment Lech Bukowski

https://textbookfull.com/product/reliable-secure-and-resilientlogistics-networks-delivering-products-in-a-risky-environmentlech-bukowski/

Opportunistic Networks: Concepts and Systems 2024th Edition Förster

https://textbookfull.com/product/opportunistic-networks-conceptsand-systems-2024th-edition-forster/

Complex Networks in Software, Knowledge, and Social Systems Miloš Savi■

https://textbookfull.com/product/complex-networks-in-softwareknowledge-and-social-systems-milos-savic/

Biota Grow 2C gather 2C cook Loucas

https://textbookfull.com/product/biota-grow-2c-gather-2c-cookloucas/

Cyber Operations Building, Defending, and Attacking Modern Computer Networks O'Leary

https://textbookfull.com/product/cyber-operations-buildingdefending-and-attacking-modern-computer-networks-oleary/

Cyber Resilience of Systems and Networks Alexander Kott

https://textbookfull.com/product/cyber-resilience-of-systems-andnetworks-alexander-kott/

Photonic Applications For Radio Systems Networks Fabio Cavaliere

https://textbookfull.com/product/photonic-applications-for-radiosystems-networks-fabio-cavaliere/

Praise for ZeroTrustNetworks, 2nd edition

Zerotrustisnotjustastrategy;itisamindsetthatchallenges assumptions,scrutinizeseveryinteraction,andguardsourdigital systemsagainstunseenfoes.Thisbookofferspracticalguidance forchieftechnologyofficers,engineers,andinformation technologyprofessionalsembarkingontheirzerotrustjourney.

Ann Johnson, Corporate Vice President, Microsoft Security

Thisbookpackagesessentialconceptsofzerotrustsecurityinan easytounderstandlanguage.Adefinitivereadforbeginnersand professionalsalike.

—Karan Dwivedi, Security Engineering Manager at Google

Thisbookdoesanexcellentjobofsynthesizingthezero-trust securitymodel.Itexplainsthekeypillarsofzerotrustsecurity whilealsocoveringthezerotrustframeworksdevelopedbyNIST , DoD,CISA,andotherorganizations,makingitavaluableresource foranyoneseekingtounderstandhowtoimplementthezero-trust securitymodel.

Cameron, Automotive Industry Technical Fellow in Identity

Wemaynotrealizethis,butourlivesdependoncomputers.When youareinanairplane,orinahospital,orinatrain,oreven turningalightbulbonathome,it’sallcomputers.Abreachcan causepandemonium,andsecuringthisinfrastructureis paramount.Assuch,zerotrustnetworksprovideyouwiththe fundamentalsandmindsetyouneedtounderstandtosecureyour investments.Thisbookisagreatresourcefordevelopers, infrastructureengineers,andmanagersalike,asitthoroughly explainsthewhysandhowsofzerotrust.

—Sahil Malik, Security Engineer, IT Industry

Withtherapidadoptionofcloudnetworks,bring-your-own-device, andwork-from-homepolicies,implementingzerotrustsecurityin today’senterprisenetworksisanabsolutemust.It’salotmore complicatedthanitsounds.ButRaziRaisandChristinaMorillo makeallofthetechnicalitiesunderstandableforreaderswith generalITbackgrounds.Theirbookisamustreadforallpeople whoadministratecomputernetworksforbusiness.

Zero Trust Networks

Building Secure Systems in Untrusted Networks

Razi Rais, Christina Morillo, Evan Gilman, and Doug Barth

Zero Trust Networks

Copyright © 2024 Christina Morillo and Razi Rais. All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (https://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com.

Acquisitions Editor: Simina Calin

Development Editor: Michele Cronin

Production Editor: Ashley Stussy

Copyeditor: Liz Wheeler

Proofreader: Sonia Saruba

Indexer: WordCo Indexing Services, Inc.

Interior Designer: David Futato

Cover Designer: Karen Montgomery

Illustrator: Kate Dullea

June 2017: First Edition

March 2024: Second Edition

Revision History for the First Edition

2024-02-23: First Release

See https://oreilly.com/catalog/errata.csp?isbn=9781492096597for release details.

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. ZeroTrustNetworks, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.

The views expressed in this work are those of the authors and do not represent the publisher’s views. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. 978-1-492-09659-7

[LSI]

Preface

Thank you for choosing to read ZeroTrustNetworks,2E! Building trusted systems in hostile networks has been a passion of ours for many years. In building and designing such systems, we have found frustration in the pace of progress toward solving some of the more fundamental security problems plaguing our industry. We’d very much like to see the industry move more aggressively toward building systems that strive to solve these problems.

To that end, we propose that the world take a new stance toward building and maintaining secure computer networks. Rather than being something that is layered on top, only considered after some value has been built, security must be fundamentally infused with the operation of the system itself. It must be ever-present, enabling operation rather than restricting it. As such, this book sets forth a collection of design patterns and considerations which, when heeded, can produce systems that are resilient to the vast majority of modern-day attack vectors.

This collection, when taken as a whole, is known as the zero trust model. In this model, nothing is taken for granted, and every single access request whether it’s made by a client in a coffee shop or a server in the datacenter—is rigorously checked and proven to be authorized. Adopting this model practically eliminates lateral movement, VPN headaches, and centralized firewall management overhead. It is a very different model; one that we believe represents the future of network and infrastructure security design. In the second edition, we broaden the scope to include recent developments in zero trust. We have added two entirely new chapters and additional real-world scenario walkthroughs to the current chapters. The chapter on zero trust architectural standards, frameworks, and guidelines will help you better grasp the zero trust

perspective from leading organizations, such as NIST, CISA, DoD, and others. Since zero trust initiatives are not easy, we added a chapter dedicated to discussing challenges and practical advice to deal with them. This chapter finishes with an examination of more recent technical advancements, including artificial intelligence, quantum computing, and privacy-preserving technologies, all of which are highly relevant to zero trust and cybersecurity in general.

Who Should Read This Book

Have you found the overhead of centralized firewalls to be restrictive? Perhaps you’ve even found their operation to be ineffective. Have you struggled with VPN headaches, TLS configuration across a myriad of applications and languages, or compliance and auditing hardships? These problems represent a small subset of those addressed by the zero trust model. If you find yourself thinking that there just has to be a better way, then you’re in luck—this book is for you.

Network engineers, security engineers, CTOs, and everyone in between can benefit from zero trust learnings. Even without a specialized skill set, many of the principles included in this book can be clearly understood, helping leaders make decisions that implement a zero trust model, improving their overall security posture incrementally.

Additionally, readers with experience using configuration management systems will see the opportunity to use those same ideas to build a more secure and operable networked system—one in which resources are secure by default. They will be interested in how automation systems can enable a new network design that is able to apply fine-grained security controls more easily. Finally, this book explores a mature zero trust design, enabling those who have already incorporated the basic philosophies to further the robustness of their security systems.

Why We Wrote This Book

We started speaking about our approach to system and network design at industry conferences in 2014. At the time, we were using configuration management systems to rigorously define the system state, applying changes programmatically as a reaction to topological changes. As a result of leveraging automation tools for this purpose, we naturally found ourselves programmatically calculating the network enforcement details instead of managing the configuration by hand. We found that using automation to capture the system design in this way allowed us to deploy and manage security features, including access control and encryption, much more easily than in systems past. Even better, doing so allowed us to place much less trust in the network than other systems might normally do, which is a key security consideration when operating in and across public clouds.

While writing this book, we spoke to individuals from dozens of companies to understand their perspective on network security designs. We found that many of those companies were reducing the trust of their internal networks. While each organization took a slightly different approach in their own system, it was clear that they were all working under the same threat model and were, as a result, building solutions that shared many properties.

Our goal with this book isn’t to present one or two particular solutions to building these types of systems, but rather to define a system model that places no trust in its communication network. Therefore, this book won’t be focused on using specific vendor software or implementations, but rather it will explore the concepts and philosophies that are used to build a zero trust network. We hope you will find it useful to have a clear mental model for how to construct this type of system when building your own system or, even better, reusable solutions for the problems described herein.

Navigating This Book

This book is organized as follows:

Chapters 1 and 2 discuss the fundamental concepts at play in a zero trust security model.

Chapters 3 and 4 explore the new concepts typically seen in mature zero trust networks: context-aware network agents and trust engines.

Chapters 5 through 8 detail how trust is established among the various actors in a network, with focus on devices, identities, applications, and network traffic. Most of this content is focused on existing technology that could be useful in a traditional network security model. The scenario walkthroughs at the end of each chapter will help you understand how the core principles of zero trust are used in a real-world setting.

Chapter 9 brings all this content together to discuss how you could begin building your own zero trust network and includes two case studies.

Chapter 10 looks at the zero trust security model from an adversarial view. It explores potential weaknesses, discussing which are well mitigated and which are not.

Chapter 11 explores zero trust architectures, standards, and frameworks from NIST, CISA, DoD, and others. The goal is to help you understand the zero trust security model from the perspective of leading organizations in the industry.

Chapter 12 outlines various functional and technical obstacles that organizations experience when implementing zero initiatives. It also provides high-level considerations that may assist you in effectively dealing with these challenges. Additionally, it examines the impact of artificial intelligence (AI), quantum computing, and privacy-enhancing technologies on

zero trust security models, which are extremely important advancements to understand. The potential impact of AI, quantum computation, and privacy-enhancing technologies on zero trust security model is also examined. Comprehending these advancements is of the utmost importance, given their pivotal role in cybersecurity strategy.

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

NOTE

This element signifies a general note.

WARNING

This element indicates a warning or caution.

O’Reilly Online Learning

NOTE

For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.

Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.

1005 Gravenstein Highway North Sebastopol, CA 95472

800-889-8969 (in the United States or Canada)

707-827-7019 (international or local)

707-829-0104 (fax)

support@oreilly.com

https://www.oreilly.com/about/contact.html

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/zero-trust-networks-2e.

For news and information about our books and courses, visit https://oreilly.com.

Find us on LinkedIn: https://linkedin.com/company/oreilly-media

Follow us on Twitter: https://twitter.com/oreillymedia

Watch us on YouTube: https://youtube.com/oreillymedia

Acknowledgments from the First Edition

We would like to thank our editor, Courtney Allen, for her help and guidance during the writing process. Thanks also to Virginia Wilson, Nan Barber, and Maureen Spencer for their help during the review.

We had the opportunity to meet with many people during the writing of this content, and we appreciate their willingness to speak with us and provide intros to other folks working in this space. Thanks to Rory Ward, Junaid Islam, Stephen Woodrow, John Kindervag, Arup Chakrabarti, Julia Evans, Ed Bellis, Andrew Dunham, Bryan Berg, Richo Healey, Cedric Staub, Jesse Endahl, Andrew Miklas, Peter Smith, Dimitri Stiliadis, Jason Chan, and David Cheney.

A special thanks to Betsy Beyer for writing the Google BeyondCorp case study included in the book. We really appreciate your willingness to work on getting that content included. Thanks!

Thanks to our technical reviewers, Ryan Huber, Kevin Babcock, and Pat Cable. We found your comments invaluable and appreciate the time you took to read through the initial drafts.

Doug would like to thank his wife, Erin, and daughters, Persephone and Daphne, for being so very understanding of the time it took to

write this book.

Evan thanks his partner, Kristen, for all of her support through the writing of this book. He would also like to thank Kareem Ali and Kenrick Thomas—without them, none of this would have been possible.

Acknowledgments from the Second Edition

We are especially grateful to Michele Cronin, our development editor, for her assistance and direction throughout the process. Thanks also to Simina Calin, our acquisitions editor, for helping us in establishing a successful path for this book.

Our heartfelt thanks goes out to our technical reviewers, including Kim Crawley, Steve Winterfeld, and Karan Dwivedi, whose extensive feedback and recommendations have enhanced every facet of this book. Many thanks!

Razi would like to thank his wonderful wife, Javeria, as well as his mother and sister, Zahida and Khaizran, for their unwavering support throughout the writing of this book.

Christina would like to thank her husband and children for their steadfast support and patience during the book-writing journey.

Chapter 1. Zero Trust Fundamentals

In an age when network surveillance is ubiquitous, we find it difficult to trust anyone, and defining what trust is itself is equally difficult. Can we trust that our internet traffic will be safe from eavesdropping? Certainly not! What about that provider you leased your fiber from? Or that contracted technician who was in your datacenter yesterday working on the cabling?

Whistleblowers like Edward Snowden and Mark Klein have revealed the tenacity of government-backed spy rings. The world was shocked at the revelation that they had managed to get inside the datacenters of large organizations. But why? Isn’t it exactly what you would do in their position? Especially if you knew that traffic there would not be encrypted?

The assumption that systems and traffic within a datacenter can be trusted is flawed. Modern networks and usage patterns no longer echo those that made perimeter defense make sense many years ago. As a result, moving freely within a “secure” infrastructure frequently has a low barrier to entry once a single host or link there has been compromised.

You may think that the idea of using a cyberattack as a weapon to disrupt critical infrastructure like a nuclear plant or a power grid is far-fetched, but cyberattacks on the Colonial Pipeline in the United States and the Kudankulam Nuclear Power Plant in India serve as a stark reminder that critical infrastructure will continue to be a highvalue target for attackers. So, what was common between the two attacks?

Well, in both cases, security was abysmal. Attackers took advantage of the fact that the VPN (virtual private network) connection to the Colonial Pipeline network was possible using a plain-text password without any multifactor authentication (MFA) in place. In the other example, malware was discovered on an Indian nuclear power plant employee’s computer that was connected to the administrative network’s internet servers. Once the attackers gained access, they were able to roam within the network due to the “trust” that comes with being inside the network.

Zero trust aims to solve the inherent problems in placing our trust in the network. Instead, it is possible to secure network communication and access so effectively that the physical security of the transport layer can be reasonably disregarded. It goes without saying that this is a lofty goal. The good news is that we’ve got pretty powerful cryptographic algorithms these days, and given the right automation systems, this vision is actually attainable.

What Is a Zero Trust Network?

A zero trust network is built upon five fundamental assertions:

The network is always assumed to be hostile.

External and internal threats exist on the network at all times.

Network locality alone is not sufficient for deciding trust in a network.

Every device, user, and network flow is authenticated and authorized.

Policies must be dynamic and calculated from as many sources of data as possible.

Traditional network security architecture breaks different networks (or pieces of a single network) into zones, contained by one or more

firewalls. Each zone is granted some level of trust, which determines the network resources it is permitted to reach. This model provides very strong defense-in-depth. For example, resources deemed more risky, such as web servers that face the public internet, are placed in an exclusion zone (often termed a “DMZ”), where traffic can be tightly monitored and controlled. Such an approach gives rise to an architecture that is similar to some you might have seen before, such as the one shown in Figure 1-1.

The zero trust model turns this diagram inside out. Placing stopgaps in the network is a solid step forward from the designs of yesteryear, but it is significantly lacking in the modern cyberattack landscape. There are many disadvantages:

Lack of intra-zone traffic inspection

Lack of flexibility in host placement (both physical and logical)

Single points of failure

It should be noted that, should network locality requirements be removed, the need for VPNs is also removed. A virtual private

Figure 1-1. Traditionalnetworksecurity architecture

network (VPN) allows a user to authenticate in order to receive an IP address on a remote network. The traffic is then tunneled from the device to the remote network, where it is decapsulated and routed. It’s the greatest backdoor that no one ever suspected. If we instead declare that network location has no value, VPN is suddenly rendered obsolete, along with several other modern network constructs. Of course, this mandate necessitates pushing enforcement as far toward the network edge as possible, but at the same time it relieves the core from such responsibility. Additionally, stateful firewalls exist in all major operating systems, and advances in switching and routing have opened an opportunity to install advanced capabilities at the edge. All of these gains come together to form one conclusion: the time is right for a paradigm shift. By leveraging distributed policy enforcement and applying zero trust principles, we can produce a design similar to the one shown in Figure 1-2.

Figure 1-2. Zero trustarchitecture

Introducing the Zero Trust Control Plane

The supporting system is known as the control plane, while most everything else is referred to as the data plane, which the control plane coordinates and configures. Requests for access to protected resources are first made through the control plane, where both the device and user must be authenticated and authorized. Fine-grained policy can be applied at this layer, perhaps based on role in the organization, time of day, geo-location, or type of device. Access to more secure resources can additionally mandate stronger authentication.

Once the control plane has decided that the request will be allowed, it dynamically configures the data plane to accept traffic from that client (and that client only). In addition, it can coordinate the details

of an encrypted tunnel between the requestor and the resource. This can include temporary one-time-use credentials, keys, and ephemeral port numbers.

It should be noted that the control plane decision to allow a request is time-bound rather than permanent. This means that if and when the factors that led the control plane decision to allow the request in the first place have changed, it may coordinate with the data plane to revoke the requested access to the resource.

While some compromises can be made on the strength of these measures, the basic idea is that an authoritative source, or trusted third party, is granted the ability to authenticate, authorize, and coordinate access in real time, based on a variety of inputs. We’ll discuss the control and data planes more in Chapter 2.

Evolution of the Perimeter Model

The traditional architecture described in this book is often referred to as the perimeter model, after the castle-wall approach used in physical security. This approach protects sensitive items by building lines of defenses that an intruder must penetrate before gaining access. Unfortunately, this approach is fundamentally flawed in the context of computer networks and no longer suffices. To fully understand the failure, it is useful to recall how the current model was arrived at.

Managing the Global IP Address Space

The journey that led to the perimeter model began with address assignment. Networks were being connected at an ever-increasing rate during the days of the early internet. If a network wasn’t being connected to the internet (remember, the internet wasn’t ubiquitous at the time), it was being connected to another business unit, another company, or perhaps a research network. Of course, IP

addresses must be unique in any given IP network, and if the network operators were unlucky enough to have overlapping ranges, they would have a lot of work to do in changing them all. If the network you are connecting to happens to be the internet, then your addresses must be globally unique. So clearly some coordination is required here.

The Internet Assigned Numbers Authority (IANA), formally established in 1998, is the body that today provides that coordination. Prior to the establishment of the IANA, this responsibility was handled by Jon Postel, who created the internet map shown in Figure 1-3. He was the authoritative source for IP address ownership records, and if you wanted to guarantee that your IP addresses were globally unique, you would register with him. At this time, everybody was encouraged to register for IP address space, even if the network being registered was not going to be connected to the internet. The assumption was that even if a network was not connected now, it would probably be connected to another network at some point.

1-3. Amap ofthe early internetcreatedby Jon Postel, datedFebruary 1982

Figure

Birth of Private IP Address Space

As IP adoption grew through the late 1980s and early 1990s, frivolous use of address space became a serious concern. Numerous cases of truly isolated networks with large IP address space requirements began to emerge. Networks connecting ATMs and arrival/departure displays at large airports were touted as prime examples. These networks were considered truly isolated for various reasons. Some devices might be isolated to meet security or privacy requirements (e.g., networks meant for ATMs). Some might be isolated because the scope of their function was so limited that having broader network access was seen as exceedingly unlikely (e.g., airport arrival and departure displays). RFC 1597, Address Allocation for Private Internets, was introduced to address this wasted public address space issue.

In March of 1994, RFC 1597 announced that three IP network ranges had been reserved with IANA for general use in private networks: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. This had the effect of slowing address depletion by ensuring that the address space of large private networks never grew beyond those allocations. It also enabled network operators to use nonglobally unique addresses where and when they saw fit. It had another interesting effect, which lingers with us today: networks using private addresses were more secure, because they were fundamentally incapable of joining other networks, particularly the internet.

At the time, very few organizations (relatively speaking) had an internet connection or presence, and as such, internal networks were frequently numbered with the reserved ranges. Additionally, security measures were weak to nonexistent because these networks were typically confined by the walls of a single organization.

Private Networks Connect to Public Networks

The number of interesting things on the internet grew fairly quickly, and soon most organizations wanted at least some sort of presence. Email was one of the earliest examples of this. People wanted to be able to send and receive email, but that meant they needed a publicly accessible mail server, which of course meant that they needed to connect to the internet somehow. With established private networks, it was often the case that this mail server would be the only server with an internet connection. It would have one network interface facing the internet, and one facing the internal network. With that, systems and people on the internal private network got the ability to send and receive internet email via their connected mail server.

It was quickly realized that these servers had opened up a physical internet path into their otherwise secure and private network. If one was compromised, an attacker might be able to work their way into the private network, since hosts there can communicate with it. This realization prompted strict scrutiny of these hosts and their network connections. Network operators placed firewalls on both sides of them to restrict communication and thwart potential attackers attempting to access internal systems from the internet, as shown in Figure 1-4. With this step, the perimeter model was born. The internal network became the “secure” network, and the tightly controlled pocket that the external hosts lay in became the DMZ, or the demilitarized zone.

Figure 1-4. Bothinternetandprivate resources can access hosts in the DMZ; private resources, however, cannot reachbeyondthe DMZ, andthus do notgain direct internetaccess

Birth of NAT

The number of internet resources being accessed from internal networks was growing rapidly, and it quickly became easier to grant general internet access to internal resources than it was to maintain intermediary hosts for every application desired. NAT, or network address translation, solved that problem nicely.

RFC 1631, The IP Network Address Translator, defines a standard for a network device that is capable of performing IP address translation at organizational boundaries. By maintaining a table that maps public IPs and ports to private ones, it enabled devices on private networks to access arbitrary internet resources. This lightweight mapping is application agnostic, which meant that network operators no longer needed to support internet connectivity for particular applications; they needed only to support internet connectivity in general.

These NAT devices had an interesting property: because the IP mapping was many-to-one, it was not possible for incoming connections from the internet to access internal private IPs without specifically configuring the NAT to handle this special case. In this way, the devices exhibited the same properties as a stateful firewall.

Actual firewalls began integrating NAT features almost instantaneously, and the two became a single function, largely indistinguishable. Supporting both network compatibility and tight security controls meant that eventually you could find one of these devices at practically every organizational boundary, as shown in Figure 1-5.

Figure 1-5. Typical(andsimplified)perimeter firewalldesign

The Contemporary Perimeter Model

With a firewall/NAT device between the internal network and the internet, the security zones are clearly forming. There is the internal “secure” zone, the DMZ (demilitarized zone), and the untrusted zone (aka the internet). If at some point in the future, this organization needed to interconnect with another, a device would be placed on that boundary in a similar manner. The neighboring organization would likely become a new security zone, with particular rules about what kind of traffic can go from one to the other, just like the DMZ or the secure zone.

Looking back, we see the progression. We went from offline/private networks with just one or two hosts with internet access to highly interconnected networks with security devices around the perimeter. It is not hard to understand: network operators couldn’t afford to

sacrifice the perfect security of their offline network because they had to open doors for various business purposes. Tight security controls at each door minimized the risk.

Evolution of the Threat Landscape

Even before the public internet, communicating with a remote computer system was highly desirable. This was commonly done over the public telephone system. Users and computer systems could dial in and, by encoding data into audible tones, gain connectivity to the remote machine. These dial-in interfaces were the most common attack vector of the day, since gaining physical access was much more difficult.

Once organizations had internet-connected hosts, attacks shifted from occurring over the telephone network to being launched over the dial-up internet. This triggered a change in most attack dynamics. Incoming calls to dial-in interfaces tied up a phone line, and were a notable occurrence when compared to a TCP connection coming from the internet. It was much easier to have a covert presence on an IP network than it was on a system that needed to be dialed into. Exploitation and brute force attempts could be carried out over long periods of time without raising too much suspicion...though an additional and more impactful capability arose from this shift: malicious code could then listen for internet traffic.

By the late 1990s, the world’s first (software) Trojan horses began to make their rounds. Typically, a user would be tricked into installing the malware, which would then open a port and wait for incoming connections. The attacker could then connect to the open port and remotely control the target machine.

It wasn’t long before that people realized it would be a good idea to protect those internet-facing hosts. Hardware firewalls were the best way to do it (most operating systems had no concept of a hostbased firewall at the time). They provided policy enforcement,

ensuring that only whitelisted/allowed-listed “safe” traffic was allowed in from the internet. If an administrator inadvertently installed something that exposed an open port (like a Trojan horse), the firewall would physically block connections to that port until explicitly configured to allow it. Likewise, traffic to the internet-facing servers from inside the network could be controlled, ensuring that internal users could speak to them, but not vice versa. This helped prevent movement into the internal network by a potentially compromised DMZ host.

DMZ hosts were of course a prime target (due to their connectivity), though such tight controls on both inbound and outbound traffic made it hard to reach an internal network through a DMZ. An attacker would first have to compromise the firewalled server, then abuse the application in such a way that it could be used for covert communication (they need to get data out of that network, after all). Dial-in interfaces remained the lowest-hanging fruit if one was determined to gain access to an internal network.

This is where things took an interesting turn. NAT was introduced to grant internet access to clients on internal networks. Due in some part to NAT mechanics and in some part to real security concerns, there was still tight control on inbound traffic, though internal resources wishing to consume external resources might freely do so. There’s an important distinction to be made when considering a network with NAT’d internet access against a network without it: the former has a relaxed (if any) outbound network policy.

This significantly transformed the network security model. Hosts on the “trusted” internal networks could then communicate directly with untrusted internet hosts, and the untrusted host was suddenly in a position to abuse the client attempting to speak with it. Even worse, malicious code could then send messages to internet hosts from within the internal network. Today, we know this as “phoning home.”

Phoning home is a critical component of most modern attacks. It allows data to be exfiltrated from otherwise-protected networks; but more importantly, since TCP is bidirectional, it allows data to be injected as well. A typical attack involves several steps, as shown in Figure 1-6. First, the attacker will compromise a single computer on the internal network by exploiting the user’s browser when they visit a particular page, by sending them an email with an attachment that exploits some local software, for example. The exploit carries a very small payload, just enough code to make a connection out to a remote internet host and execute the code it receives in the response. This payload is sometimes referred to as a dialer.

The dialer downloads and installs the real malware, which more often than not will attempt to make an additional connection to a remote internet host controlled by the attacker. The attacker will use this connection to send commands to the malware, exfiltrate sensitive data, or even to obtain an interactive session. This “patient zero” can act as a stepping stone, giving the attacker a host on the internal network from which to launch additional attacks.

Another random document with no related content on Scribd:

1 0ᴴ 56ᵐ 35.1ˢ +31°36′39″ f pF, R, 20″d, *14m 20″p.

2 39.3 31 38 24 e F, R, 20″d, *12m 20″n.

3 49.0 31 22 14 h₀ F, mE110°, 60″l.

4 0 57  5.7 32 4 12 e eF, st. *13m 30″np.

5 54.5 32 17 41 e vF, R, 25″d, *14m 30″sf.

6 0 58  8.9 32 8 33 e vF, R, 25″d, *9 1′nf.

7 22.3 31 33 12 e eF st. 8 41.8 31 45 33 f pF, R, S, Δ2 faint*, bM.

9 42.7 31 17 58 f pF, st. 2*13, 14 1.5′p. 10 54.7 31 16 30 g F, cE0°, 30″l. 11 58.0 31 43 5 g F, cE130°, 30″l, bM.

59.7 32 5 33 e vF, R, 30″d.

0 59 13.9 31 56 21 f vF, st. *16m40″sf. 14 28.2 31 31 43 f vF, st. *15m 1.5′f.

15 51.6 32 33 48 g vF, E140°, 45″l.

16 58.2 32 1 58 f vF, E60°, 20″l 3f*.

17 58.8 31 41 27 f eF, eS.

18 1  0  0.7 31 54 35 e F, st.

3.6 31 18 39

vF, st. d. nuc.

6.4 31 29 19 e vF, 1E, 20″l.

8.2 31 42 16 e vF, st. 22 10.9 31 43 12 h vF, E90°, 1′l. 23 15.0 32 24 1 e eF, eS 2*10, 11m1′nf. 24 18.9 31 30 22 g vF, cE, S, *15m40″s. 25 22.0 31 1 42 e vF, st.

22.1 32 22 51 e eF, R, 30″d, *12m1.5′nf. 27 22.9 31 31 29 f FcE60°1′l, *16m40″np. 28 25.0 31 45 17 f eF, E, eS. 29 29.0 31 54 48 h₀ Fv, mE160°, 40″l*13m1′s. 30 33.3 31 54 41 e eF, E, eS.

31 39.3 31 25 23 h F, mE130°, 1′l.

32 43.2 32 17 18 e vF, R, 40″d, *14m30″s.

33 59.1 31 35 14 g eF, eS, st.

34 1  1  3.5 32 38 9 e vF, cE40°*11m1′nf.

35 11.3 31 13 16 h₀ vF, 310°, 1′l.

36 19.6 31 47 9 f F, S, E60°, *14m1′s.

37 24.5 31 25 17 f F, st. *14m1′np.

38 27.8 31 52 56 f eF, vS, *15m20″p.

39 32.7 31 45 48 e eF, st. in line with 2f*.

40 50.3 31 45 57 e eF, iR, *14m1′s.

41 58.8 31 25 54 e pF, R, 25″d. no nuc.

42 1  2  5.5 31 34 21 e vF, st. *10m20″s.

43 20.4 31 29 4 e vF, R, 45″d. no nuc.

44 22.3 31 18 42 f F, st. and sev f*.

45 26.4 32 3 22 e vF, st. *11m20″s.

46 32.0 32 6 19 e eF, iR*14m30″sf.

47 39.7 31 30 21 g vF, cE80°, S.

48 48.5 31 47 5 f F, st. *15m1′nf.

49 49.0 31 41 39 f eF, vS, *15m30″f.

50 49.8 31 57 3 f eF, st. *14m1′np.

51 1  3  5.3 31 42 7 f vF, st. 2*14m1′f.

52 8.0 32 14 51 e eF, st. 53 26.4 31 43 18 f vF, st. Δ2vF*.

54 37.6 31 30 51 f eF, st. bet. 2*.

55 57.6 31 55 41 f eF, st. *12m15″p.

56 1  4 16.4 32 2 9 f vF, st. bet. 2*. 57 1  5  1.6 31 48 22 e eF, st. *12m1′s.

N P K F I N.G.C. 370 0ᴴ 59ᵐ 51.6ˢ +31°44′55″ g vF, S, cE20°* 14m30″s.

N.G.C.

374 1  0 12.5 32 7 35 g₀ pB, mE10°bet. 2*13m.

376 14.3 31 40 43 f vF.

379 22.5 31 51 8 g₀ pB, cE 0°, 60″×30″.

380 24.5 31 48 53 e pB, R, 40″d.

382 30.9 31 44 8 f pB, R, 20″d.

383 32.0 31 44 38 e pB, R, 1'd bM.

384 32.2 31 37 26 g₀ pB, cE135°, 30″l.

385 34.3 31 39 4 f pB, R, 40″d.

386 38.3 31 41 35 f pF, st. 388 54.2 31 38 28 f F, st.

392 1  1 29.1 32 27 59 f pF, R, 30″d bM, *11m1′ sp.

394 31.6 32 28 50 f F, st. 397 36.4 32 26 32 f vF, st. 398 1  2 0.0 31 50 50 f F, st. 399 5.2 31 58 1 g₀ F E50° 40″l. 403 20.0 32 5 9 k pB, mE90°, 60″×20″. 387 1  0

31 43 23 f vF, eS, st. I.C. 1618 0  59 3.4 31 44 31 g₀ pF, cE, 150° 25″l, bM. 1619 1  0 28.6 32 23 57 f pF, st. bet. 2*11, 12m.

N.G.C. 379 and 372 are probably the same object, with α of 370, and δ the mean of the two N.G.C. positions. There is no other object in the immediate vicinity

400

401 Faint stars in these positions; no nebulae near 402 390, Faint star, 16m in this position No trace of a nebula

TABLE X

32 18 51 f eF, vS.

32 0 10 e eeeF, vS.

1  44  0.7 32 27 29 e eeF, vS.

32 9 58 e eeF, eS.

N P K F II

vF, eS.

31 55 32 c vF nuc., iR eeF neb.,60″d. 1 42  20.4 31 57 55 q 270″×30″. Found visually by Barnard. Not catalogued.

TABLE XI F III N

31 37.9 29 24 6 d eeF, 20″d.

32 38.7 29 26 44 e eeF, 15″d.

33 38.8 29 44 12 e eeF, 15″d.

34 39.8 29 20 17 e eeF, 15″d.

35 40.3 29 54 55 e eeF, 15″d.

36 41.2 29 27 20 w eeF, nuc. 10″d, ring, 30″d.

37 41.4 28 55 57 e eF, 15″d.

38 42.8 29 23 45 d vF, 15″d.

39 44.9 29 23 51 e eF, 10″d.

40 47.3 29 18 17 k vF, E150°, 45″×15″.

41 48.0 29 43 23 g₀ eeF, E40°, 20″×10″.

42 48.3 29 21 21 e eF, 15″d. 43 54.0 29 21 19 g₀ eF, 30″×10″.

44 55.7 29 35 33 e F, 20″d.

45 56.6 28 55 41 e eF, 35″d.

46 58.2 29 13 50 g eeF, E50°, 30″×10″.

47 11  3  4.1 29 10 39 a eeF, 15″d, structure.

48 4.3 29 38 56 g₀ eeF, E80°, 20″×10″.

49 21.6 29 1 14 d eF, 15″d.

50 22.6 29 18 15 d eeF, 20″d.

51 23.4 29 17 21 e vF, 20″d.

52 23.6 29 39 35 e eF, 20″d.

53 24.3 29 40 11 e eeF, 20″d.

54 27.9 29 9 3 f eF, 15″d.

55 28.6 30 7 9 f eeF, 30″d.

56 28.7 29 0 47 d eeF, 15″d.

57 30.1 28 49 9 e eeF, 20″d.

58 31.4 29 43 22 e F, 15″d.

59 31.5 29 28 6 e eF, 15″d.

60 32.5 29 14 55 e eF, 15″d.

61 33.4 28 57 49 e eF, 15″d.

62 35.8 29 18 9 f vF, 20″d.

63 38.5 29 23 55 e eeF, 10″d.

64 39.6 29 23 9 a? eF, 35″×25″. E35°, a miniature Dumb-bell.

65 39.7 29 25 39 e eeeF, 10″d.

66 40.1 29 25 48 e eeeF, 10″d.

67 40.3 29 23 57 e eeF, 10″d.

68 41.3 29 21 55 g₀ eF, E110°, 30″*10″.

69 41.9 29 22 21 e eF, 20″d.

70 43.7 30 7 14 e eeF, 20″d.

71 44.7 29 22 38 e eeF, 20″d.

72 46.2 29 28 7 f eF, 20″d.

73 46.4 29 30 25 d eF, 15″d.

74 49.8 29 22 46 d eeF, 20″d.

75 51.6 29 22 53 e eeF, 10″d.

76 52.4 29 22 34 e eeF, 15″d.

77 52.9 29 43 59 e eeF, 20″d.

78 53.6 28 59 39 e F, 35″d.

79 54.5 29 26 1 d eeF, 20″d.

80 54.7 29 23 5 e eeF, 20″d.

81 55.1 29 21 50 e eF, 15″d.

82 56.7 29 26 22 e eeF, 15″d, E50°.

83 56.9 29 34 40 e eF, 15″d.

84 57.5 29 16 59 e eF, double nebula,  nuc. 4″ apart.

85 57.6 29 8 7 e eF, 30″d.

86 57.7 29 27 19 h₀ eeF, E140°, 15″×5″.

87 11  4  0.8 29 17 51 e eeF, 10″d.

88 1.0 28 56 28 e eeF, 20″d.

89 1.4 29 22 15 e eF, 15″d. 90 1.4 29 39 5 e eeF, 15″d. 91 1.8 28 57 21 e vF, 30″d. 92 3.4 29 27 26 e eF, 10″d. 93 3.7 29 29 10 e eeF, 20″d.

20″d.

3.8 29 2 9 e eeF, iR.

10″d.

5.7 29 28 23 e eeF, 15″d, faint extensions.

5.8 30 14 51 e eF, st.

6.9 29 22 50 e eF, 15″d. 100 7.6 28 56 51 h₀ eeF, E25°, 30″×10″. 101 9.4 29 14 23 e eeF, 15″d. 102 9.9 29 29 29 d eeF, 10″d. 103 10.0 28 53 55 e? eeF, faint extensions  60″×40″?

104 10.1 30 0 27 d eF, 30″d.

10.6 29 8 48 g₀ eF, E145°, spiral, 40″×20″.

12.8 29 28 58 h eeeF, 20″×10″. 107 13.4 29 23 15 e eeF, 15″d. 108 13.5 29 21 19 g₀ eeF, E125°, 25″×15″. 109 13.8 29 47 14 d eeF, 20″d.

110 14.2 30 0 57 k eF, E40°, 34″×20″. 111 14.4 29 25 24 e eF, 15″d. 112 15.6 29 29 36 d eeeF, 10″d. 113 18.6 28 55 56 e eeF, 15″d. 114 20.2 28 53 6 f eeF, 20″d.

115 22.8 28 54 6 e eeF, 20″d.

116 27.9 29 23 25 f eF, 35″d.

117 27.9 29 26 40 e? eeF, 60″×40″, spiral?

118 28.4 29 22 31 e eF, 45″d.

119 28.6 29 21 58 d eeF, 15″d.

120 28.6 29 25 18 e eeF, 10″d.

121 30.2 29 37 42 e eeF, 15″d.

122 32.0 29 25 37 d eeF, 15″d.

123 34.4 29 21 33 e eF, 20″d.

124 34.9 29 42 1 e eF, 20″d.

125 35.5 29 12 10 e eeF, 10″d.

126 36.0 29 21 0 e eF, E60°, 20″×15″.

127 37.0 29 27 7 d eeeF, 15″d.

128 38.5 28 56 22 e eF, st.

129 39.4 29 24 33 f vF, 25″d.

130 40.2 29 12 57 e eeF, 15″d.

131 41.8 29 27 40 g eeF, E95°, 20″ × 10″.

132 46.8 29 19 18 g eeF, 30″ × 15″. 133 47.9 29 31 9 d eeF, 10″d.

134 49.3 29 26 1 f eF, 15″d. 135 49.9 29 29 19 e eeF, 10″d.

49.9 29 14 45 e eeF, 15″d. 137 50.5 29 25 27 e eF, 30″d. 138 51.5 29 22 55 e eF, 10″d. 139 52.7 29 23 21 e eF, 10″d. 140 54.1 29 29 57 e eeF, 15″d.

141 11  5  3.0 28 56 43 e vF, 30″d. 142 4.7 29 16 36 e eF, 15″d. 143 6.8 29 15 53 e eeF, 20″d. 144 7.6 28 53 4 d eeF, 15″d. 145 11.6 29 38 5 e eeF, 20″d.

146 12.3 29 10 1 d eF, 20″d.

147 13.5 30 9 30 d eF, 20″d.

148 14.4 30 6 28 e

eF, 20″d.

149 14.7 29 20 38 w eF, 25″d, spiral.

150 15.6 29 8 19 d eeeF, 15″d.

151 17.1 29 29 16 e eF, 20″d.

152 19.4 29 10 52 g vF, E40°, 50″ × 20″.

153 34.3 29 25 10 d eeF, 30″d.

154 35.5 29 15 0 e eeF, 30″d.

155 43.6 28 57 24 e eF, 40″d.

156 49.2 28 42 34 f eF, st.

157 51.3 28 43 12 e eeF, 30″d.

158 59.6 28 57 38 e eeF, 30″d.

159 11  6  6.9 28 44 55 d eeF, 30″d.

160 9.7 29 29 30 d eeeF, 20″d.

161 10.6 28 40 46 e eF, 30″d.

162 11.8 29 4 8 f vF, st. 163 12.8 30 11 16 e eeF, 10″d.

164 17.5 29 25 47 e eF, 15″d.

165 23.2 28 43 55 f eeF, 20″d.

166 24.9 28 39 40 e eeF, 30″d.

167 27.8 28 41 26 e eeF, 30″d.

168 29.0 28 56 22 e eeF, 20″d.

169 40.9 29 20 27 d eeeF, 20″d.

170 37.7 28 33 23 d eeeF, 15″d.

171 42.7 29 37 59 e eeF, 20″d.

172 44.2 29 5 13 d eeeF, 15″d.

173 50.6 29 18 31 e eeF, 20″d.

174 11 7  11.1 28 32 54 d eeF, 20″d.

175 14.9 30 14 45 e eF, 20″d.

176 19.2 29 18 25 h eeeF, 30″×10″.

177 27.1 29 6 26 f eF, 20″d.

178 32.9 28 51 30 e eF, 30″d.

N P K F III

N.G.C.

3527 11ᴴ 0ᵐ 31.4ˢ +29°12′ 6″ f vF, 35″d.

3536 11 2 5.3 29 9 5 e F, 40″d.

3539 22.9 29 20 56 g₀ F, E5°, 60″×20″.

3550 11 3 53.5 29 26 47 pB, eccentric nuc., 35″ × 25″.

3552 11 3 52.2 29 24 38 e F, 20″d.

3554 11 3 57.7 29 22 15 e vF, 25″d.

3558 11 4 10.9 29 13 17 f vF, 15″d, with what appears to be a faint ring 50″ in d.

3561 11 4 28.4 29 22 31 e eF, 45″d.

TABLE XII

F IV N [10]

56 52 58 e eF, cS.

53.1 56 3 25 e eeF, eS. 16 13 36 20.1 55 50 25 e eeF, eS.

51

43.7 56 42 11 e eeF, S, *15m10″s.

46.2 56 48 12 e eF, cL.

49.7 56 41 26 f eF, S.

53.6 56 48 57 e eeF, eS.

56 27 19 h eeF, S.

19.0 56 24 54 e eF, S.

20.2 56 26 51 f eeF, vS.

35.5 57 7 6 e eF, cS.

46.0 56 5 6 f eeF, S.

54.0 56 10 12 h eeF, S.

56 9 31 h eeF, S.

9.8 56 7 11 f eeF, eS.

15.8 56 13 9 e eeF, eS.

17.1 56 13 57 f eF, vS.

29.1 56 16 49 e eF, S.

35.2 56 15 5 h eF, vS.

35.4 56 13 55 h eeF, eS.

44 37.3 56 14 41 f eF, vS.

45 47.3 56 41 19 e eeF, cS.

46 52.8 55 35 23 e eeF, eS.

47 56.4 56 12 58 f eF, vS.

48 13 39  6.9 56 15 45 e eeF, eS.

49 7.9 56 16 31 h eF, vS.

50 8.1 56 5 45 f vF, S. 51 9.2 56 11 45 e eeF, eS.

52 9.4 55 56 14 e eeF, eS.

53 13.3 56 16 32 f eeF, vS.

54 17.6 56 10 33 e eeF, eS. 55 19.8 56 10 50 e eeF, eS. 56 23.0 56 11 40 e eF, eS. 57 25.1 56 16 43 e eeF, eS. 58 30.3 56 26 49 f eF, eS.

31.6 56 20 3 e eeF, S. 60 45.1 56 29 5 f eF, vS. 61 45.7 56 34 46 e eeF, S. 62 54.2 56 15 18 e eeF, eS.

63 13 40  3.2 56 37 22 e eeF, eS.

64 5.9 56 30 56 e eeF, eS.

65 5.9 56 30 29 h eeF, 30″l. 66 27.2 56 6 27 e eeF, vS. 67 13 41 27.2 56 20 38 e eF, 60″d.

68 38.8 55 47 15 e eF, eS.

69 47.4 55 44 54 f eF, vS.

70 13 42 40.2 56 15 54 e eeF, S.

N P K F IV

N.G.C.

5279 37 3.72 56 18 14.5 5294 40 39.7   55 55 2 f eF, S, *15m1′np.

N G C 5278 and 5279 form a double nebula, somewhat similar to Messier 51 5278 is the nucleus and 5279 is at the tail of the arm. The spiral apparently has but one branch.

TABLE XIII

F V N

1 14ᴴ 53ᵐ 52.5ˢ +23°10′16″ e eF, S, R.

2 54.5 23 57 39 e vF, R, 20″d, *18m40″nf.

3 14 54 56.2 23 53 37 g eF, S, m3. *16m1′.np.

4 58.1 23 16 56 e vF, pS, iR.

5 14 55  6.7 23 24 32 f eF, S.

6 16.2 24 5 30 f F, S, *17m30″n.

7 31.4 24 6 9 w F, 30″d. Spiral.

8 35.9 23 58 27 g vF, mE, 40″l, bet. 2*. 9 37.3 24 12 53 e eF, eS.

10 14 56  13.7 23 52 21 g F, E, spiral? 11 17.7 24 2 30 g F, E180°. 12 26.3 24 0 51 h₀ vF, S, iR. 13 27.0 24 9 28 g F, vS, E. 14 28.6 23 23 8 e vF, S, R, 15″d, no nuc. 15 30.0 23 54 53 e vF, vS, R. 16 32.6 24 2 47 f eF, vS. 17 46.4 24 3 54 e eF, S, iR. 18 47.8 24 36 4 e vF, S, iR. 19 51.2 23 40 4 e vF, vS.

20 56.0 23 51 10 e eF, vS, R.

21 58.7 23 49 12 f eF, vS, R.

22 58.7 23 50 14 e eF, eS, R.

23 59.0 23 51 41 g eF, S, IE.

24 14 57  4.3 23 51 51 e eF, S.

25 4.3 23 52 8 f eF, E.

26 6.1 24 5 56 f F, bet. 2*14, 15m.

27 8.4 23 47 22 g eF, cS, iR.

28 8.9 24 16 59 e eF, S. 29 10.3 23 50 31 e eF, S.

30 11.3 23 46 44 e eF, S. 31 11.8 23 49 57 e eF, S.

32 13.6 23 53 2 h eF, S.

33 18.8 23 44 22 g eF, S.

34 24.1 23 42 42 e eF, cS, iR.

35 24.3 24 4 40 e eF, S, iR.

36 26.8 23 45 2 e eF, vS ,iR.

37 35.9 24 6 37 e eF, S.

38 41.7 24 35 7 f eF, S.

39 43.0 23 24 38 e vF, R, 30″d, no nuc.

40 51.7 24 0 48 g eF, vS, Δ with 2*14 and 16m.

41 14 58  0.6 23 18 4 c vF, 25″d, spiral?

42 6.8 23 11 21 g F, cL, mE180°, 80″×15″.

43 18.5 23 26 30 g eF, S, 20″d.

44 19.8 23 21 55 f vF, R? 60″d.

45 25.9 23 25 35 e eF, S, R, 20″d.

46 48.4 23 40 57 g eF, cS, mE.

47 54.7 23 54 12 e F, mE 180°.

48 14 59  56.8 24 10 32 e vF, S, iR, bM.

49 15  0  7.2 23 52 11 e eF, S, iR.

P K F V

N.G.C.

5829 14ᴴ 57ᵐ 9.6ˢ +23°49′29″ w open 2br, spiral.

I.C.

4526 14 57  5.9 23 50 31 e pB, R, 18″d. 4532  59 21.7 23 44 43 e pB, S, E.

I C 4526 is connected with N G C 5829 The two form a double nebula fashioned as a miniature of Messier 51

TABLE XIV

F VI N

1 17ᴴ 8ᵐ 16.7ˢ +44° 5′35″ f vF, vS, *13m, 1′f.

2 29.9 43 26 6 f vF, vS, st.

3 35.2 43 23 8 g eF, E 60°, *13m40″sp.

4 52.6 42 57 44 f F, S, st.

5 17  9  2.6 44 18 28 e vF, vS, *16m, 40″s.

6 14.2 44 16 11 e eF, S, *16m, 40″f.

7 17.5 43 50 51 f vF, sharp nuc. 30″d. 8 33.2 43 2 38 e F, pS, *17m, 1′n. 9 35.1 44 2 54 e F, vS, *15m, 30″f.

10 41.1 43 38 39 g₀ pF, S, mE, 60°*14m, 30″p. 11 53.8 43 52 2 e vF, vS, *17m, 40″n.

12 17 10  3.4 44 12 35 f eF, eS, *16m, 30″n. 13 23.3 43 49 32 e vF, vS, bet. 2 vf*. 14 25.5 43 43 7 f vF, vS. 15 29.1 43 44 48 e vF, vS. 16 33.0 44 4 43 g vF, S. 17 37.7 44 5 32 e eF, vS. 18 39.0 43 42 38 g vF, eS, *16m, 40″sf.

19 40.2 44 5 20 h eF, vS.

20 46.7 43 51 14 f vF, vS, *16m, 40″sf.

21 52.8 43 33 9 f vF, S, *16m, 40″sf.

22 55.7 44 4 8 g F, cE 70°, *14m, 40″n.

23 17 11  16.3 43 10 57 f vF, S.

24 25.9 43 25 48 f pF, S, *16m, 40″f.

25 33.9 43 47 21 g vF, vs, cE 160°, *15m, 40″np.

26 36.7 43 42 51 h₀ vF, S, cE 120°, faint nuc.

27 43.0 43 53 35 g₀ pF, S, cE 20°, *14m, 1.5′np.

28 45.7 43 55 42 f F, vS, *15m, 40″nf.

29 48.6 43 58 50 e vF, S *13m, 1.5′n.

30 57.1 44 8 50 e eF, es.

31 57.8 44 8 6 e eF, S.

32 57.9 43 44 57 e vF, vS, *15m, 30″f.

33 17 12  13.3 44 2 16 e F, eS, *12m, 1′n.

34 26.2 44 12 21 e F, eS.

35 37.2 44 12 12 e F, eS, Δ with 2*12m.

36 38.4 43 28 52 f pF, vS, *1.5′s.

37 40.9 43 54 40 h₀ eF, cE 150°, no nuc.

38 44.9 43 45 22 e vF, vS, Δ with 2*16m.

39 50.6 43 39 48 f vF, eS, Δ with 2 f*.

40 51.0 43 48 16 e vF, vS, *16m, 40″nf.

41 17  13  4.9 43 36 37 e eF, vS, *15m, 20″s.

42 27.2 43 40 39 e vF, vS.

43 39.2 43 44 19 e vF, S.

N P K F VI

N.G.C. 6323 17ᴴ 9ᵐ 30.6ˢ +43°55′42″ i pF, mE, ns, 40″l.

6329 17 10  27.3 43 49 40 f pF, pL, slE.

6332 17 11  15.2 43 48 5 g₀ pF, pL, E 45°.

6336 17 12  30.0 43 55 35 v pF, open spiral, 45″d.

I.C.

4645 17 10  53.0 +43°14′40″ e vF, pS, Δ with 2 faint*.

N.G.C. 6327 is on the plate but was not measured.

TABLE XV

F VII N

1 23ᴴ 10ᵐ 25.7ˢ +8°13′28″ f st. 14m.

2 23  11  19.4 7 34 13 e F, S, *17m30″s.

3 39.3 7 45 26 d vF, R, no nuc., 16m45″ np.

4 47.3 7 3 55 f eF, S, R, no nuc.

5 23  12  23.1 7 18 20 c vF, st. nuc. with ring 45″d.

6 42.2 6 45 7 d eF, S, R, no nuc.

7 51.1 7 2 10 q F, 1bM, mE100°, 100, ×20″.

8 23  13  17.2 7 24 12 h₀ vF, S, 1E50°*14m30″p.

9 19.4 7 34 51 q F, sharp nuc., mE70°, 80″×20″.

10 29.9 7 31 15 f F, S, E150°.

11 33.6 8 6 51 d eF, pS, R.

12 35.4 7 52 39 g pF, bM, mE150° 40″l.

13 41.6 7 32 2 g eF, vS.

14 41.6 7 18 13 e vF, vS, Δ2 faint *.

15 49.1 7 2 16 e vF, S, Δ2 faint *.

16 52.7 7 14 52 h F, sharp nuc. vmE20°90″×15″.

17 56.6 7 19 16 e eF, pL, no nuc.

18 23  14  2.4 6 51 8 f F, S, R, *14m90″n.

19 2.9 7 38 55 f F, S, R, bM.

20 18.4 7 42 40 f F, S, bM.

21 24.4 7 45 35 e eF, vS, *16m30″s.

Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.