Could this be caused by specifying the DROP target in the rule?
No.
Should I use REJECT instead?
No.
A DROP target on that rule on the INPUT chain will mean that Apache never gets to see the very first SYN packet or any packet at all with that source address. Without establishing a connection, it will never end up in the CLOSE_WAIT state. See the state diagram from Wikipedia below:
As you can see, CLOSE_WAIT only happens after an established session and only on the server if the client initiates closing the session. With KeepAlive, the session stays open until one of the client or the server reaches their timeout and actively closes the session.
It is common for the server to reach this timeout and close the session, leading the server to end up with a lot of connections in the TIME_WAIT state. They will stay in this state for two minutes by default but this will very rarely cause a problem. TIME_WAIT connections (on Linux) tie up a IP/port combination but you won't run out of those until you have about 30,000 connections in the TIME_WAIT state.
The source address range in your rule does not match the IP address in the CLOSE_WAIT state in your example.
REJECT is polite to use for polite people if for some reason you are not able to accept their connections because it allows them to close the connection immediately, but for hackers/spammers there is no need to be polite. Make them wait for whatever timeout they have configured.
So, what can cause connections in the CLOSE_WAIT state? The client sends a FIN, the server responds with a FIN/ACK and then waits for the final ACK. If it never received that final ACK, it's stuck there until something else happens such as restarting Apache.
Bad connection state tracking in other code (such as a hardware firewall) could cause this, as could problems at the client end. I couldn't be sure what's causing your specific problem.