Novels
The first part of the list is of novels I have read in the last year that have a strong IT security focus, are well written, and can teach the security interested IT professional something about security. If you haven’t read them yet, they should definitely be on your reading list.
They’re listed in the order I read them, which is conveniently also alphabetical order.
Cryptonomicon
This Neal Stephenson novel is a trifle unique in that it is actually two tales, each with its own plot, in one. The narrative switches between these tales regularly, one set during World War II, the other in the modern world. Specific modern technologies are often fictionalized (e.g. Finux, a thinly veiled reference to Linux, and Ordo, an encryption system that doesn’t exist in the real world but very well could), while more general technologies (e.g. cryptographic technologies in general) are entirely real.
The story introduces the reader to concepts that, for most of us, may be new. It ends up being kind of accidentally educational in that respect, presenting ideas about cryptographic currencies, principles of cryptographic technology, and some of the history of modern computing and modern cryptography in forms easily digestible for the technically inclined reader. It even presents a rather unique demonstration of basic cryptographic principles in action in the form of the Solitaire cipher, a cryptographic system invented by Bruce Schneier specifically for Cryptonomicon that can be employed without a computer, via a normal deck of playing cards. It’s not a trivial, toy cryptographic system, however: it is meant to be a form of strong cryptography and, in fact, when Cryptonomicon was published with the Solitaire cipher algorithm printed within its pages in the form of a Perl script, saving that script in a file on a computer in the US and emailing it to someone in another country would have violated US munitions export laws because it qualifies as “strong encryption”.
Halting State
Probably the least directly educational of the three, this novel by Charles Stross is most interesting for its speculations on virtual currencies, virtual realities in meatspace, cyber-terrorism, and the social implications of all of the above. The primary characters are involved in the investigation of what starts out looking like the “robbery” of a virtual bank in a near-future MMORPG, but quickly spins out of control as they discover that all is not as it at first seems.
It is written primarily in the second person, reminiscent of old text based adventure games, which I found a little difficult to get into at first — especially with the switching between perspective characters in different chapters. It’s an engrossing tale, with a well constructed plot, however.
Little Brother
Cory Doctorow set out to write this novel for “young adults” (i.e. teenagers), with an intentionally educational thread throughout. The main character, a high school student with a perhaps more than healthy interest in learning what others don’t want him to know (and using that knowledge), is a hacker in the original sense who, written in the first person perspective, spends a fair bit of time explaining matters of IT security to the reader.
Little Brother is probably the best-written work of fiction that doubles as an educational text I have ever read, in part because it presents basic concepts within the context of the story and encourages the reader to pursue further knowledge on his or her own. If you read the entire novel and don’t find yourself inspired to read more on the subjects and concepts presented, you may just not be cut out to be a technologist at all. It’s the kind of book I wish I had in my hands when I was thirteen — but even now, about two decades older, it was a thoroughly enjoyable and inspiring read.
The plot surrounds the events following a terrorist attack on the Bay Bridge in San Francisco, in a future so near it was quite a while before I was sure it wasn’t written to basically take place in the present. Politically, it looks like it may take place around 2011 some time, though it is flexible enough that it might believably take place any time in the next decade. The technologies are essentially the technologies we know today, with a few specific additions that could well arise in the next few years.
Like usual, Doctorow’s challenges to the dominant paradigm go beyond the content of his fiction: this novel is not only available at bookstores and libraries, but also as a free download under the terms of a Creative Commons license. If you like reading full-length novels in digital file formats, you can get it there as a plain text, PDF, or HTML formatted file. I personally prefer having a physical book in my hands, so that’s the form of the novel I read.
For a more personal take on Little Brother, check out my brief review in my personal Weblog.
Related reading
The second part of the list is works that aren’t novels — in one case, a book-length essay on the development of operating systems, and in the other a collection of short stories.
In the Beginning was the Command Line
People who enjoy Cryptonomicon may also want to read Stephenson’s In the Beginning was the Command Line, a lengthy essay examining the history of operating systems. It was written in the late 1990s, and is a little dated now, but the lessons it conveys are no less valuable. While it doesn’t directly address security, it does provide some insights into the design philosophies and necessities of operating systems, the collective mindset of their users, and other matters that provide a basis for understanding the security characteristics of systems incorporating various OSes and real-life end users. It has been published as a short book, but is also available for download as a Mac Stuffit or Zip compressed plain text file, free of charge. Among the rest of the works in this list, this is the only one I read for the first time before 17 July 2007. I have read it several times, however, the most recent being a few months ago. It’s not only worth reading once — it’s worth revisiting.
Overclocked: Stores of the Future Present
Doctorow’s Overclocked: Stories of the Future Present is a collection of short stories by the author of Little Brother. Many of them, individually, seem tailor-made to challenge the comfortable preconceptions of the modern technologist, illustrating in science fiction prose the possible consequences of contemporary technology policy. Like Little Brother, and most if not all the rest of Doctorow’s fiction, it is available as a free download as well as in dead-tree hardcopy editions.
Recommendations
If you’re a technology enthusiast, and there’s anything in the above list of works that you haven’t read, you should rectify that oversight soon. They’re all well written, informative, and often inspiring. Three of them are even available for free online, so the excuses for failing to read them lie somewhere between slim and none.
Tuesday, July 29, 2008
Bignum arithmetic and premature optimization
Donald Knuth, the patron saint of algorithm analysis, once famously said “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” Programmers of a thoughtful bent constantly argue over what this means, and at times whether it is even true. Mostly, they ignore its effect on security.
As new programming languages become ever-more “high level” and dynamic, they get further and further from forcing the programmer to cater to the way computers “think”. This provides significant advantages for developing software swiftly and easily, sometimes at significant costs to the efficiency of the code itself. Moore’s Law, however, ensures that for many (if not most) cases those efficiency costs are absorbed by the hardware so thoroughly that users never see the difference, at least in a one-to-one comparison of general software functionality. In fact, for the same general functionality, software written in a higher level language will often outperform software written in a lower level language, if each is run on hardware contemporary with the language’s inception.
Of course, featuritis — a separate phenomenon entirely — often adds far greater weight to an application that combines with the greater resource usage of higher level dynamic languages to slow things down to the point where we start noticing something is wrong. That, however, is an entirely separate matter.
There are those who will argue that choosing a language based on the comparative performance characteristics of programs written in that language is a case of premature optimization. When all you need is a command line utility that will complete its task in under half a second, and Ruby can fill that need, resorting to assembly language to eke maximum performance out of the program certainly seems like a bad trade, if the tendency of Ruby programs to be much easier to write and maintain is considered.
There is certainly a case to be made for lower level languages contributing to greater security. Knowing assembly language, or even a higher level “portable assembly” language such as C, helps the programmer wrap his brain around the concepts of von Neumann architecture computation. Even if you write all your software in a very high level language like Ruby, knowing what’s going on “under the hood”, as it were, can yield great rewards when some careful, precise tinkering is necessary — and in understanding the implications of what you’re doing with all those high level language constructs. This applies to security implications as much as to performance, portability, and stability implications.
Don’t take anything said here as dissuading you from learning lower level, static languages such as C or assembly. Even if you never use them in earnest, knowing these languages will help you really understand what you’re doing with higher level, dynamic languages, and may help you make your code more secure.
On the other hand, high level dynamic languages such as Ruby provide a lot of time saving linguistic constructs that, often as a happy accident, actually improve the security of your code without any effort on your part. An example is “bignum” handling.
In programming languages such as C, integers have limits to how big they can get. For instance, an unsigned integer variable might be limited to 16 bits — between 0 and 216-1 (i.e. 0 to 65535). In unsigned 16 bit integer arithmetic, usually 65535 + 1 = 0, because the short integer type is incapable of representing a numeric value outside the range of 0-65535. In some cases, trying to stick a larger value than a data type can handle into a variable of that data type can crash the program, provide improper access to memory, or cause any of a number of other potential security issues. For this reason, programmers in languages like C need to be careful about how they use limited precision data types.
Arbitrary precision arithmetic, also known as “bignum arithmetic”, is an arithmetic technique implemented in a programming language whereby the extent of an integer’s value is limited only by the restrictions of the hardware itself — essentially, by how much RAM the system has. This can, for instance, take the form of an automatic extension of the value that can be handled by the data type as it is needed, rather than limiting the value to an extent defined before a value is entered into a variable or otherwise handled by the program. As this greatly reduces the inherent danger of accepting overly large inputs, bignum arithmetic can prove a great boon to the security of a program.
Such arbitrary precision arithmetic capabilities can be had with languages such as C, via libraries like BigDigits, the GNU MPL, and CLN, but this is not the default behavior of the language and requires explicit use by the programmer. Languages such as Ruby, on the other hand, employ bignum arithmetic by default, as it is needed, without requiring any intervention on the part of the programmer to specify that extensibility of the values that can be handled by numeric data types. It’s important to understand concepts like fixed integer arithmetic, of course, but it’s not important to use it all the time — or even most of the time.
There are programmers who would complain at this implication, because arbitrary precision arithmetic generally imposes an efficiency penalty on programs that make use of it. In most cases, however, such concerns constitute a case of Knuth’s “premature optimization”, because unnecessary use of fixed precision arithmetic can lead to surprising behavior from your software if you make a mistake in development and some unexpected input overflows an integer.
For security purposes, it’s generally the case that Ruby’s way of doing this is the right way to do it: default to avoiding the all too common dangers of fixed precision arithmetic altogether. The only fly in the ointment is the rare occasion where the performance penalties of arbitrary precision arithmetic really matters — or the rare field of endeavor where it matters often.
When the importance of a nanosecond improvement in runtime is not needed, choose the tools that will make it easy to write more secure code.
As new programming languages become ever-more “high level” and dynamic, they get further and further from forcing the programmer to cater to the way computers “think”. This provides significant advantages for developing software swiftly and easily, sometimes at significant costs to the efficiency of the code itself. Moore’s Law, however, ensures that for many (if not most) cases those efficiency costs are absorbed by the hardware so thoroughly that users never see the difference, at least in a one-to-one comparison of general software functionality. In fact, for the same general functionality, software written in a higher level language will often outperform software written in a lower level language, if each is run on hardware contemporary with the language’s inception.
Of course, featuritis — a separate phenomenon entirely — often adds far greater weight to an application that combines with the greater resource usage of higher level dynamic languages to slow things down to the point where we start noticing something is wrong. That, however, is an entirely separate matter.
There are those who will argue that choosing a language based on the comparative performance characteristics of programs written in that language is a case of premature optimization. When all you need is a command line utility that will complete its task in under half a second, and Ruby can fill that need, resorting to assembly language to eke maximum performance out of the program certainly seems like a bad trade, if the tendency of Ruby programs to be much easier to write and maintain is considered.
There is certainly a case to be made for lower level languages contributing to greater security. Knowing assembly language, or even a higher level “portable assembly” language such as C, helps the programmer wrap his brain around the concepts of von Neumann architecture computation. Even if you write all your software in a very high level language like Ruby, knowing what’s going on “under the hood”, as it were, can yield great rewards when some careful, precise tinkering is necessary — and in understanding the implications of what you’re doing with all those high level language constructs. This applies to security implications as much as to performance, portability, and stability implications.
Don’t take anything said here as dissuading you from learning lower level, static languages such as C or assembly. Even if you never use them in earnest, knowing these languages will help you really understand what you’re doing with higher level, dynamic languages, and may help you make your code more secure.
On the other hand, high level dynamic languages such as Ruby provide a lot of time saving linguistic constructs that, often as a happy accident, actually improve the security of your code without any effort on your part. An example is “bignum” handling.
In programming languages such as C, integers have limits to how big they can get. For instance, an unsigned integer variable might be limited to 16 bits — between 0 and 216-1 (i.e. 0 to 65535). In unsigned 16 bit integer arithmetic, usually 65535 + 1 = 0, because the short integer type is incapable of representing a numeric value outside the range of 0-65535. In some cases, trying to stick a larger value than a data type can handle into a variable of that data type can crash the program, provide improper access to memory, or cause any of a number of other potential security issues. For this reason, programmers in languages like C need to be careful about how they use limited precision data types.
Arbitrary precision arithmetic, also known as “bignum arithmetic”, is an arithmetic technique implemented in a programming language whereby the extent of an integer’s value is limited only by the restrictions of the hardware itself — essentially, by how much RAM the system has. This can, for instance, take the form of an automatic extension of the value that can be handled by the data type as it is needed, rather than limiting the value to an extent defined before a value is entered into a variable or otherwise handled by the program. As this greatly reduces the inherent danger of accepting overly large inputs, bignum arithmetic can prove a great boon to the security of a program.
Such arbitrary precision arithmetic capabilities can be had with languages such as C, via libraries like BigDigits, the GNU MPL, and CLN, but this is not the default behavior of the language and requires explicit use by the programmer. Languages such as Ruby, on the other hand, employ bignum arithmetic by default, as it is needed, without requiring any intervention on the part of the programmer to specify that extensibility of the values that can be handled by numeric data types. It’s important to understand concepts like fixed integer arithmetic, of course, but it’s not important to use it all the time — or even most of the time.
There are programmers who would complain at this implication, because arbitrary precision arithmetic generally imposes an efficiency penalty on programs that make use of it. In most cases, however, such concerns constitute a case of Knuth’s “premature optimization”, because unnecessary use of fixed precision arithmetic can lead to surprising behavior from your software if you make a mistake in development and some unexpected input overflows an integer.
For security purposes, it’s generally the case that Ruby’s way of doing this is the right way to do it: default to avoiding the all too common dangers of fixed precision arithmetic altogether. The only fly in the ointment is the rare occasion where the performance penalties of arbitrary precision arithmetic really matters — or the rare field of endeavor where it matters often.
When the importance of a nanosecond improvement in runtime is not needed, choose the tools that will make it easy to write more secure code.
Five ways to show business value of M-F authentication
There’s more to selecting an enterprise second-factor authentication method than meets the retina scanner. As with any IT project, each dollar spent must produce business value. With M-F authentication, this translates to value beyond simply verifying an employee’s identity.
Too often, security professionals are mesmerized by regulatory or best practice multi-factor (M-F) authentication mantras. They don’t see that selling M-F solutions to management requires more than a strategically placed HIPAA, SOX, or CoBIT two-by-four. Besides, using regulatory requirements to squeeze additional security dollars out of the IT budget is an argument with diminishing returns.
There are five basic characteristics of an M-F solution that affect its potential for showing business value: an acceptable probability of success in verifying identity, easy enrollment, enhanced productivity, enables single sign on (SSO), and user acceptance.
1. Achieves business-defined probability of success in verifying identity – This is the obvious function of an M-F solution. It should supplement the primary authentication method, usually password-based, by meeting a business-defined threshold for positive verification.Expecting an M-F method to produce 100 percent accuracy is the first mistake of many security managers. Even the effectiveness of finger-print recognition is determined by its error rate. Unless you’re guarding the crown jewels or defense department secrets, the cost of solutions that achieve zero errors is usually higher than necessary to achieve reasonable and appropriate protection. The level of success necessary depends on the strength of your passwords, business tolerance for risk, and the existence and effectiveness of other access controls.
2. Easy enrollment – Enrollment should take less than two minutes and be easily integrated into the new-hire process. Presenting a solution to management that requires employees to juggle three balls while whistling Dixie is not going to help your cause. For example, I just looked at a solution last week that required users to answer over 60 questions to get set up. The solution, currently an academic exercise only, achieved a probability of success that was high enough, but enrollment challenges make it almost impossible to gain management acceptance.
3. Enhances productivity – The user experience should be improved, eliminating existing authentication challenges that go beyond regulatory compliance. In fact, selling a solution to management might require demonstrating how it can solve other issues. For example, many health care organizations deploy shared computers to nurses stations. Several nurses use these devices, logging in many times, during each shift. Their ability to provide care might be enhanced by an M-F solution that quickly verifies their identity and performs fast user switching, eliminating lost time dealing with system authentication issues. Proximity detection can make this happen before the nurse even gets to the keyboard.Another enhancement is SSO-like functionality. Although users have to authenticate to each application, the use of M-F technology can often eliminate the need to enter a user ID and password every time.
4. Enables SSO – The M-F solution should be compatible with future SSO implementations. Selecting an M-F technology without considering SSO is a big mistake. The cost of M-F solutions can be high, and ripping it out if it isn’t compatible with the SSO technology you choose is a career-limiting exercise. According to Forrester, the best approach is selecting an SSO solution first, even if implementation is two to three years in the future. Implementation of an M-F solution should be within the context of your SSO vision. Share that vision with management, positioning your biometrics or smart-card solution as an incremental step toward an improved user experience.
5. Acceptable to users – The solution must be easy to use and actually improve the way users see the security that protects information assets. Nothing kills an M-F rollout faster than user revolt. User resistance is often based on one or more of the following,
- Fear that the company stores unique personal information
- Fear that the company is collecting personal health information (retinal scans look at patterns that are also used to determine certain health conditions) for insurance purposes
- Fear that the red light in retinal scanning sensors is physically harmful
- Fear of contracting diseases through contact with publicly used sensors
- High error rate, without an easy alternative to logging in
The first four bullets under the fifth business value characteristic can be assuaged with pre-rollout discussions with users or user representatives, helping them understand the actual facts about the M-F technology selected. The last item is a technology challenge.
As I wrote early in this post, M-F technology isn’t perfect. There will be errors. One error that frustrates users is a rejection of authorized login attempts. Frustration levels can be controlled by ensuring your solution includes an easy way to deal with these issues as they arise. Remember, this is supposed to improve user experience
Too often, security professionals are mesmerized by regulatory or best practice multi-factor (M-F) authentication mantras. They don’t see that selling M-F solutions to management requires more than a strategically placed HIPAA, SOX, or CoBIT two-by-four. Besides, using regulatory requirements to squeeze additional security dollars out of the IT budget is an argument with diminishing returns.
There are five basic characteristics of an M-F solution that affect its potential for showing business value: an acceptable probability of success in verifying identity, easy enrollment, enhanced productivity, enables single sign on (SSO), and user acceptance.
1. Achieves business-defined probability of success in verifying identity – This is the obvious function of an M-F solution. It should supplement the primary authentication method, usually password-based, by meeting a business-defined threshold for positive verification.Expecting an M-F method to produce 100 percent accuracy is the first mistake of many security managers. Even the effectiveness of finger-print recognition is determined by its error rate. Unless you’re guarding the crown jewels or defense department secrets, the cost of solutions that achieve zero errors is usually higher than necessary to achieve reasonable and appropriate protection. The level of success necessary depends on the strength of your passwords, business tolerance for risk, and the existence and effectiveness of other access controls.
2. Easy enrollment – Enrollment should take less than two minutes and be easily integrated into the new-hire process. Presenting a solution to management that requires employees to juggle three balls while whistling Dixie is not going to help your cause. For example, I just looked at a solution last week that required users to answer over 60 questions to get set up. The solution, currently an academic exercise only, achieved a probability of success that was high enough, but enrollment challenges make it almost impossible to gain management acceptance.
3. Enhances productivity – The user experience should be improved, eliminating existing authentication challenges that go beyond regulatory compliance. In fact, selling a solution to management might require demonstrating how it can solve other issues. For example, many health care organizations deploy shared computers to nurses stations. Several nurses use these devices, logging in many times, during each shift. Their ability to provide care might be enhanced by an M-F solution that quickly verifies their identity and performs fast user switching, eliminating lost time dealing with system authentication issues. Proximity detection can make this happen before the nurse even gets to the keyboard.Another enhancement is SSO-like functionality. Although users have to authenticate to each application, the use of M-F technology can often eliminate the need to enter a user ID and password every time.
4. Enables SSO – The M-F solution should be compatible with future SSO implementations. Selecting an M-F technology without considering SSO is a big mistake. The cost of M-F solutions can be high, and ripping it out if it isn’t compatible with the SSO technology you choose is a career-limiting exercise. According to Forrester, the best approach is selecting an SSO solution first, even if implementation is two to three years in the future. Implementation of an M-F solution should be within the context of your SSO vision. Share that vision with management, positioning your biometrics or smart-card solution as an incremental step toward an improved user experience.
5. Acceptable to users – The solution must be easy to use and actually improve the way users see the security that protects information assets. Nothing kills an M-F rollout faster than user revolt. User resistance is often based on one or more of the following,
- Fear that the company stores unique personal information
- Fear that the company is collecting personal health information (retinal scans look at patterns that are also used to determine certain health conditions) for insurance purposes
- Fear that the red light in retinal scanning sensors is physically harmful
- Fear of contracting diseases through contact with publicly used sensors
- High error rate, without an easy alternative to logging in
The first four bullets under the fifth business value characteristic can be assuaged with pre-rollout discussions with users or user representatives, helping them understand the actual facts about the M-F technology selected. The last item is a technology challenge.
As I wrote early in this post, M-F technology isn’t perfect. There will be errors. One error that frustrates users is a rejection of authorized login attempts. Frustration levels can be controlled by ensuring your solution includes an easy way to deal with these issues as they arise. Remember, this is supposed to improve user experience
Use tcpdump for traffic analysis
The tcpdump tool is an old mainstay of network debugging and security monitoring, and security experts all over the world swear by its usefulness. It is a command line tool that eschews all the makeup and jewelry of other traffic analysis tools such as Ettercap and Wireshark, both of which provide packet sniffing functionality with a convenient captive interface. In contrast to such tools, tcpdump takes a command at the shell, with options specified at that time, and dumps the results to standard output. This may seem primitive to some users, but it provides power and flexibility that isn’t available with the common captive interface alternatives.
Options
The tcpdump utility provides dozens of options, but I’ll just cover a few of them here:
-A: Print each packet in ASCII.
-c N: Where the letter N is a number, this option tells tcpdump to exit after N packets.
-i interface: Capture packets on the specified network interface.
-n: Don’t resolve addresses to names.
-q: Provide less verbose (”quiet”) output so output lines are shorter.
-r filename: Read packets from the specified file rather than a network interface. This is usually used after raw packets have been logged to a file with the -w option.
-t: Don’t print a timestamp on each line of output.
-v: Provide more verbose output. Verbosity can be increased more with -vv, and even more than that with -vvv.
-w filename: Write raw packets to the specified file.
Expressions
The tcpdump utility also supports command-line expressions, used to define filtering rules so that you get exactly the traffic you want to see, ignoring “uninteresting” packets. Expressions consist of a number of primitives and, optionally, modifier terms. The following primitives and modifiers do not constitute a comprehensive list, but they are among the most commonly useful.
Primitives
dst foo: Specify an address or hostname to limit captured packets to traffic sent to a particular host.
host foo: Specify an address or hostname to limit captured packets to traffic to and from a particular host.
net foo: Specify a network or network segment using CIDR notation to limit packet capture.
proto foo: Specify a protocol to limit captured packets to network traffic using that protocol.
src foo: Specify an address or hostname to limit captured packets to traffic sent by a particular host.
Modifiers
and: Use this to chain together primitives when you want to limit captured packets to those that meet the requirements of the expressions on both sides of the and.
not: Use this modifier just before a primitive when you want to limit captured packets to those that do not meet the requirements of the following expresssion.
or: Use this to chain together primitives when you want to limit captured packets to those that meet the requirements of one or more of the expressions on either side of the or.
Examples
All of these options and expression primitives and modifiers, along with others listed in the tcpdump manpage, can be used to construct very specific commands that produce very precise output.
tcpdump -c 50 dst foo can give you information that may help identify the source of heavy incoming traffic targeting an overloaded server with hostname “foo”, dumping the first 50 packets as output.
tcpdump -c 500 -w `date +"%Y%j%T"`.log dumps 500 packets to a file named with a current time/date stamp (e.g. 200820715:16:31.log) so that they can later be filtered according to the information you want to see. I have the command date +"%Y %j%T" aliased to stamp in my shell’s rc file, so I can shorten a command like this to tcpdump -c 500 -w `stamp`.log, saving me from having to remember all the formatting options for the date command off the top of my head.
tcpdump proto ssh src or dst foo and src and dst not bar produces ongoing output that shows all SSH activity originating from or targeting host “foo” unless it is originating from or targeting host “bar”. If foo is only supposed to be accessed via SSH by bar, this command will allow ongoing monitoring of unauthorized SSH traffic to and from foo. You could even start a number of persistent monitoring processes with tcpdump like this within a tmux session on a dedicated monitoring server.
As you can no doubt see, tcpdump’s expressions capabilities are roughly equivalent to a simple domain specific programming language that is extremely easy to understand. With that kind of power and flexibility at my fingertips, there’s little need to use anything else for general traffic analysis tasks.
Options
The tcpdump utility provides dozens of options, but I’ll just cover a few of them here:
-A: Print each packet in ASCII.
-c N: Where the letter N is a number, this option tells tcpdump to exit after N packets.
-i interface: Capture packets on the specified network interface.
-n: Don’t resolve addresses to names.
-q: Provide less verbose (”quiet”) output so output lines are shorter.
-r filename: Read packets from the specified file rather than a network interface. This is usually used after raw packets have been logged to a file with the -w option.
-t: Don’t print a timestamp on each line of output.
-v: Provide more verbose output. Verbosity can be increased more with -vv, and even more than that with -vvv.
-w filename: Write raw packets to the specified file.
Expressions
The tcpdump utility also supports command-line expressions, used to define filtering rules so that you get exactly the traffic you want to see, ignoring “uninteresting” packets. Expressions consist of a number of primitives and, optionally, modifier terms. The following primitives and modifiers do not constitute a comprehensive list, but they are among the most commonly useful.
Primitives
dst foo: Specify an address or hostname to limit captured packets to traffic sent to a particular host.
host foo: Specify an address or hostname to limit captured packets to traffic to and from a particular host.
net foo: Specify a network or network segment using CIDR notation to limit packet capture.
proto foo: Specify a protocol to limit captured packets to network traffic using that protocol.
src foo: Specify an address or hostname to limit captured packets to traffic sent by a particular host.
Modifiers
and: Use this to chain together primitives when you want to limit captured packets to those that meet the requirements of the expressions on both sides of the and.
not: Use this modifier just before a primitive when you want to limit captured packets to those that do not meet the requirements of the following expresssion.
or: Use this to chain together primitives when you want to limit captured packets to those that meet the requirements of one or more of the expressions on either side of the or.
Examples
All of these options and expression primitives and modifiers, along with others listed in the tcpdump manpage, can be used to construct very specific commands that produce very precise output.
tcpdump -c 50 dst foo can give you information that may help identify the source of heavy incoming traffic targeting an overloaded server with hostname “foo”, dumping the first 50 packets as output.
tcpdump -c 500 -w `date +"%Y%j%T"`.log dumps 500 packets to a file named with a current time/date stamp (e.g. 200820715:16:31.log) so that they can later be filtered according to the information you want to see. I have the command date +"%Y %j%T" aliased to stamp in my shell’s rc file, so I can shorten a command like this to tcpdump -c 500 -w `stamp`.log, saving me from having to remember all the formatting options for the date command off the top of my head.
tcpdump proto ssh src or dst foo and src and dst not bar produces ongoing output that shows all SSH activity originating from or targeting host “foo” unless it is originating from or targeting host “bar”. If foo is only supposed to be accessed via SSH by bar, this command will allow ongoing monitoring of unauthorized SSH traffic to and from foo. You could even start a number of persistent monitoring processes with tcpdump like this within a tmux session on a dedicated monitoring server.
As you can no doubt see, tcpdump’s expressions capabilities are roughly equivalent to a simple domain specific programming language that is extremely easy to understand. With that kind of power and flexibility at my fingertips, there’s little need to use anything else for general traffic analysis tasks.
Subscribe to:
Posts (Atom)