Here's what I figured with the help of a few articles from NixCraft:

I just tested it, and it seems to be doing what I need, I'm curious if maybe the rules are either too lenient, or too restrictive, as a user I only need internet and SSH open, IDK about any necessary services other than ICMP for testing and stuff. I'm curious if there are any necessary service that I'm blocking.

The 127.0.0.1 would normally be the loopback device (lo) and not eth0.

If you're doing any network file systems you're likely blocking them. If you do any IRC stuff you're probably blocking ident and other things that "chat" things seem to "require" these days. Along with FTP, PING, and other things you might use from outside your machine. But if you don't use any of that stuff, you're good (in theory). Of course you're only blocking incoming things for the most part. Your system is still free to broadcast any and all things OUT of your network.

In debian the netbase package has a /etc/services file that lists a lot of ports for various things. And one should note that iptables has -t ??? things beyond just nat and mangle. Like filter, and a couple others I don't recall of the top of my head. Not that they get used much by default, but they exist and you're not clearing them.

And of course tcp is only one packet type. According to /etc/services, it implies that ssh (20), http(80), and https(443) use both tcp and udp packets. Or I could be wrong, I am by no means a network guru.

1 members found this post helpful.

I can gaurantee that the only user-level applications I'll be using (for now) will be Apache and SSL. For security I only want the essential applications to be able to listen. Its bad enough I need apache. PING, traceroute, and other utilities, I believe are ICMP, so `iptables -A INPUT -i eth0 -p icmp -s 0.0.0.0/0 -m state --state ESTABLISHED,RELATED -j ACCEPT` will allow return ACK packets for those services. However my machine won't respond to any of them on the outside, which is what I intend.

I didn't know about the other tables thanks for pointing that out.

And the loopback socket. Oops. Thank you.

Err

ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol

while

ftp-data 20/tcp # File Transfer [Default Data]
ftp-data 20/udp # File Transfer [Default Data]
ftp-data 20/sctp # FTP

http could also be on 8080 or 3128 (squid caching) or some anagram (8123?, polipo). And ssh is often put on another port as a 'security' measure (which it isn't really, on its own, but that's drifting in a direction firmly signposted as 'Off Topic'). But, at least you should know if you've done it and allow the correct port, whichever that is.

Here endeth todays reading from /etc/services

Anyway, egress (that which gets out) filtering is more difficult....actually, that's a bad statement, as it isn't so much difficult, just a bit fussy, compared to stateful filtering of what comes in.

If you're using Debian...

One of the things I do on a fresh install is to stop and disable any unnecessary services. A basic install will have exim4, nfs-common and rpcbind running - I've not found any problems with disabling these on most systems.

If there's nothing listening on a port, nothing will be able to connect to it...

I'd add rules for outgoing traffic and setting the chain to DROP by default.

If your PC gets compromised you would like to limit the actions an attacker might perform, wouldn't you?

DROP is not the wisest choice for blocking outgoing traffic. In 99.99% or more of the cases any outgoing traffic is going to be coming from you. In that case you don't want to waste your time waiting for timeouts which DROP will cause. For outgoing traffic, at least, use REJECT instead of DROP.

I don't understand your point.

If the traffic is legitimate, it is not going to be dropped, so why would you have to wait for DROP timeout?

Here are two examples, of many. You can have a legitimate application sending traffic on a port other than you expected. Or you can add a new application and need to update the packet filter.

DROP is not any "extra" help on the external connections either. Try reading the link I provided or try this one instead:

http://www.chiark.greenend.org.uk/~p...drop-vs-reject

There are a lot more similar articles.

So the best approach is to let INPUT as DROP but OUTPUT as REJECT? Or do you use REJECT on INPUT chain as well?

Both can benefit from REJECT over DROP. For me, the point is to keep you from spending your time unnecessarily while configuring, debugging or using your own services. That is also by extension your legitimate users and customers. There are other points in the two links above.

There are exceptions. Say you have a --limit set for a particular port, it probably does not matter if you use DROP there. If you are really interested in that or think it's fun you can look at compiling in the TARPIT target. But I don't know if that is uptodate or even usable. It's probably not in the regular iptables for a reason and your return for the effort will likely be low.

1 members found this post helpful.

I know this is old. I don't mean to bump old threads. whatever.

So the reject vs drop policy is:
they both work the same
at least reject is TCP compliant

I didn't understand the SYN attack argument, he seems to be saying that drop stays in the buffer longer. Why is it in the buffer at all? why wouldn't the packet memory be marked free immediately when drop rule is reached?

I also don't see the point in controlling output if my input rules are solid. If my server is compromised, how hard would it be to change the netfilter rules. They're being read by a regular system file.

It's not that old. A compromised system might change your executables, and otherwise go undetected. Like swapping out your bash for a version that keylogs. There's basically nothing in place to prevent E.T. from phoning home if you don't filter your OUTPUT packets.

And then there's workplace issues where you need the network up for downloads / updates, but don't want to broadcast anything until you've finished configuring the machine(s). And other workplace issues where you need to block users from inside the network from using sites and services. Or family issues where you need more of the same.