5675d13 ( ) In Syslog We Trust?
|
|
- Sybil Blake
- 8 years ago
- Views:
Transcription
1 5675d13 ( )
2 1 Introduction Syslog is ubiquitous, but its popularity belies significant drawbacks. This paper discusses what syslog is and explains why the classic RFC 3164 variant is not appropriate for a logging infrastructure where any trust is required in the integrity of your log data. It also considers the newer RFC version, which is a substantial improvement but has significant problems that remain prohibitive where log data integrity and forensic soundness of log data are required. Syslog means several things: 1. A format for log messages. This is syslog format. 2. A protocol for transmitting syslog format messages between computers. This is the syslog protocol. 3. (Informally) a program that handles syslog format messages and sends/receives such messages via the syslog protocol. Popular syslog implementations include the classic Linux/Unix syslog daemons, syslog-ng, rsyslog and (on Windows) SolarWinds Kiwi syslog server. From a data integrity perspective we are concerned with three requirements: 1. No undetectable addition (or duplication) of events. 2. No undetectable modification of events. 3. No undetectable deletion (or loss, malicious or otherwise) of events. 2 Syslog Standards Syslog was first standardised as IETF RFC 3164 in 2001 [1]. This was a retrospective attempt to codify the various extant syslog implementations. More recently, the RFC standards [2, 3, 4] are an attempt to correct the most glaring problems with RFC Since RFC 5424 syslog is not backwardscompatible with RFC 3164 there is little sense in talking about syslog : one should specify the variant (3164 or 5424) being considered. This paper considers both variants. RFC 3164 is widely deployed: it is the de facto standard mechanism for network devices to output log messages. RFC 5424 has seen little traction to date, although as Linux distributions increasingly migrate to syslog-ng and rsyslog as their standard syslog implementations, its uptake is likely to increase. A third standard, RFC 3195 [5], encapsulates Syslog messages within XML documents and sends them over TCP. This paper does not consider RFC 3195 further as it appears to be moribund (which is unfortunate, because it has reliability benefits that RFC 3164 and RFC lack). 3 Syslog Format 3.1 RFC 3164 This is an RFC 3164 format syslog message: Jul 11 12:34:27 lemon su: 'su root' failed for alice on /dev/pts/3 This format has several problems: 1. The timestamp has no year: you have no idea when this failed privilege escalation attempt occurred. 2. The timestamp has no time zone. Even if it had a year, you d still have no idea when it happened. Page 2 of 9
3 3. Although syslog defines a facility (what subsystem generated the event) and a severity (how important the event is), these are not recorded in the message. 4. Although at first glance syslog messages are single-line records, we have seen newline characters in syslog messages 1. This means that a file containing syslog messages can t be parsed unambiguously. (You make an educated guess: if the start of a line looks like the start of a new message then assume that the previous message is complete.) 5. The standard restricts the total length of the message to 1024 bytes. The typical Windows 2008R2 Security log message is longer than this, and so cannot be converted to syslog format without losing data. 6. The standard only permits plain-text messages. Common log formats, including the Windows Event Log, support binary data in events and so cannot in general be converted to syslog format without losing data or using a binary-to-text conversion mechanism such as Base64 [6]. 7. The standard does not define the character set or encoding for the messages, beyond observing that seven-bit ASCII is most often used. Assuria have seen syslog messages encoded in ASCII, ISO , UTF-8, EUC-JP and Shift_JIS. Given the way that syslog messages are forwarded, it is possible for a single syslog file to contain messages with different character sets/encodings, and with no reliable way to disambiguate (i.e. parse reliably) the resulting file. 8. The message is free-form text: there is no structure in the format that log parsing tools can exploit. This reduces such tools to pattern matching (e.g. regular expressions), which are vulnerable to seeminglyinsignificant changes to the message. For example, basic logon events are logged differently (and require different patterns to match) across currently-supported Enterprise Linux versions and distributions. (It is worth noting that since the syslog message is unstructured, converting a more structured event such as a Windows Event Log event or a Solaris BSM event into a syslog message necessarily discards this structure. In other words, it s a lossy conversion.) 9. Although the standard is reasonably prescriptive about the initial part of the message, many applications and devices that generate syslog messages disregard the standard. The only consistent parts of the syslog message that you can assume will exist in general are the timestamp and hostname. 10. The message has no integrity protection: an attacker can modify it undetectably. Despite RFC 3164 s substantial shortcomings, and the fact that RFC 3164 itself states that there are some concerns about the applicability of this protocol in situations that require robust delivery ( 6), many popular SIEM solutions are entirely 3164-orientated: they normalise all events into RFC 3164 format and forward events via the RFC 3164 protocol. This makes things easy for the SIEM vendor but prohibits non-textual data and events longer than 1024 bytes, and, by RFC 3164 s own admission, destroys integrity and forensic soundness, as defined in section 1 above and discussed in section 4.1 below. 1 Unlike RFC 5424, a strict reading of RFC 3164 prohibits newline characters in messages. As noted however, we have seen them in practice. This illustrates the general laxity and disregard for the standard by applications and devices that generate events in (notionally) RFC 3164 format. Page 3 of 9
4 3.2 RFC 5424 RFC 5424 is Rainer Gerhards attempt to remedy RFC 3164 s shortcomings. The number and nature of those shortcomings mean that the 5424 format bears little relation to 3164, but is still colloquially referred to as syslog. It is essentially a different protocol, related to RFC 3164 in name only. The following example is taken from RFC 5424: T22:14:15.003Z mymachine.example.com evntslog ID47 [examplesdid@32473 iut="3" eventsource="application" eventid="1011"] BOMAn application event log entry... Key features: 1. The initial 1 is a version number. This allows the format to be developed in backwards-incompatible ways without processing software having to apply heuristics to determine how to parse a message, as is currently the case. 2. The timestamp provides a year and a time zone, and hence fixes the problems with the RFC 3164 timestamp. The only (slightly churlish) problem with the 5424 timestamp is that the standard is rather flexible, permitting various different timestamp formats. This makes a parser more difficult to write (and hence more prone to bugs) and permits incomplete timestamps. It would have been better to mandate a single, strict timestamp format, such as one based on ISO 8601 [7]. Still, at least RFC 5424 allows (and encourages) a decent timestamp, rather than prohibiting one as RFC 3164 does. 3. The format has explicit fields for hostname, application, process ID and message ID: there is more structure in the format, which makes parsing easier. 4. The section with square brackets is Structured Data: this allows <name, value> pairs to be expressed, rather than these being embedded within the plain-text message. Although the value is UTF-8, the name is restricted to seven-bit ASCII. The standard claims that structured data are easily parseable, but having implemented parsers for over thirty formats of all shapes and sizes, we beg to differ. The primary complication is that structured data are embedded in an unstructured textual message: control and data are mixed, which always leads to problems including, in a broader context (i.e. software in general), a significant class of security vulnerabilities. The 5424 format is not inherently insecure in this regard, but requires a non-trivial parser. The structured data encoding also disregards typing: values are always strings, even when they re logically numbers (for example). 5. The message is unstructured text, as before. UTF-8 is recommended, but other encodings are permitted. RFC 5424 is a substantial improvement over RFC However, it still has some significant weaknesses: 1. The facility and severity are retained from RFC 3164, but they are again omitted from the message itself. 2. RFC 3164 s length limitation has been raised appreciably. However, receivers are explicitly permitted to truncate and/or discard messages: If a transport receiver receives a message with a length larger than it supports, the transport receiver SHOULD truncate the payload. Alternatively, it MAY discard the message. This alone is arguably Page 4 of 9
5 sufficient to deem the RFC 5424 format unsuitable for a forensicallysound logging infrastructure. At a minimum, one should confirm that the particular receiver[s] being used can cope with arbitrarily long messages (which is of debatable tractability) without such truncation or deletion. 3. Although RFC 5424 resolves many of RFC 3164 s shortcomings, it doesn t mandate these improvements. You can use a decent timestamp, but you don t have to. You can encode everything in UTF-8, but you can use EBCDIC if you fancy it. This makes handling RFC 5424 messages gratuitously complicated: you have to handle numerous timestamp formats, multiple character sets, messages with incomplete fields etc. 4. Perhaps as a consequence of the lax treatment of character sets, RFC 5424 permits a syslog application to reformat control characters received ( 8.2). Not content with permitting truncation and deletion, the standard also permits modification of events. 5. In a regression from RFC 3164, the format merely discourages newlines in messages, rather than prohibiting them: The syslog application SHOULD avoid octet values below 32. These values are legal ( 6.4). A file containing 5424-format messages is therefore ambiguous in the formal grammar sense, which means that there are multiple valid ways to parse the file. Only one of these ways will yield the original events, but there is no way to guarantee which. (You can make a guess that s almost certainly correct, but you re still guessing.) 6. The format is still intrinsically textual: you can t easily represent binary data. 7. There is still no integrity protection, so the messages can again be modified undetectably. RFC 5424 is significantly better than RFC 3164 but also significantly more complicated. Complexity is an enemy of both correctness and security. 4 Syslog Protocol The Syslog Protocol is the means by which syslog messages are transferred between computers. As discussed, there is no such thing as the syslog protocol due to the mutually incompatible RFC 3164 and RFC standards. 4.1 RFC 3164 RFC 3164 s protocol is as simple as they come: prepend <n> to the syslog message, where n encodes the facility and severity, and send the result to UDP port 514. While this simplicity has probably contributed to its popularity, if you want any confidence in the integrity of your log data then it is disastrous: 1. UDP is an unreliable protocol. Unreliable in network terms means that delivery is not guaranteed: the network is within its rights silently to drop the message on the floor, or to duplicate the message. If you send one syslog message, expect any number (zero included) to arrive. 2. UDP does not guarantee that messages are received in the order that they were sent. Since the syslog timestamp granularity is one second, messages within a second cannot be ordered with respect to time. 3. UDP messages can be trivially spoofed, so there is no protection against fake messages being injected into the system. 4. UDP s checksum is weak and optional: there is no protection of any significance against the message being corrupted in transit (accidentally, let alone maliciously). Page 5 of 9
6 5. UDP is not encrypted: the message can be freely observed in transit. 6. UDP has no flow or congestion control: senders can bombard receivers with messages. The standard (indeed, only practical) defence against this is rate-limiting: if you receive too many messages in a certain time then discard further messages (perhaps from certain senders) for some further time period. 7. The sender has no means of knowing whether the receiver is online, let alone whether it s receiving anything. It s fire-and-forget (or fire-andhope). If the receiver is down then you ll lose events until it s reinstated. The common solution to this is highly-available collection infrastructure: this tends to be expensive since you re replicating things, and not as highly-available as you d like to think. You also gain a nontrivial deduplication problem. This means that if you re using RFC 3164 as your transport mechanism you can guarantee none of the following: 1. A received syslog message was legitimately sent. 2. A legitimately sent syslog message was received (e.g. by your SIEM). 3. A received syslog message was the same message that was sent. 4. A received syslog message isn t a duplicate of some other syslog message. If the reader is in any doubt about the shortcomings of RFC 3164 then they can consult the standard itself, which gives an honest, detailed and somewhat whimsical account of its problems 2,3 : There are several security consequences of the fundamental simplicity of syslog and there are some concerns about the applicability of this protocol in situations that require robust delivery ( 6). messages may be sent accidentally, erroneously or even maliciously ( 6). The receiver of the packet [i.e. message] will not be able to ascertain that the message was indeed sent from the reported sender ( 6.2). a misconfigured machine may send syslog messages to a collector representing itself as another machine ( 6.2.1). Malicious exploits of this [message forgery] behavior have also been noted ( 6.2.2) the forensics of a network anomaly rely upon reconstructing the sequence of events the syslog process and protocol do not ensure ordered delivery. ( 6.3) messages may be recorded and replayed at a later time ( 6.3.4), i.e. RFC 3164 syslog is vulnerable to replay attacks. As there is no mechanism within either the syslog process or the protocol to ensure delivery, and since the underlying transport is UDP, some messages may be lost The consequences of [this] cannot be determined ( 6.4). 2 The honesty of RFC 3164 is laudable; the customers of the IT industry would benefit from such honesty and objective analysis becoming more prevalent. 3 These are not criticisms of the designer of the syslog protocol: forensic integrity was not a requirement. The problem is with vendors and consultants who promote RFC 3164 as something that it is not. RFC 3164 is thus deployed inappropriately, with illusory results. Page 6 of 9
7 syslog messages may be damaged in transit, or an attacker may maliciously modify them ( 6.5). Neither the syslog protocol nor the syslog application have mechanisms to provide confidentiality of the messages in transit ( 6.6). A few years ago Assuria visited a customer site to investigate communication problems between Assuria Log Manager (ALM) Agents and the ALM Collector. It transpired that a misconfigured load-balanced switch was discarding one third of the packets that traversed it. ALM noticed because it had problems establishing reliable communications and complained via its own logging/alerting mechanisms (but didn t lose any log data). Had the infrastructure been RFC 3164-based then the customer would have lost, irrevocably and undetectably (unless explicit endto-end tests were undertaken), a third of their events. If the purpose of your logging infrastructure is basic operational monitoring then RFC 3164 may be appropriate, but it is inadequate in almost every respect for any form of security monitoring or auditing. Since RFC 3164 provides a detailed and honest assessment of its shortcomings from a security and integrity perspective, the only logical conclusion that can be drawn about someone who recommends RFC 3164 in environments with such requirements is that they haven t read RFC 3164 before recommending it. 4.2 RFC Unlike RFC 3164, which defines the format and transmission protocol, RFC 5424 just defines the format. Other standards define transmission protocols, or transport mappings. At time of writing, two such mappings are standardised: RFC 5425: Syslog over TLS. RFC 5426: Syslog over UDP. There are various implementations of syslog over TCP. This had an IETF draft [8] but this is now deemed Historic 4, with RFC 5425 recommended instead. RFC 5426 is effectively RFC 3164 s UDP-based approach but carrying RFC format messages. It has similarly prohibitive drawbacks and is not considered here further. RFC 5425 addresses several of the UDP-based protocols problems, but, like the 3164/5424 relationship, falls frustratingly short of providing the necessary levels of integrity for a forensically-sound audit solution (notwithstanding the problems inherent in the 5424 format itself): 1. Messages are sent over a reliable channel, where reliable is used in the formal communication protocol sense. Messages won t be silently discarded or duplicated in transit. ( Silently is the key word here: you can still lose messages in transit, as discussed below. Unlike UDP, you at least know that a problem has occurred though.) 2. The channel can be mutually-authenticated using standard, widelydeployed cryptographic algorithms and protocols. Spoofing is therefore prevented (within normally accepted limits, such as a private key compromise or a break of the cryptographic algorithms being used). 3. TLS provides a cryptographic checksum, so corruption in transit is statistically improbable. (It s physically impossible to prevent such corruption, regardless of the communication channel [9], but it is reduced to an acceptable level.) 4 The IESG does NOT RECOMMEND implementing or deploying syslog over plain TCP Syslog over TLS transport [RFC5425] is recommended. Page 7 of 9
8 4. The communication is strongly encrypted, and hence can t easily be eavesdropped upon. 5. The protocol has flow and congestion control, and authentication makes the trivial denial-of-service attack that UDP is vulnerable to impractical. (You can still launch a DoS attack on a 5425 receiver just as you can launch an attack on any other TCP-based server, but the protocol is not inherently vulnerable.) Like 5424, 5425 is substantially better than The main problem, however, is a lack of application-layer acknowledgements. The standard itself acknowledges this: if the TCP connection (or TLS session) is broken for some reason (or closed by the transport receiver), the syslog transport sender cannot always know what messages were successfully delivered to the syslog application at the other end ( 6.3). Rainer Gerhards himself acknowledged this in 2008: one can not implement a reliable syslog transport without introducing app-level acks. It is simply impossible [10]. Since Gerhards, instrumental in the development of the 5424 family of standards, stated this before RFC 5425 was published, one can only conclude that RFC 5425 was not designed to be used in situations where reliably delivery (a pre-requisite of integrity and forensic soundness) is important. 5 When Worlds Collide The above sections have shown that from an integrity or forensic perspective, RFC 3164 syslog is hopeless while RFC , though substantially better, still has prohibitive problems. However, the combination of RFC 3164 and RFC 5424 makes the situation worse. In technical terms (e.g. message formats) RFC 3164 and RFC 5424 are unrelated protocols. However, in marketing terms they re both syslog, and they have sufficient overlap to cause problems. For example, you can send an RFC 3164 format message and an RFC 5424 format message to the same receiver, and these messages can be written to the same log file. This log file then contains messages in two mutually incompatible formats, arbitrarily interleaved with each other. The 5424 parsing problem, already non-trivial, promptly becomes even harder: we re essentially parsing two unrelated formats, and guessing which parser to use on a per-event basis within the same file (after guessing which character set/encoding to use on a per-event basis within the same file). Parsing via guessing is not likely to be a strategy that wins many friends in an adversarial setting. Unless the entire infrastructure is transitioned to 5424 (which is impractical given currently-available network devices), the only way to avoid this is to rewrite all received messages into 5424 format in a single character set/encoding. Although these modifications might be acceptable from a forensic standpoint, you no longer have the original event and are therefore in a position of having to justify yourself, rather than having nothing to justify. 6 Conclusion This paper has discussed the various mutually-incompatible standards that are popularly referred to as syslog, and assessed them against the requirements for data integrity and forensic soundness. These properties are essential if the outputs of a log management or SIEM solution are to be considered credible when challenged. The original RFC 3164 has major shortcomings and explicitly states that it does not fulfil such requirements. RFC 5424 addresses many of these shortcomings but still has prohibitive weaknesses. RFC 5424 is an opportunity missed, largely through maintaining a pretence that it is syslog and by consequently being overly flexible format-wise and insufficiently strong protocolwise. This was perhaps essential in order to gain traction, however. Page 8 of 9
9 Assuria s position is that RFC 3164 syslog will remain widely deployed for the foreseeable future due to its ubiquity in devices and appliances. Assuria Log Manager therefore provides a syslog receiver that can receive 3164 and 5424 format messages, furnishes both with a standard, normalised timestamp and applies robust cryptographic integrity protection (albeit after the unavoidable syslog network hop). We recommend avoiding syslog if possible; for example: Most operating system audit functions (including the Windows Security Log, Solaris BSM, AIX Audit, HP-UX Trusted Mode Audit) have a rich, structured native format. Collect and retain such logs in that format 5. CheckPoint can log via OPSEC. Sourcefire appliances can log via estreamer (push) or vjdbc (pull). Cisco IPS devices provide CIDEE. SQL Server 2008 Enterprise edition has a fine-grained audit function that yields structured database result sets. Earlier and non-enterprise versions of SQL Server provide C2-compliant auditing in a structured binary format. SharePoint provides a C# API to retrieve audit events as.net objects. Where avoiding syslog is not possible, prefer RFC Where UDP-based syslog is unavoidable, keep hops as short as possible: ideally the sender and receiver should be on the same Ethernet segment, because once UDP hits routers it s liable to be dropped. 7 References 1 C. Lonvick: The BSD syslog protocol. IETF Request for Comments 3164, R. Gerhards: The Syslog Protocol. IETF Request for Comments 5424, F. Miao et al.: Transport Layer Security (TLS) Transport Mapping for Syslog. IETF Request for Comments 5425, A. Okmianski: Transmission of Syslog Messages over UDP. IETF Request for Comments 5426, D. New and M. Rose: Reliable Delivery for syslog. IETF Request for Comments 3195, S. Josefsson: The Base16, Base32, and Base64 Data Encodings. IETF Request for Comments 4648, ISO: Data elements and interchange formats Information interchange Representation of dates and times. ISO 8601, Third edition, R. Gerhards and C. Lonvick: Transmission of Syslog Messages over TCP. IETF draft-gerhards-syslog-plain-tcp-14.txt, C. E. Shannon: A Mathematical Theory of Communication. Bell System Technical Journal 27, pp , , R. Gerhards: why [sic] you can t build a reliable TCP protocol without app-level acks The notion of taking a security audit log, typically accredited at least to EAL 4, lossily-converting it into a less-structured format and then forwarding over an unreliable transport seems somewhat at odds with the concept of security audit. Page 9 of 9
Log Management with Open-Source Tools. Risto Vaarandi SEB Estonia
Log Management with Open-Source Tools Risto Vaarandi SEB Estonia Outline Why use open source tools for log management? Widely used logging protocols and recently introduced new standards Open-source syslog
More informationSY0-201. system so that an unauthorized individual can take over an authorized session, or to disrupt service to authorized users.
system so that an unauthorized individual can take over an authorized session, or to disrupt service to authorized users. From a high-level standpoint, attacks on computer systems and networks can be grouped
More information6b967b2 (2010-12-10) Effective Log Formats
6b967b2 (2010-12-10) Effective Log Formats 1 Introduction Most SIM / SIEM solutions require all non-textual log data (e.g. Windows Event Logs) to be rewritten into a simple textual format such as syslog.
More informationAssuria can help protectively monitor firewalls for PCI compliance. Assuria can also check the configurations of personal firewalls on host devices
The Payment Card Industry (PCI) Data Security Standard (DSS) provides an actionable framework for developing a robust payment card data security process. The Payment Application Data Security Standard
More informationLog Management with Open-Source Tools. Risto Vaarandi rvaarandi 4T Y4H00 D0T C0M
Log Management with Open-Source Tools Risto Vaarandi rvaarandi 4T Y4H00 D0T C0M Outline Why do we need log collection and management? Why use open source tools? Widely used logging protocols and recently
More informationAn Introduction to Syslog. Rainer Gerhards Adiscon
An Introduction to Syslog Rainer Gerhards Adiscon What is Syslog? The heterogeneous network logging workhorse a system to emit/store/process meaningful log messages both a communications protocol as well
More informationAdvanced Computer Networks IN2097. 1 Dec 2015
Chair for Network Architectures and Services Technische Universität München Advanced Computer Networks IN2097 1 Dec 2015 Prof. Dr.-Ing. Georg Carle Chair for Network Architectures and Services Department
More informationsyslog-ng 3.0 Monitoring logs with Nagios
syslog-ng 3.0 Monitoring logs with Nagios Scheidler Balázs balazs.scheidler@balabit.hu Table of Contents Short introduction to syslog The syslog-ng story Changes in the log processing landscape New vision
More informationDistributed syslog architectures with syslog-ng Premium Edition
Distributed syslog architectures with syslog-ng Premium Edition May 12, 2011 The advantages of using syslog-ng Premium Edition to create distributed system logging architectures. Copyright 1996-2011 BalaBit
More information7 Network Security. 7.1 Introduction 7.2 Improving the Security 7.3 Internet Security Framework. 7.5 Absolute Security?
7 Network Security 7.1 Introduction 7.2 Improving the Security 7.3 Internet Security Framework 7.4 Firewalls 7.5 Absolute Security? 7.1 Introduction Security of Communications data transport e.g. risk
More informationIntrusion Detection Systems
Intrusion Detection Systems Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 Jain@cse.wustl.edu Audio/Video recordings of this lecture are available at: http://www.cse.wustl.edu/~jain/cse571-07/
More informationData Collection and Analysis: Get End-to-End Security with Cisco Connected Analytics for Network Deployment
White Paper Data Collection and Analysis: Get End-to-End Security with Cisco Connected Analytics for Network Deployment Cisco Connected Analytics for Network Deployment (CAND) is Cisco hosted, subscription-based
More information2. From a control perspective, the PRIMARY objective of classifying information assets is to:
MIS5206 Week 13 Your Name Date 1. When conducting a penetration test of an organization's internal network, which of the following approaches would BEST enable the conductor of the test to remain undetected
More informationE-Commerce Security. The Client-Side Vulnerabilities. Securing the Data Transaction LECTURE 7 (SECURITY)
E-Commerce Security An e-commerce security system has four fronts: LECTURE 7 (SECURITY) Web Client Security Data Transport Security Web Server Security Operating System Security A safe e-commerce system
More informationBuilding Your Firewall Rulebase Lance Spitzner Last Modified: January 26, 2000
Building Your Firewall Rulebase Lance Spitzner Last Modified: January 26, 2000 Building a solid rulebase is a critical, if not the most critical, step in implementing a successful and secure firewall.
More informationWireless Encryption Protection
Wireless Encryption Protection We re going to jump around a little here and go to something that I really find interesting, how do you secure yourself when you connect to a router. Now first and foremost
More informationDOMAIN NAME SECURITY EXTENSIONS
DOMAIN NAME SECURITY EXTENSIONS The aim of this paper is to provide information with regards to the current status of Domain Name System (DNS) and its evolution into Domain Name System Security Extensions
More informationOverview. Securing TCP/IP. Introduction to TCP/IP (cont d) Introduction to TCP/IP
Overview Securing TCP/IP Chapter 6 TCP/IP Open Systems Interconnection Model Anatomy of a Packet Internet Protocol Security (IPSec) Web Security (HTTP over TLS, Secure-HTTP) Lecturer: Pei-yih Ting 1 2
More informationPrivyLink Internet Application Security Environment *
WHITE PAPER PrivyLink Internet Application Security Environment * The End-to-end Security Solution for Internet Applications September 2003 The potential business advantages of the Internet are immense.
More informationSecurity vulnerabilities in the Internet and possible solutions
Security vulnerabilities in the Internet and possible solutions 1. Introduction The foundation of today's Internet is the TCP/IP protocol suite. Since the time when these specifications were finished in
More informationFirewalls, Tunnels, and Network Intrusion Detection
Firewalls, Tunnels, and Network Intrusion Detection 1 Part 1: Firewall as a Technique to create a virtual security wall separating your organization from the wild west of the public internet 2 1 Firewalls
More informationAccess Control: Firewalls (1)
Access Control: Firewalls (1) World is divided in good and bad guys ---> access control (security checks) at a single point of entry/exit: in medieval castles: drawbridge in corporate buildings: security/reception
More informationGuideline on Auditing and Log Management
CMSGu2012-05 Mauritian Computer Emergency Response Team CERT-MU SECURITY GUIDELINE 2011-02 Enhancing Cyber Security in Mauritius Guideline on Auditing and Log Management National Computer Board Mauritius
More informationNAT TCP SIP ALG Support
The feature allows embedded messages of the Session Initiation Protocol (SIP) passing through a device that is configured with Network Address Translation (NAT) to be translated and encoded back to the
More informationIPsec Details 1 / 43. IPsec Details
Header (AH) AH Layout Other AH Fields Mutable Parts of the IP Header What is an SPI? What s an SA? Encapsulating Security Payload (ESP) ESP Layout Padding Using ESP IPsec and Firewalls IPsec and the DNS
More informationProtocol Rollback and Network Security
CSE 484 / CSE M 584 (Spring 2012) Protocol Rollback and Network Security Tadayoshi Kohno Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin, John Manferdelli, John Mitchell, Vitaly Shmatikov, Bennet Yee,
More informationFinal exam review, Fall 2005 FSU (CIS-5357) Network Security
Final exam review, Fall 2005 FSU (CIS-5357) Network Security Instructor: Breno de Medeiros 1. What is an insertion attack against a NIDS? Answer: An insertion attack against a network intrusion detection
More informationFirewalls and Intrusion Detection
Firewalls and Intrusion Detection What is a Firewall? A computer system between the internal network and the rest of the Internet A single computer or a set of computers that cooperate to perform the firewall
More informationFirewalls, Tunnels, and Network Intrusion Detection. Firewalls
Firewalls, Tunnels, and Network Intrusion Detection 1 Firewalls A firewall is an integrated collection of security measures designed to prevent unauthorized electronic access to a networked computer system.
More informationHigh Performance VPN Solutions Over Satellite Networks
High Performance VPN Solutions Over Satellite Networks Enhanced Packet Handling Both Accelerates And Encrypts High-Delay Satellite Circuits Characteristics of Satellite Networks? Satellite Networks have
More informationFINAL DoIT 11.03.2015 - v.4 PAYMENT CARD INDUSTRY DATA SECURITY STANDARDS APPLICATION DEVELOPMENT AND MAINTENANCE PROCEDURES
Purpose: The Department of Information Technology (DoIT) is committed to developing secure applications. DoIT s System Development Methodology (SDM) and Application Development requirements ensure that
More informationPassing PCI Compliance How to Address the Application Security Mandates
Passing PCI Compliance How to Address the Application Security Mandates The Payment Card Industry Data Security Standards includes several requirements that mandate security at the application layer. These
More informationChapter 9. IP Secure
Chapter 9 IP Secure 1 Network architecture is usually explained as a stack of different layers. Figure 1 explains the OSI (Open System Interconnect) model stack and IP (Internet Protocol) model stack.
More informationHANDBOOK 8 NETWORK SECURITY Version 1.0
Australian Communications-Electronic Security Instruction 33 (ACSI 33) Point of Contact: Customer Services Team Phone: 02 6265 0197 Email: assist@dsd.gov.au HANDBOOK 8 NETWORK SECURITY Version 1.0 Objectives
More informationSecurity (II) ISO 7498-2: Security Architecture of OSI Reference Model. Outline. Course Outline: Fundamental Topics. EE5723/EE4723 Spring 2012
Course Outline: Fundamental Topics System View of Network Security Network Security Model Security Threat Model & Security Services Model Overview of Network Security Security Basis: Cryptography Secret
More informationINTERNET SECURITY: FIREWALLS AND BEYOND. Mehernosh H. Amroli 4-25-2002
INTERNET SECURITY: FIREWALLS AND BEYOND Mehernosh H. Amroli 4-25-2002 Preview History of Internet Firewall Technology Internet Layer Security Transport Layer Security Application Layer Security Before
More informationThreatSpike Dome: A New Approach To Security Monitoring
ThreatSpike Dome: A New Approach To Security Monitoring 2015 ThreatSpike Labs Limited The problem with SIEM Hacking, insider and advanced persistent threats can be difficult to detect with existing product
More informationSimple Network Management Protocol
A Seminar Report on Simple Network Management Protocol Submitted in partial fulfillment of the requirement for the award of degree Of Computer Science SUBMITTED TO: SUBMITTED BY: www.studymafia.org www.studymafia.org
More informationThe syslog-ng Store Box 3 F2
The syslog-ng Store Box 3 F2 PRODUCT DESCRIPTION Copyright 2000-2014 BalaBit IT Security All rights reserved. www.balabit.com Introduction The syslog-ng Store Box (SSB) is a high-reliability and high-performance
More informationComparative Analysis of Open-Source Log Management Solutions for Security Monitoring and Network Forensics
Comparative Analysis of Open-Source Log Management Solutions for Security Monitoring and Network Forensics Risto Vaarandi, Paweł Niziski NATO Cooperative Cyber Defence Centre of Excellence, Tallinn, Estonia
More informationSession Hijacking Exploiting TCP, UDP and HTTP Sessions
Session Hijacking Exploiting TCP, UDP and HTTP Sessions Shray Kapoor shray.kapoor@gmail.com Preface With the emerging fields in e-commerce, financial and identity information are at a higher risk of being
More informationNetwork Working Group Request for Comments: 840 April 1983. Official Protocols
Network Working Group Request for Comments: 840 J. Postel ISI April 1983 This RFC identifies the documents specifying the official protocols used in the Internet. Annotations identify any revisions or
More informationCOSC 472 Network Security
COSC 472 Network Security Instructor: Dr. Enyue (Annie) Lu Office hours: http://faculty.salisbury.edu/~ealu/schedule.htm Office room: HS114 Email: ealu@salisbury.edu Course information: http://faculty.salisbury.edu/~ealu/cosc472/cosc472.html
More informationOPENID AUTHENTICATION SECURITY
OPENID AUTHENTICATION SECURITY Erik Lagercrantz and Patrik Sternudd Uppsala, May 17 2009 1 ABSTRACT This documents gives an introduction to OpenID, which is a system for centralised online authentication.
More informationCS5008: Internet Computing
CS5008: Internet Computing Lecture 22: Internet Security A. O Riordan, 2009, latest revision 2015 Internet Security When a computer connects to the Internet and begins communicating with others, it is
More informationSecond-generation (GenII) honeypots
Second-generation (GenII) honeypots Bojan Zdrnja CompSci 725, University of Auckland, Oct 2004. b.zdrnja@auckland.ac.nz Abstract Honeypots are security resources which trap malicious activities, so they
More informationSecure Software Programming and Vulnerability Analysis
Secure Software Programming and Vulnerability Analysis Christopher Kruegel chris@auto.tuwien.ac.at http://www.auto.tuwien.ac.at/~chris Operations and Denial of Service Secure Software Programming 2 Overview
More informationPotential Targets - Field Devices
Potential Targets - Field Devices Motorola Field Devices: Remote Terminal Units ACE 3600 Front End Devices ACE IP Gateway ACE Field Interface Unit (ACE FIU) 2 Credential Cracking Repeated attempts to
More informationBarracuda Intrusion Detection and Prevention System
Providing complete and comprehensive real-time network protection Today s networks are constantly under attack by an ever growing number of emerging exploits and attackers using advanced evasion techniques
More informationSitefinity Security and Best Practices
Sitefinity Security and Best Practices Table of Contents Overview The Ten Most Critical Web Application Security Risks Injection Cross-Site-Scripting (XSS) Broken Authentication and Session Management
More informationCSCI 4250/6250 Fall 2015 Computer and Networks Security
CSCI 4250/6250 Fall 2015 Computer and Networks Security Network Security Goodrich, Chapter 5-6 Tunnels } The contents of TCP packets are not normally encrypted, so if someone is eavesdropping on a TCP
More informationChapter 17. Transport-Level Security
Chapter 17 Transport-Level Security Web Security Considerations The World Wide Web is fundamentally a client/server application running over the Internet and TCP/IP intranets The following characteristics
More informationDos & DDoS Attack Signatures (note supplied by Steve Tonkovich of CAPTUS NETWORKS)
Dos & DDoS Attack Signatures (note supplied by Steve Tonkovich of CAPTUS NETWORKS) Signature based IDS systems use these fingerprints to verify that an attack is taking place. The problem with this method
More informationKiwi SyslogGen. A Freeware Syslog message generator for Windows. by SolarWinds, Inc.
Kiwi SyslogGen A Freeware Syslog message generator for Windows by SolarWinds, Inc. Kiwi SyslogGen is a free Windows Syslog message generator which sends Unix type Syslog messages to any PC or Unix Syslog
More informationHushmail Express Password Encryption in Hushmail. Brian Smith Hush Communications
Hushmail Express Password Encryption in Hushmail Brian Smith Hush Communications Introduction...2 Goals...2 Summary...2 Detailed Description...4 Message Composition...4 Message Delivery...4 Message Retrieval...5
More informationNetwork Intrusion Detection Systems. Beyond packet filtering
Network Intrusion Detection Systems Beyond packet filtering Goal of NIDS Detect attacks as they happen: Real-time monitoring of networks Provide information about attacks that have succeeded: Forensic
More informationAlliance Key Manager Solution Brief
Alliance Key Manager Solution Brief KEY MANAGEMENT Enterprise Encryption Key Management On the road to protecting sensitive data assets, data encryption remains one of the most difficult goals. A major
More informationPolicy Management: The Avenda Approach To An Essential Network Service
End-to-End Trust and Identity Platform White Paper Policy Management: The Avenda Approach To An Essential Network Service http://www.avendasys.com email: info@avendasys.com email: sales@avendasys.com Avenda
More informationSite to Site Virtual Private Networks (VPNs):
Site to Site Virtual Private Networks Programme NPFIT DOCUMENT RECORD ID KEY Sub-Prog / Project Information Governance NPFIT-FNT-TO-IG-GPG-0002.01 Prog. Director Mark Ferrar Owner Tim Davis Version 1.0
More informationComputer Security DD2395 http://www.csc.kth.se/utbildning/kth/kurser/dd2395/dasakh10/
Computer Security DD2395 http://www.csc.kth.se/utbildning/kth/kurser/dd2395/dasakh10/ Fall 2010 Sonja Buchegger buc@kth.se Lecture 13, Dec. 6, 2010 Auditing Security Audit an independent review and examination
More informationAbstract. Introduction. Section I. What is Denial of Service Attack?
Abstract In this report, I am describing the main types of DoS attacks and their effect on computer and network environment. This report will form the basis of my forthcoming report which will discuss
More informationsyslog-ng Store Box PRODUCT DESCRIPTION Copyright 2000-2009 BalaBit IT Security All rights reserved. www.balabit.com
syslog-ng Store Box PRODUCT DESCRIPTION Copyright 2000-2009 BalaBit IT Security All rights reserved. www.balabit.com Introduction Log messages contain information about the events happening on the hosts.
More informationFINAL DoIT 04.01.2013- v.8 APPLICATION SECURITY PROCEDURE
Purpose: This procedure identifies what is required to ensure the development of a secure application. Procedure: The five basic areas covered by this document include: Standards for Privacy and Security
More informationThe basic groups of components are described below. Fig X- 1 shows the relationship between components on a network.
Elements of Email Email Components There are a number of software components used to produce, send and transfer email. These components can be broken down as clients or servers, although some components
More informationNetwork Security Part II: Standards
Network Security Part II: Standards Raj Jain Washington University Saint Louis, MO 63131 Jain@cse.wustl.edu These slides are available on-line at: http://www.cse.wustl.edu/~jain/cse473-05/ 18-1 Overview
More informationFile Transfer And Access (FTP, TFTP, NFS) Chapter 25 By: Sang Oh Spencer Kam Atsuya Takagi
File Transfer And Access (FTP, TFTP, NFS) Chapter 25 By: Sang Oh Spencer Kam Atsuya Takagi History of FTP The first proposed file transfer mechanisms were developed for implementation on hosts at M.I.T.
More informationTECHNICAL CHALLENGES OF VoIP BYPASS
TECHNICAL CHALLENGES OF VoIP BYPASS Presented by Monica Cultrera VP Software Development Bitek International Inc 23 rd TELELCOMMUNICATION CONFERENCE Agenda 1. Defining VoIP What is VoIP? How to establish
More informationCOORDINATED THREAT CONTROL
APPLICATION NOTE COORDINATED THREAT CONTROL Interoperability of Juniper Networks IDP Series Intrusion Detection and Prevention Appliances and SA Series SSL VPN Appliances Copyright 2010, Juniper Networks,
More informationThe syslog-ng Premium Edition 5LTS
The syslog-ng Premium Edition 5LTS PRODUCT DESCRIPTION Copyright 2000-2013 BalaBit IT Security All rights reserved. www.balabit.com Introduction The syslog-ng Premium Edition enables enterprises to collect,
More informationChapter 3. TCP/IP Networks. 3.1 Internet Protocol version 4 (IPv4)
Chapter 3 TCP/IP Networks 3.1 Internet Protocol version 4 (IPv4) Internet Protocol version 4 is the fourth iteration of the Internet Protocol (IP) and it is the first version of the protocol to be widely
More informationFirewall Introduction Several Types of Firewall. Cisco PIX Firewall
Firewall Introduction Several Types of Firewall. Cisco PIX Firewall What is a Firewall? Non-computer industries: a wall that controls the spreading of a fire. Networks: a designed device that controls
More informationiscsi Security (Insecure SCSI) Presenter: Himanshu Dwivedi
iscsi Security (Insecure SCSI) Presenter: Himanshu Dwivedi Agenda Introduction iscsi Attacks Enumeration Authorization Authentication iscsi Defenses Information Security Partners (isec) isec Partners Independent
More informationFREQUENTLY ASKED QUESTIONS
FREQUENTLY ASKED QUESTIONS Secure Bytes, October 2011 This document is confidential and for the use of a Secure Bytes client only. The information contained herein is the property of Secure Bytes and may
More informationVulnerabilità dei protocolli SSL/TLS
Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Dipartimento di Informatica e Comunicazione Vulnerabilità dei protocolli SSL/TLS Andrea Visconti Overview Introduction
More informationCS 356 Lecture 16 Denial of Service. Spring 2013
CS 356 Lecture 16 Denial of Service Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access Control Lists Chapter
More informationAuthenticity of Public Keys
SSL/TLS EJ Jung 10/18/10 Authenticity of Public Keys Bob s key? private key Bob public key Problem: How does know that the public key she received is really Bob s public key? Distribution of Public Keys!
More informationProtecting Your Organisation from Targeted Cyber Intrusion
Protecting Your Organisation from Targeted Cyber Intrusion How the 35 mitigations against targeted cyber intrusion published by Defence Signals Directorate can be implemented on the Microsoft technology
More informationFirst Semester Examinations 2011/12 INTERNET PRINCIPLES
PAPER CODE NO. EXAMINER : Martin Gairing COMP211 DEPARTMENT : Computer Science Tel. No. 0151 795 4264 First Semester Examinations 2011/12 INTERNET PRINCIPLES TIME ALLOWED : Two Hours INSTRUCTIONS TO CANDIDATES
More informationCommon Event Expression
Common Event Expression Architecture Overview Version 0.5 The CEE Editorial Board May 2010 Approved for Public Release; Distribution Unlimited. Case 10-2296 This page intentionally left blank. Acknowledgments
More informationTopics in Network Security
Topics in Network Security Jem Berkes MASc. ECE, University of Waterloo B.Sc. ECE, University of Manitoba www.berkes.ca February, 2009 Ver. 2 In this presentation Wi-Fi security (802.11) Protecting insecure
More information13 Virtual Private Networks 13.1 Point-to-Point Protocol (PPP) 13.2 Layer 2/3/4 VPNs 13.3 Multi-Protocol Label Switching 13.4 IPsec Transport Mode
13 Virtual Private Networks 13.1 Point-to-Point Protocol (PPP) PPP-based remote access using dial-in PPP encryption control protocol (ECP) PPP extensible authentication protocol (EAP) 13.2 Layer 2/3/4
More informationVICTORIA UNIVERSITY OF WELLINGTON Te Whare Wānanga o te Ūpoko o te Ika a Māui
VICTORIA UNIVERSITY OF WELLINGTON Te Whare Wānanga o te Ūpoko o te Ika a Māui School of Engineering and Computer Science Te Kura Mātai Pūkaha, Pūrorohiko PO Box 600 Wellington New Zealand Tel: +64 4 463
More informationThe Trivial Cisco IP Phones Compromise
Security analysis of the implications of deploying Cisco Systems SIP-based IP Phones model 7960 Ofir Arkin Founder The Sys-Security Group ofir@sys-security.com http://www.sys-security.com September 2002
More informationRARP: Reverse Address Resolution Protocol
SFWR 4C03: Computer Networks and Computer Security January 19-22 2004 Lecturer: Kartik Krishnan Lectures 7-9 RARP: Reverse Address Resolution Protocol When a system with a local disk is bootstrapped it
More informationOverview of Network Security The need for network security Desirable security properties Common vulnerabilities Security policy designs
Overview of Network Security The need for network security Desirable security properties Common vulnerabilities Security policy designs Why Network Security? Keep the bad guys out. (1) Closed networks
More informationThe syslog-ng Premium Edition 5F2
The syslog-ng Premium Edition 5F2 PRODUCT DESCRIPTION Copyright 2000-2014 BalaBit IT Security All rights reserved. www.balabit.com Introduction The syslog-ng Premium Edition enables enterprises to collect,
More informationPayment Card Industry Data Security Standard Payment Card Industry Data Security Standard (PCI / DSS)
Payment Card Industry Data Security Standard (PCI / DSS) InterSect Alliance International Pty Ltd Page 1 of 12 Intersect Alliance International Pty Ltd. All rights reserved worldwide. Intersect Alliance
More informationLecture 17 - Network Security
Lecture 17 - Network Security CMPSC 443 - Spring 2012 Introduction Computer and Network Security Professor Jaeger www.cse.psu.edu/~tjaeger/cse443-s12/ Idea Why donʼt we just integrate some of these neat
More informationThe Cyber Threat Profiler
Whitepaper The Cyber Threat Profiler Good Intelligence is essential to efficient system protection INTRODUCTION As the world becomes more dependent on cyber connectivity, the volume of cyber attacks are
More informationIntrusion Detections Systems
Intrusion Detections Systems 2009-03-04 Secure Computer Systems Poia Samoudi Asli Davor Sutic Contents Intrusion Detections Systems... 1 Contents... 2 Abstract... 2 Introduction... 3 IDS importance...
More informationPART OF THE PICTURE: The TCP/IP Communications Architecture
PART OF THE PICTURE: The / Communications Architecture 1 PART OF THE PICTURE: The / Communications Architecture BY WILLIAM STALLINGS The key to the success of distributed applications is that all the terminals
More informationSNARE Agent for Windows v 4.2.3 - Release Notes
SNARE Agent for Windows v 4.2.3 - Release Notes Snare is a program that facilitates the central collection and processing of the Windows Event Log information. All three primary event logs (Application,
More informationPROFESSIONAL SECURITY SYSTEMS
PROFESSIONAL SECURITY SYSTEMS Security policy, active protection against network attacks and management of IDP Introduction Intrusion Detection and Prevention (IDP ) is a new generation of network security
More informationEthernet. Ethernet. Network Devices
Ethernet Babak Kia Adjunct Professor Boston University College of Engineering ENG SC757 - Advanced Microprocessor Design Ethernet Ethernet is a term used to refer to a diverse set of frame based networking
More informationWHITE PAPER. FortiWeb and the OWASP Top 10 Mitigating the most dangerous application security threats
WHITE PAPER FortiWeb and the OWASP Top 10 PAGE 2 Introduction The Open Web Application Security project (OWASP) Top Ten provides a powerful awareness document for web application security. The OWASP Top
More informationInternet Firewall Tutorial A White Paper January 2005
Internet Firewall Tutorial A White Paper January 2005 The Mansion, Bletchley Park Milton Keynes MK3 6EB, UK Tel: 01908 276650 Fax: 01908 276699 http://www.ipcortex.co.uk/ About the Author Rob Pickering
More informationServer Security. Contents. Is Rumpus Secure? 2. Use Care When Creating User Accounts 2. Managing Passwords 3. Watch Out For Aliases 4
Contents Is Rumpus Secure? 2 Use Care When Creating User Accounts 2 Managing Passwords 3 Watch Out For Aliases 4 Deploy A Firewall 5 Minimize Running Applications And Processes 5 Manage Physical Access
More informationCounter Expertise Review on the TNO Security Analysis of the Dutch OV-Chipkaart. OV-Chipkaart Security Issues Tutorial for Non-Expert Readers
Counter Expertise Review on the TNO Security Analysis of the Dutch OV-Chipkaart OV-Chipkaart Security Issues Tutorial for Non-Expert Readers The current debate concerning the OV-Chipkaart security was
More informationFirewall-Friendly VoIP Secure Gateway and VoIP Security Issues
Firewall-Friendly VoIP Secure Gateway and VoIP Security Issues v Noriyuki Fukuyama v Shingo Fujimoto v Masahiko Takenaka (Manuscript received September 26, 2003) IP telephony services using VoIP (Voice
More information