Explain these Firewall Alerts to me?

Next from the bottom, that is a rejected PING. Someong PINGed you, and your firewall does not issue the ICMP reply that PING uses. You will always see these. YOu just need to watch out for PING of Death, where someone tries to PING your firewall so much with so many large packets that your firewall can't keep up and it goes offline.

Next, the TCP Null scan:

"NULL scanning

Clearly through it's endowed named, the NULL scan unsets ALL flags available in
the TCP header. ACK, FIN, RST, SYN, URG, PSH all become unassigned. The reserved
bits (RES1, RES2) actually do not effect the result of any scan, whether or not
they are set clearly does not matter. On arrival of this packet to the server,
BSD networking code informs the kernel to drop the incoming call if the port is
open.

client -> NULL (no flags)server -> -

Alternatively, an RST packet will be returned if a closed port has been reached
(yes another inverse mapped scan).

client -> NULL (no flags)
server -> RST

Owing to the fact that the RFC does not exclaim exactly how a host should
respond to these types of packets, various network code for the major operating
systems will differ in the packet responses, ie Microsoft vs UNIX.

Advantages : avoids IDS, avoids TCP three-way handshake
Disadvantages: UNIX only, false positives"

Last, the FIN scan:

"FIN scanning

The FIN scan method uses inverse mapping to discover closed ports.
Unfortunately, this techniques relies on bad BSD network code which most
operating systems have based their TCP/IP stacks on (all the better for
scanning). Ideally, once a FIN flagged packet is sent, a closed port will resend
with an RST bit. Open ports, alternatively will not send a packet back,
therefore what precisely is not answered with theFIN bit, is assumed to be open
through this process of inverse mapping.

Take a look at the negotiation for open/closed port recognition displayed below.

client -> FIN
server -> -

No reply signaled by the server is iconic of an open port. The server's
operating system silently dropped the incoming FIN packet to the service running
on that port. Opposing this is the RST reply by the server upon a closed port
reached. Since, no service is bound on that port, issuing a FIN invokes a reset
(RST) response from the server.

client -> FIN
server -> RST

Part 2 of FIN scan:

"Arguably there are two ways to test for an open port. The first is receiving a
list of closed port responses and subtracting these port replies from a list of
the port probes originally sent. For example, sending 3 packets to ports 1, 2, 3
on a remote host.

If the response back is an RST for ports 1 and 3, we then compare the original
port list: 1, 2, 3 to the received ports: 1, 3 and deduce that 2 is the open
port via comparison.

The second test involves using a timeout for the packet response. If the timeout
limit is reached to receive the packet in question then we assume it to be open.
Obviously, this method is test for false positives and should be avoided where
possible. The responsesfor the packet could be obscured because of firewalls,
filters, routers, slow links, and heavy traffic, thus is not a solid test to be
used as a rule of thumb for stealth FIN scanning.

Advantages : avoids many IDS, avoids TCP three-way handshake
Disadvantages: slow false positives"

The FIN and NULL scan definitions came from:
http://www.synnergy.net/downloads/papers/portscan.txt

Poster rated this answer