also sprach Philipp Snizek (on Sun, 24 Dec 2000 10:35:36PM +0100):
I accept that you use 100% ipchains to see how secure it is. But your solution is not very fexible, e.g. ftp. Many ftp servers have (as you know) data ports on >1024. Connections to them will not work (I beg your pardon if I'm wrong, I just went very quickly through it).
i think i am allowing them. specifically with the following two lines: -A ei-in -d 0.0.0.0/0 1024:65535 -p 6 -j accepted -A ei-in -d 0.0.0.0/0 1024:65535 -p 17 -j accepted where ei-in is the chain of packets arriving from a non-local machine on the external interface.
You can save up a lot of rulesets which will make your script easier to control by using squid for www, ssl and pasv ftp. Also you can run bind as a dns forwarder bound to your int eth (Not to your ext eth!).
well, i am. currently, i don't forward 443 to squid, but 80 is automatically handled by squid without the need to specify a proxy. and i actually did not know that ftp can be handled by squid too.
I solved it the way that I have squid doing the main internet job. My ipchains forward policy is set to deny. All others are set to accept. I just run ipchains for pop and smtp. This makes it very easy to control the chains.
yes i know. i don't find my scripts particularly hard for i broke them up into subchains quite nicely...
I know, it's not what you wanted to hear. I'm not a cacker. But I still hope that it helps in making your systems more secure and easier to monitor.
thanks though. i appreciate any input... martin [greetings from the heart of the sun]# echo madduck@!#:1:s@\@@@.net -- the young lady had an unusual list, linked in part to a structural weakness. she set no preconditions.