Firstly may I ask, what is the point/purpose of redacting your local IP addresses and ports? It does nothing to help you in the "security by obscurity" school of thought, and really makes helping you a crystal ball job.
When I run it however I loose the ability to access any ports or even ping from the local host.
iptables -A INPUT -d 10.0.0.xx -s 127.0.0.1 -j ACCEPT
To enable traffic on the loopback interface, you would need to use a rule such as
iptables -A INPUT -i lo -j ACCEPT
Which will accept anything and everything on the loopback interface. This is usually standard practice.
Since you are running a webserver you are most likely going to want to allow access to either the entire internet, or an entire lan. Matching by destination IP is a bit pointless, since the packets have got to the host, chances are they have the hosts IP as the packets destination IP. Normally one would use a rule such as
iptables -A INPUT -p tcp --dport 80 -s 10.0.0.0/24 -j ACCEPT
This would allow anything coming from the 10.0.0.0/24 subnet, and drop everything else. In the case of a public webserver, you would omit the -s match.
I try to think of iptables rules by breaking them down. Looking at the specific characteristics of the connections I want to allow
Lets take your ssh rule as an example.
iptables -A INPUT -d 10.0.0.xx -p tcp --dport xxx -j ACCEPT
iptables -A INPUT (append a rule to the end of the filter table, INPUT chain)
-d 10.0.0.xx (match packets with a destination IP 10.0.0.xx AND)
-p tcp --dport xxx (protocol: tcp, destination port xxx)
-j ACCEPT (this ones pretty obvious)
It is also worthwhile to enable logging, this is helpful for diagnosing problems.
Also using "watch" in conjunction with "iptables -nvL $chain" while generating a bunch of traffic using hping or nc and watching the byte/packet counters.
I really do recommend this link for a good description of how iptables works, with flowcharts and tables explaining the tables, and chains etc..