Do these two methods accomplish the same thing ?logging host 18.104.22.168 sequence-num-session and service sequence-numbersI was doing a task that asked me to enable protection against syslog message tampering.
Depends upon your perspective [:)]. With both commands in play, the syslog host at 22.214.171.124 would have both the 'global' sequence numbers (via service sequence-numbers) as well as the host-specific sequence numbers (via logging host 126.96.36.199 sequence-num-session). Host specific sequence numbers are incremental tags for each message sent to the specified host, whereas the global sequence numbers are incremental tags for all messages. So, at least as I understand it, if you were filtering traffic to 188.8.131.52 so it only received a subset of syslog messages, there is a distinct possibility that you may see gaps in the global sequence numbers when/where messages were logged (at the device or to a different host) but not to 184.108.40.206.
If you did a 'no logging host 220.127.116.11 sequence-num-session' followed by a 'logging host 18.104.22.168 sequence-num-session', the tags would start over at 1 for subsequent messages logged to host 22.214.171.124, while the global sequence numbers would still be incrementing (don't recall but I believe these 'reset' upon reboot but never start at 000000, but don't quote me on that). This becomes more convoluted when you consider situations involving multiple devices logging to a single host, and the situation then arises that there isn't a unified method of event sequencing. To compound the problem, syslog uses UDP as a transport protocol and hence does not ensure ordered delivery. Timestamps help, esp when using an authoritative source that is sync'd across all devices, but a hacker could conceivably forge timestamps by using the current time in bogus syslog messages.
The sequence numbers, in tandem, aid in overcoming this obstacle in that, even if forged, they'll most likely be out of range/out of sequence/or perchance overlapping. In addition, you could add 'logging message-count' to provide yet another value that would be hard to 'guess' and replay in a forged message without a high probability of being off the mark. So, in pursuit of achieving the task of protecting against syslog message tampering, IMO, you've succeeded, and doubly so by including both commands.
Sample syslog output follows comprised of all three numbering methods discussed above:
<187>225: [[email protected] s_sn="76>: 000573: Mar 8 21:18:11.095: %LINK-3-UPDOWN: Interface FastEthernet0/0/0, changed state to up 126.96.36.199 08/03 13:20:35.521
<187> - PRIORITY field comprised of Facility and Severity; in short, Facility is multiplied by 8 and added to the Severity value to get the value shown between <>. Facility values range from 0-24 and Severity ranges from 0-7. Since Cisco defaults to facility7, corresponding to a decimal value of 23, we multiply by 8 to get 184. 187 - 184 is 3 so the Severity is Error.
225: - Example of logging message-count being enabled
[[email protected] s_sn="76>: - sequence-num-session number, or 76th message generated to this device since the logging host command was entered
000573: - 'global' sequence number generated via 'logging sequence-numbers'
As you can see, while a timestamp may be somewhat vulnerable to forgery assuming a hacker on the same network with access to the same global time source, an attempt at accurately predicting all three sequence values/counters or their ranges is relatively improbable esp when there isn't a discernable relationship between them.