The answer depends on what you are targeting to some extent. If there is an Internet-facing port on the host your scan may be blocked by the firewall responding with resets (RST) which makes your initial scan results look closed or filtered even though that may not be entirely true. Firewalls are designed to make this harder and can block some scans but if at least one port is available for testing you have a very good chance of figuring it out.
That said you will have to focus on information like the type and versions of applications running on the system. Use nmap to focus on the ports that are open and increase verbosity and look at the service versions.
nmap -Pn -vvv -sV -p 80 #(webserver) or
nmap -Pn -vvv -sV -p 22 #(ssh, hopefully on another port)
and you
will see outputs that include lines like
22/tcp open ssh syn-ack OpenSSH 5.9p1 Debian 5ubuntu1.8 (Ubuntu Linux; protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
This can help you identify the host even if general port scanning will not.
Note: you can also take this a step further by analyzing the protocol traffic itself or content available via the applications exposed.
Additionally an nmap FTP bounce scan can also scan other servers behind a firewall:
https://nmap.org/nsedoc/scripts/ftp-bounce.html
nmap -vvv -b -PN :@
-Pn
or-PN
(same thing)? That tells Nmap that the target is up, regardless of what reality is. Nmap is just taking your word for it. Use--reason
to see why it thinks so.