in this case the packets got dropped as “invalid” packets - So they where not matching an active TCP session (and there will and can be the case, there was also a successfull and “good” connection/packets). Details regarding connection tracking you can find on this page: wiki.ipfire.org - Firewall Options
Public connections to all possible (well known services) ports are a common thing - because there are many bots and exploit searching things out there. For some time this logs may be interesting, but on a regular base you will disable logging for blocked incoming connections to have a clean firewall log. (And in case you are looking for something to diagnose, the logging can easily be switched back on)
for the sake of completeness, I think it is important to notice that the firewall logs as displayed in the web interface currently do not show the TCP flags of a packet (such as SYN, SYN-ACK, etc.).
Looking at the web interface, it is important to understand that it shows packets, not connections. To conclude if a packet in question belonged to a connection, and what state the connection had, the TCP flags would be helpful.
They can still be viewed by looking at /var/log/messages directly. I am still unsure if displaying them in the web interface as well would be an overkill for new users, or if the benefit of that would outweigh the disadvantages…