A practical guide for IPtables and Linux security

This is the best iptables tutorial I've seen. Oskar Andreasson's iptables tutorial is the one I rely on, but he doesn't explain things as well as this does. Use them together and you shall be Iptable Master of the Universe. A++, many thumbs up.

Ok, bookmarked. Your praise impresses me :D

Looks like I'll need this one now that I'm bringing up my mail service. It turns out I can't connect to my imap/pop server because the ports aren't opened on that box.

don, when you say 'ports aren't opened' are your imap/pop services running, or is there a firewall in the way? I'm sure you know the difference, but it is a point of confusion for a lot of newbs, who naturally are reading this thread in breathless anticipation of Mysteries Revealed.

My fave diagnostic tools are these:

ping, to test both connectivity and name services. always ping first by IP address and then hostname

netstat -untap on the box itself, to see what ports are open, which is another way of saying what services are running and which ports they are listening on

nmap, to see how your server looks from the outside

nmap shows ports 25 & 80 as open, but no listing for 110/143. Ports are opened on the router. Mail goes in/out when using mail on the local box, but I can't connect from my laptop via Kmail. I mailed myself, my pa & brother from the local box, so I could ssh into it and run mail. I just can't connect to the IMAP/POP accounts.

At least now I can ssh into the box. I'm using a fresh, vanilla install of Debian Etch with postfix and dovecot.

Well then I'd say your POP and IMAP servers are not running. 'ps ax' or 'netstat -untap' will tell for sure.

That is a possibility. I ran /etc/init.d/dovecot start, but didn't see any messages. I had to leave and can't seem to login via SSH from here for some reason. :-( I'm getting a message about the keys being changed. I only logged in once to test the connection, then left to come to work. Strange that.

OMG Don, it's evil crackers! Oh wait, that means something different in the South, doesn't it. Um, evil computer invaders! Um, oh I don't know.

Yeah, the login error message gives me the line about possible man-in-the-middle attacks. Frankly, I doubt it. I'll just have to wait until I get back home. That sucks. The whole point of running ssh was so I could work on the box during any breaks I might get. Arrrggghhh! Oh well.

Rev, that just means that the server host key has changed. So either you changed the actual key, either on purpose or accidentally, like reinstalling OpenSSH. Or the IP address of the server changed, and your SSH client already has a host key for that address, but now it's the wrong key because it's a different server. Go into /home/[user]/.ssh/known_hosts on the client PC and delete the offending key; the error message should tell you which one.

That's right! I've done that before. That's exactly what happened. I ran into a problem on the new server and, under the gun for time, I re-installed Etch on that box. I had forgotten about that issue.

/me knocks head against wall carefully - don't want to break wall.

I used to have that problem from time to time. My solution was to set up an account that had no priveledges at all. Pretty much the only thing that you could do is SSH into that account and no other. From there you could change users to one of the normal user accounts and from that account go root if needed. The dummy account had root access denied to it via aliases.

Its not elegant, but it let me loosen up the permissions so I could always SSH in.

*edit* missed the client side part of the description. oops */edit*

O.k. you were right. It wasn't running. I got it up and running o.k. now. I can use mail & mutt at the local box to read/send mail from my shiny new server.