- •Network Intrusion Detection, Third Edition
- •Table of Contents
- •Copyright
- •About the Authors
- •About the Technical Reviewers
- •Acknowledgments
- •Tell Us What You Think
- •Introduction
- •Chapter 1. IP Concepts
- •Layers
- •Data Flow
- •Packaging (Beyond Paper or Plastic)
- •Bits, Bytes, and Packets
- •Encapsulation Revisited
- •Interpretation of the Layers
- •Addresses
- •Physical Addresses, Media Access Controller Addresses
- •Logical Addresses, IP Addresses
- •Subnet Masks
- •Service Ports
- •IP Protocols
- •Domain Name System
- •Routing: How You Get There from Here
- •Summary
- •Chapter 2. Introduction to TCPdump and TCP
- •TCPdump
- •TCPdump Behavior
- •Filters
- •Binary Collection
- •TCPdump Output
- •Absolute and Relative Sequence Numbers
- •Dumping in Hexadecimal
- •Introduction to TCP
- •Establishing a TCP Connection
- •Server and Client Ports
- •Connection Termination
- •The Graceful Method
- •The Abrupt Method
- •Data Transfer
- •What's the Bottom Line?
- •TCP Gone Awry
- •An ACK Scan
- •A Telnet Scan?
- •TCP Session Hijacking
- •Summary
- •Chapter 3. Fragmentation
- •Theory of Fragmentation
- •All Aboard the Fragment Train
- •The Fragment Dining Car
- •The Fragment Caboose
- •Viewing Fragmentation Using TCPdump
- •Fragmentation and Packet-Filtering Devices
- •The Don't Fragment Flag
- •Malicious Fragmentation
- •TCP Header Fragments
- •Teardrop
- •Summary
- •Chapter 4. ICMP
- •ICMP Theory
- •Why Do You Need ICMP?
- •Where Does ICMP Fit In?
- •Understanding ICMP
- •Summary of ICMP Theory
- •Mapping Techniques
- •Tireless Mapper
- •Efficient Mapper
- •Clever Mapper
- •Cerebral Mapper
- •Summary of Mapping
- •Normal ICMP Activity
- •Host Unreachable
- •Port Unreachable
- •Admin Prohibited
- •Need to Frag
- •Time Exceeded In-Transit
- •Embedded Information in ICMP Error Messages
- •Summary of Normal ICMP
- •Malicious ICMP Activity
- •Smurf Attack
- •Tribe Flood Network
- •WinFreeze
- •Loki
- •Unsolicited ICMP Echo Replies
- •Theory 1: Spoofing
- •Theory 2: TFN
- •Theory 3: Loki
- •Summary of Malicious ICMP Traffic
- •To Block or Not to Block
- •Unrequited ICMP Echo Requests
- •Kiss traceroute Goodbye
- •Silence of the LANs
- •Broken Path MTU Discovery
- •Summary
- •Chapter 5. Stimulus and Response
- •The Expected
- •Request for Comments
- •TCP Stimulus-Response
- •Destination Host Listens on Requested Port
- •Destination Host Not Listening on Requested Port
- •Destination Host Doesn't Exist
- •Destination Port Blocked
- •Destination Port Blocked, Router Doesn't Respond
- •UDP Stimulus-Response
- •Destination Host Listening on Requested Port
- •Destination Host Not Listening on Requested Port
- •Windows tracert
- •TCPdump of tracert
- •Protocol Benders
- •Active FTP
- •Passive FTP
- •UNIX Traceroute
- •Summary of Expected Behavior and Protocol Benders
- •Abnormal Stimuli
- •Evasion Stimulus, Lack of Response
- •Evil Stimulus, Fatal Response
- •No Stimulus, All Response
- •Unconventional Stimulus, Operating System Identifying Response
- •Bogus "Reserved" TCP Flags
- •Anomalous TCP Flag Combinations
- •No TCP Flags
- •Summary of Abnormal Stimuli
- •Summary
- •Chapter 6. DNS
- •Back to Basics: DNS Theory
- •The Structure of DNS
- •Steppin' Out on the Internet
- •DNS Resolution Process
- •TCPdump Output of Resolution
- •Strange TCPdump Notation
- •Caching: Been There, Done That
- •Reverse Lookups
- •Master and Slave Name Servers
- •Zone Transfers
- •Summary of DNS Theory
- •Using DNS for Reconnaissance
- •The nslookup Command
- •Name That Name Server
- •HINFO: Snooping for Details
- •List Zone Map Information
- •Tainting DNS Responses
- •A Weak Link
- •Cache Poisoning
- •Summary
- •Part II: Traffic Analysis
- •Chapter 7. Packet Dissection Using TCPdump
- •Why Learn to Do Packet Dissection?
- •Sidestep DNS Queries
- •Normal Query
- •Evasive Query
- •Introduction to Packet Dissection Using TCPdump
- •Where Does the IP Stop and the Embedded Protocol Begin?
- •Other Length Fields
- •The IP Datagram Length
- •Increasing the Snaplen
- •Dissecting the Whole Packet
- •Freeware Tools for Packet Dissection
- •Ethereal
- •tcpshow
- •Summary
- •Chapter 8. Examining IP Header Fields
- •Insertion and Evasion Attacks
- •Insertion Attacks
- •Evasion Attacks
- •IP Header Fields
- •IP Version Number
- •Protocol Number
- •The Don't Fragment (DF) Flag
- •The More Fragments (MF) Flag
- •Mapping Using Incomplete Fragments
- •IP Numbers
- •IP Identification Number
- •Time to Live (TTL)
- •Looking at the IP ID and TTL Values Together to Discover Spoofing
- •IP Checksums
- •Summary
- •Chapter 9. Examining Embedded Protocol Header Fields
- •Ports
- •TCP Checksums
- •TCP Sequence Numbers
- •Acknowledgement Numbers
- •TCP Flags
- •TCP Corruption
- •ECN Flag Bits
- •Operating System Fingerprinting
- •Retransmissions
- •Using Retransmissions Against a Hostile Host—LaBrea Tarpit Version 1
- •TCP Window Size
- •LaBrea Version 2
- •Ports
- •UDP Port Scanning
- •UDP Length Field
- •ICMP
- •Type and Code
- •Identification and Sequence Numbers
- •Misuse of ICMP Identification and Sequence Numbers
- •Summary
- •Chapter 10. Real-World Analysis
- •You've Been Hacked!
- •Netbus Scan
- •How Slow Can you Go?
- •RingZero Worm
- •Summary
- •Chapter 11. Mystery Traffic
- •The Event in a Nutshell
- •The Traffic
- •DDoS or Scan
- •Source Hosts
- •Destination Hosts
- •Scanning Rates
- •Fingerprinting Participant Hosts
- •Arriving TTL Values
- •TCP Window Size
- •TCP Options
- •TCP Retries
- •Summary
- •Part III: Filters/Rules for Network Monitoring
- •Chapter 12. Writing TCPdump Filters
- •The Mechanics of Writing TCPdump Filters
- •Bit Masking
- •Preserving and Discarding Individual Bits
- •Creating the Mask
- •Putting It All Together
- •TCPdump IP Filters
- •Detecting Traffic to the Broadcast Addresses
- •Detecting Fragmentation
- •TCPdump UDP Filters
- •TCPdump TCP Filters
- •Filters for Examining TCP Flags
- •Detecting Data on SYN Connections
- •Summary
- •Chapter 13. Introduction to Snort and Snort Rules
- •An Overview of Running Snort
- •Snort Rules
- •Snort Rule Anatomy
- •Rule Header Fields
- •The Action Field
- •The Protocol Field
- •The Source and Destination IP Address Fields
- •The Source and Destination Port Field
- •Direction Indicator
- •Summary
- •Chapter 14. Snort Rules - Part II
- •Format of Snort Options
- •Rule Options
- •Msg Option
- •Logto Option
- •Ttl Option
- •Id Option
- •Dsize Option
- •Sequence Option
- •Acknowledgement Option
- •Itype and Icode Options
- •Flags Option
- •Content Option
- •Offset Option
- •Depth Option
- •Nocase Option
- •Regex Option
- •Session Option
- •Resp Option
- •Tag Option
- •Putting It All Together
- •Summary
- •Part IV: Intrusion Infrastructure
- •Chapter 15. Mitnick Attack
- •Exploiting TCP
- •IP Weaknesses
- •SYN Flooding
- •Covering His Tracks
- •Identifying Trust Relationships
- •Examining Network Traces
- •Setting Up the System Compromise?
- •Detecting the Mitnick Attack
- •Trust Relationship
- •Port Scan
- •Host Scan
- •Connections to Dangerous Ports
- •TCP Wrappers
- •Tripwire
- •Preventing the Mitnick Attack
- •Summary
- •Chapter 16. Architectural Issues
- •Events of Interest
- •Limits to Observation
- •Human Factors Limit Detects
- •Limitations Caused by the Analyst
- •Limitations Caused by the CIRTs
- •Severity
- •Criticality
- •Lethality
- •Countermeasures
- •Calculating Severity
- •Scanning for Trojans
- •Analysis
- •Severity
- •Host Scan Against FTP
- •Analysis
- •Severity
- •Sensor Placement
- •Outside Firewall
- •Sensors Inside Firewall
- •Both Inside and Outside Firewall
- •Analyst Console
- •Faster Console
- •False Positive Management
- •Display Filters
- •Mark as Analyzed
- •Drill Down
- •Correlation
- •Better Reporting
- •Event-Detection Reports
- •Weekly/Monthly Summary Reports
- •Summary
- •Chapter 17. Organizational Issues
- •Organizational Security Model
- •Security Policy
- •Industry Practice for Due Care
- •Security Infrastructure
- •Implementing Priority Countermeasures
- •Periodic Reviews
- •Implementing Incident Handling
- •Defining Risk
- •Risk
- •Accepting the Risk
- •Trojan Version
- •Malicious Connections
- •Mitigating or Reducing the Risk
- •Network Attack
- •Snatch and Run
- •Transferring the Risk
- •Defining the Threat
- •Recognition of Uncertainty
- •Risk Management Is Dollar Driven
- •How Risky Is a Risk?
- •Quantitative Risk Assessment
- •Qualitative Risk Assessments
- •Why They Don't Work
- •Summary
- •Chapter 18. Automated and Manual Response
- •Automated Response
- •Architectural Issues
- •Response at the Internet Connection
- •Internal Firewalls
- •Host-Based Defenses
- •Throttling
- •Drop Connection
- •Shun
- •Proactive Shunning
- •Islanding
- •Reset
- •Honeypot
- •Proxy System
- •Empty System
- •Honeypot Summary
- •Manual Response
- •Containment
- •Freeze the Scene
- •Sample Fax Form
- •On-Site Containment
- •Site Survey
- •System Containment
- •Hot Search
- •Eradication
- •Recovery
- •Lessons Learned
- •Summary
- •Chapter 19. Business Case for Intrusion Detection
- •Part One: Management Issues
- •Bang for the Buck
- •The Expenditure Is Finite
- •Technology Used to Destabilize
- •Network Impacts
- •IDS Behavioral Modification
- •The Policy
- •Part of a Larger Strategy
- •Part Two: Threats and Vulnerabilities
- •Threat Assessment and Analysis
- •Threat Vectors
- •Threat Determination
- •Asset Identification
- •Valuation
- •Vulnerability Analysis
- •Risk Evaluation
- •Part Three: Tradeoffs and Recommended Solution
- •Identify What Is in Place
- •Identify Your Recommendations
- •Identify Options for Countermeasures
- •Cost-Benefit Analysis
- •Follow-On Steps
- •Repeat the Executive Summary
- •Summary
- •Chapter 20. Future Directions
- •Increasing Threat
- •Improved Targeting
- •How the Threat Will Be Manifested
- •Defending Against the Threat
- •Skills Versus Tools
- •Analysts Skill Set
- •Improved Tools
- •Defense in Depth
- •Emerging Techniques
- •Virus Industry Revisited
- •Smart Auditors
- •Summary
- •Part V: Appendixes
- •Appendix A. Exploits and Scans to Apply Exploits
- •False Positives
- •All Response, No Stimulus
- •Scan or Response?
- •SYN Floods
- •Valid SYN Flood
- •False Positive SYN Flood
- •Back Orifice?
- •IMAP Exploits
- •10143 Signature Source Port IMAP
- •111 Signature IMAP
- •Source Port 0, SYN and FIN Set
- •Source Port 65535 and SYN FIN Set
- •DNS Zone Followed by 0, SYN FIN Targeting NFS
- •Scans to Apply Exploits
- •mscan
- •Son of mscan
- •Access Builder?
- •Single Exploit, Portmap
- •rexec
- •Targeting SGI Systems?
- •Discard
- •Weird Web Scans
- •IP-Proto-191
- •Summary
- •Appendix B. Denial of Service
- •Brute-Force Denial-of-Service Traces
- •Smurf
- •Directed Broadcast
- •Echo-Chargen
- •Elegant Kills
- •Teardrop
- •Land Attack
- •We're Doomed
- •nmap
- •Distributed Denial-of-Service Attacks
- •Intro to DDoS
- •DDoS Software
- •Trinoo
- •Stacheldraht
- •Summary
- •Appendix C. Detection of Intelligence Gathering
- •Network and Host Mapping
- •Host Scan Using UDP Echo Requests
- •Netmask-Based Broadcasts
- •Port Scan
- •Scanning for a Particular Port
- •Complex Script, Possible Compromise
- •"Random" Port Scan
- •Database Correlation Report
- •SNMP/ICMP
- •FTP Bounce
- •NetBIOS-Specific Traces
- •A Visit from a Web Server
- •Null Session
- •Stealth Attacks
- •Explicit Stealth Mapping Techniques
- •FIN Scan
- •Inverse Mapping
- •Answers to Domain Queries
- •Answers to Domain Queries, Part 2
- •Fragments, Just Fragments
- •Measuring Response Time
- •Echo Requests
- •Actual DNS Queries
- •Probe on UDP Port 33434
- •3DNS to TCP Port 53
- •Worms as Information Gatherers
- •Pretty Park Worm
- •RingZero
- •Summary
00:32:50.286098 192.168.4.5 > prober: icmp:192.168.8.255 unreach
What is the origin of the ip-proto-191 notation? TCPdump tries to figure out the IP protocol by looking at the appropriate field in the IP header. TCPdump knows the common protocol translations. If it finds a 1 in this field, it labels it as ICMP in the output—6 is TCP, and 17 is UDP. If it is not a protocol that it knows about, however, it uses the ip-proto notation with the number that it discovered in the protocol field.
The preceding output also shows a response from 192.168.4.5. This response, in itself, supplies some reconnaissance about the network. Even if you do not get a protocol unreachable, you still have every chance of seeing a host unreachable.
Summary
Analysts make many common mistakes. These include SYN floods, misconfigured networks, and being too quick to match a signature. If possible, try to avoid sending false positives to your CIRT.
Some of the tricks attackers are using for either stealth or better penetration, such as setting both the SYN and FIN flag, allow these packets to be trivially detected.
Appendix B. Denial of Service
In February 2000, denial-of-service attacks were the hot topic. With a network of more than 2,000 compromised systems, most of them via a DNS buffer overflow, attackers shut down major high-profile Internet sites such as CNN and eBay. Although the end of this chapter covers these attacks, they are the exception and not the rule for denial of service. In general, denial-of- service attacks groan on and on, doing little harm besides wasting people's time and bandwidth and occasionally crashing a system. In the vast majority of these attacks, the source address is faked or "spoofed." Please be very slow to phone the owners of the address space that you think just hit you with a denial of service and read them the riot act! One day it might be your address that is spoofed. This is a short chapter divided into two sections. The first section deals with denial-of-service brute-force attacks that are widespread and regularly detected even if they are not all that well known. The second section includes additional well-known attacks, but these are more elegant; in fact, they tend to be one-packet kills—that is, a single attacker packet that can freeze or shut down a system.
Brute-Force Denial-of-Service Traces
These brute-force patterns have reached a point that they are known by almost all Internet institutions. The curious thing is that I still find sites and systems vulnerable to these attacks.
Keep in mind that one of the characteristics of many of the denial-of-service attacks is that the attacker can use one of your systems to cause harm to someone else. The fixes are well published and well understood; please implement them. Only you can prevent SYN floods, UDP
floods, Smurf, and Echo-Chargen!
Smurf
The Smurf attack has no effect except to consume bandwidth. The most important thing to consider with regard to the effectiveness of Smurf is that for your site's Internet connection to run smoothly, you depend on the security policy of other people's sites. This is a very old
attack, but you still see it deployed with the most current attack tools. Smurf is still deployed for exactly one reason: It still works. In the following case, spoofed.pound.me.net almost
certainly did not really send the echo request to 192.168.1.255. Instead, an outside computer interjects this into the network, as shown in Figure B.1. The poor spoofed addressee will potentially get hit with a large number of ICMP echo replies. If spoofed is on a slow Internet connection, this might be harmful; and if a large number of hosts reply to the Smurf, damage can be done to fast networks.
Figure B.1. ICMP denial of service.
Cisco published the following field notice titled "Minimizing the Effects of 'Smurfing' Denial of Service Attacks." The following quotation is from that document:
A Scenario: Assume a co-location switched network with 100 hosts, and that the attacker has a T1. The attacker sends, for example, a 768 kbps stream of ICMP echo (ping) packets, with a spoofed source address of the victim, to the broadcast address of the "bounce site." These ping packets hit the bounce site's broadcast network of 100 hosts. Each of them takes the packet and responds to it, creating 100 ping replies outbound. By multiplying the bandwidth, you see that 76.8 Mbps is used outbound from the "bounce site" after the traffic is multiplied. This is then sent to the victim (the spoofed source of the originating packets).1
1www.cisco.com/warp/public/707/5.html
I chose to reference a Cisco technical manual because Cisco routers—the most widely deployed routers in the world—are one of the primary keys to eliminating Smurf attacks. Let's examine
how the attack works and then the countermeasures:
00:00:05.327 spoofed.pound.me.net > 192.168.15.255: icmp: echo request 00:00:05.342 spoofed.pound.me.net > 192.168.1.255: icmp: echo request 00:00:14.154 spoofed.pound.me.net > 192.168.15.255: icmp: echo request
00:00:14.171 spoofed.pound.me.net > 192.168.1.255: icmp: echo request 00:00:19.055 spoofed.pound.me.net > 192.168.15.255: icmp: echo request 00:00:19.073 spoofed.pound.me.net > 192.168.1.255: icmp: echo request 00:00:23.873 spoofed.pound.me.net > 192.168.15.255: icmp: echo request
All for One
Many denial-of-service attacks and network-mapping probes use broadcasts, packets addressed to all members of a network, to accomplish their purposes. RFC 919 sets several standards for broadcasts, including the rule that 255.255.255.255 must not be forwarded by a router or routing host.
How did 255.255.255.255 come to be? The local network layer can always map an IP address into a data link layer address. Think about switched networks—that is exactly how they work. So, the choice of an IP "broadcast host number" is somewhat arbitrary. Something needed to be selected, and it seemed reasonable that it should be one that was not likely to be assigned to a real host. The number whose bits are all 1s had this property. Keep the idea of all 1s in mind; we will look at patterns where the broadcast is not 255.255.255.255 due to subnet masking, but the all 1s remains true.
The address 255.255.255.255 denotes a broadcast on a local hardware network, which must not be forwarded by a router or routing host. This address might be used, for example, by hosts that do not know their network number and are asking some server for it. A common case of this is a diskless workstation; as it is booting up, it broadcasts a request for help in finding its operating system. Its server hears the request and answers, providing the next step in the boot up process and then the customized files this system needs to do its job.
Therefore, a host on net 36, for example, might do the following:
●Broadcast to all of its immediate neighbors by using 255.255.255.255
●Broadcast to all of net 36 by using 36.255.255.255
(Note that unless the network has been broken up into subnets, these two methods have identical effects.)
If the use of "all 1s" in an octet of an IP address means "broadcast," using "all 0s"
could be viewed as meaning "unspecified." There is probably no reason for such addresses to appear anywhere but as the source address of a bootp. bootp is
one of the protocols used to help diskless systems and routers load their operating systems and configuration files. Although there is a legacy ICMP Information Request datagram, these are obsolete and should not occur in normal traffic. As a notational convention, however, we refer to networks (as opposed to hosts) by using addresses with 0 fields. For example, 36.0.0.0 means "network number 36," whereas 36.255.255.255 means "all hosts on network number 36."2
2 www.library.ucg.ie/Connected/RFC/919/7.htm
Directed Broadcast
If you detect a pattern such as the following 255.255.255.255, the odds are that it was sent as a simple broadcast and has been expanded by your router, as shown here:
1.A packet originally destined for 172.20.4.255 assumes a netmask of 255.255.255.0, the size of a Class C network. This broadcasts to all hosts of the 172.20.4 network.
2.A router, possibly in your organization, has the 172.20.4 interface. When it copies the packet from the Internet and rebuilds it on the 4 interface, it expands the broadcast, thereby referencing all hosts served by that interface. Therefore, it rewrites to broadcast as 255.255.255.255.
In the following trace, the broadcast has been expanded. The all 1s broadcast is as described
earlier, and the legacy all 0s broadcast has been expanded to the network portion of the netmask. Who answers these expanded pings? Every system that hears them! Therefore, one packet coming in from a spoofed address ends up being amplified to hundreds or thousands of packets. Sites that do not block incoming ICMP are known as Smurf amplifiers. You can find a listing of these, including the top 10, at www.powertech.no/smurf or www.netscan.org. (In this case, it is
not a great honor to be in the top 10.) Take a look at the trace: |
icmp: echo request |
05:20:48.261 spoofed.pound.me.net > 192.168.0.0: |
05:20:48.263 spoofed.pound.me.net > 255.255.255.255: icmp: echo request
05:21:35.792 spoofed.pound.me.net > 192.168.0.0: icmp: echo request 05:21:35.819 spoofed.pound.me.net > 255.255.255.255: icmp: echo request
05:22:16.909 spoofed.pound.me.net > 192.168.0.0: icmp: echo request 05:22:16.927 spoofed.pound.me.net > 255.255.255.255: icmp: echo request
05:22:58.046 |
spoofed.pound.me.net |
> |
192.168.0.0: |
icmp: |
echo |
request |
05:22:58.061 |
spoofed.pound.me.net |
> |
255.255.255.255: icmp: |
echo |
request |
In terms of countermeasures, you can build perimeter defenses that are denial-of-service resistant. Instead of connecting a proxy or application gateway firewall directly to your Internet connection, you might want to have a router first. After all, they are more efficient at blocking high-bandwidth attacks simply because they are designed to operate at "wire speeds." You should also block outgoing packets that have a source address not from your network; this is known as egress filtering. You can find examples of egress filtering for a large number of routers and firewalls in the GCFW practical assignments at www.giac.org/cert.php. Many denial-of- service attacks use spoofed source addresses. If you do not let them on the Internet, you are being a good net-neighbor. Needless to say, if one of your systems is sending out spoofed
addresses, that is a clue that this box might have been compromised.
Echo-Chargen
Echo-Chargen is another example of a classic brute-force attack that uses poorly defended sites and poorly configured systems as amplifiers. This attack mostly looks for UNIX systems as amplifiers, so it is not quite as potent as Smurf, which uses any system. You know how they depict the audiences of tennis matches on cartoons? Everybody's head goes back and forth following the ball. This pattern is just like that except that the heads would have to oscillate at just under the speed of light. Echo is UDP port 7; if it receives a packet it echoes back the payload. If you send echo an "a," it replies with an "a."
Chargen (character generator) is UDP port 19. If you send Chargen any characters, it replies with a pseudo random string of characters.
In the following trace, an outsider spoofs a number of connections to various hosts' Chargen ports. The hope here is that they will reply back to the echo port and a game of Echo <--> Chargen ping-pong will begin burning bandwidth and CPU cycles.
You can still detect this in actual use, but it is becoming more rare. You can help make it even more rare. There is no reason to allow packets addressed to these ports through your organization's firewall or filtering router. These services should be commented out of your UNIX
system's inetd.conf files:
08:08:16.155354 spoofed.pound.me.net.echo > 172.31.203.17.chargen: udp 08:21:48.891451 spoofed.pound.me.net.echo > 192.168.14.50.chargen: udp 08:25:12.968929 spoofed.pound.me.net.echo > 192.168.102.3.chargen: udp 08:42:22.605428 spoofed.pound.me.net.echo > 192.168.18.28.chargen: udp 08:47:21.450708 spoofed.pound.me.net.echo > 172.31.130.93.chargen: udp 08:51:27.491458 spoofed.pound.me.net.echo > 172.31.153.78.chargen: udp 08:53:13.530992 spoofed.pound.me.net.echo > 172.31.146.49.chargen: udp
I studied martial arts for many years and eventually became an instructor. Twice a year we would have a black belt test. The school's master would invite other masters to form a panel for the test. Of course, it is customary to bow to these masters, and they bow back. I have a mischievous streak, and from time to time I would bow, they would bow, I would bow again,