http://enworld.cyberstreet.com/showthread.php?threadid=57522
The weird part after the s= is a checksum. So, "af62088b575e7c54f25d0bbc705e8745" is a checksum, or to be more precise, a md5 checksum.
On the Internet, checksums are often used for validation. Say I have a website where you can download a very important document. This document is very, very important, and I don't want people to read it if even a single letter has changed in the transmission. To be sure the visitors download the file exactly as I wrote it, I also provide a checksum generated from the contents of the file. I write the checksum on my webpage.
Then a user downloads the file, and to be sure the file is valid he generates his own checksum from the file. If the two checksums (the one from my website and the one he generated himself) are exactly the same, the file hasn't changed.
On ENWorld, checksums are used to store the passwords in the database (this is really clever because you cannot "reverse engineer" a checksum the same way you can crack an encryption system). Checksums are also used to keep track of sessions (the weird string after the s= in the URL). Sessions are sort of server side cookies and are responsible of keeping track of you while on the website (say, if you are logged in, how long you have been reading and such).
I am not completely sure what NIS complains about, but my guess is that as the session code/checksum regenerates itself on enworld once in a while for no apparent reason (this is something I have only noticed on ENWorld and no other vBulletin forum), and this string is also stored locally in a cookie, the firewall gets angry when the string in the cookie and the string on the website doesn't match.
Edit: Heh, I just noticed that this regenarating thing often happens when you post a reply.
Edit2: So, put enworld on the ignore list in NIS and don't worry about it. I don't think you should.
