All the companies I have worked at (and I know I am lucky because of this) have had QA that is set up exactly the same as production so I am unsure how common those sorts of bugs are.
Deployments to QA were completed the same way deployments to prod were. If there were deployment scripts the only thing that changed between UAT and PROD were server names.
I would say that bugs in QA are actual bugs with the software and are legitimate. A bug resulting from a configuration error is still a bug (even though a configuration change can fix it). I would keep track of all the bugs that are a result of configuration differences between QA and PROD and then ask management for funds (if needed) or authorization to make changes so that the configuration between QA and PROD is the same. If the environment is set up for every QA test work on the scripts so that it is the same as prod.
By having our QA and PROD set up the same we could try out new configuration changes in QA and see if it would introduce any bugs or cause performance issues. With out QA and PROD matching that would not have been possible.
As for who should set up the QA environment? It has varied from the devops team (responsible for all environments) to the server admins (responsible for all environments). However this will differ for every company.
Do not question the "legitimacy" of bugs. If some one finds a "bug" it means something did not work correctly. If it is because of a configuration issue either fix the configuration issue in QA or handle the issue in code if you expect that configuration issue to be present in PROD. As soon as you start to question the "legitimacy" of bugs things will get missed by QA and some major catastrophy will happen in PROD, Murphy likes to rear his head.