I am new to the list but impressed with shorewall & the archives (though I can''t find a way to search the archives other than downloading the lot & mounting them locally). I''ve installed 1.2.12 which is the package in the Debian stable release tree, it''s on kernel 2.4.18-586tsc and iptables 1.2.6a. I have an ADSL connection with a fixed IP and four IPs on top of that gateway one. Currently I use all four for wife, my and kids'' computers and the crucial server which serves up http,https,smtp,pop3 & ssh and runs ntp to keep time and whatever it needs for the DNS. At the moment I don''t need the server to do any more but would like to have a new local net behind the server running samba (as we all have to use M$ sadly) and I''d like to put more machines in there so I can get linux back in. I think I''m "firewall-IQ-challenged" so apologies if I''m looking through answers to these questions somewhere obvious. 1) is the 1.3 tree a development tree and 1.2 the stable? Even if so, am I right to guess from the development history that I should still be safe to point my sources.list at: deb http://security.dsi.unimi.it/~lorenzo/debian ./ and move to the 1.3.8 version? 2) I want to put the firewall in front of some local machines which will run on a 100Mbs hub and move my www and Email server to a dmz running off a different interface on the firewall using proxyarp: I''ve got the loc zone working with masquerading and everything simple seems to work fine (no samba yet!). I have got proxyarp working to some extent except that it seems to block DNS lookups by the server in the dmz despite the fact that the same rules allow lookups from the loc zone (with masquerading). That cripples things but doesn''t generate shorewall error messages so I think I''ve misunderstood proxyarp. Do I need different subnet masks on the firewall & server in the dmz? One thing I read seems to say "yes" another "no". 3) Finally a philosophy issue almost. My reading around firewalling suggests to me that I''d be safest with: all all DROP info as the only policy and then use explicit rules to allow only exactly what I want, both outgoing and incoming. Most of the shorewall examples I have read seem to start with more tolerant policies. Anyone worked on my paranoid mode and willing to share config e.g.s Enough for now. Hoping someone can help. Chris PSYCTC: Psychotherapy, Psychology, Psychiatry, Counselling and Therapeutic Communities; practice, research, teaching and consultancy. Chris Evans & Jo-anne Carlyle http://psyctc.org/ Email: chris@psyctc.org
This is a cryptographically signed message in MIME format. --------------ms040703010907000206010608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chris Evans wrote:> I am new to the list but impressed with shorewall & the archives > (though I can''t find a way to search the archives other than > downloading the lot & mounting them locally).The Archive Search feature has been removed from the Shorewall web site until further notice.> I''ve installed 1.2.12 > which is the package in the Debian stable release tree, it''s on > kernel 2.4.18-586tsc and iptables 1.2.6a. I have an ADSL connection > with a fixed IP and four IPs on top of that gateway one. Currently I > use all four for wife, my and kids'' computers and the crucial server > which serves up http,https,smtp,pop3 & ssh and runs ntp to keep time > and whatever it needs for the DNS. At the moment I don''t need the > server to do any more but would like to have a new local net behind > the server running samba (as we all have to use M$ sadly) and I''d > like to put more machines in there so I can get linux back in. > > I think I''m "firewall-IQ-challenged" so apologies if I''m looking > through answers to these questions somewhere obvious. > > 1) is the 1.3 tree a development tree and 1.2 the stable? Even if > so, am I right to guess from the development history that I should > still be safe to point my sources.list at: > deb http://security.dsi.unimi.it/~lorenzo/debian ./ > and move to the 1.3.8 version?Shorewall has ONE thread -- I can barely keep up with that...> > 2) I want to put the firewall in front of some local machines which > will run on a 100Mbs hub and move my www and Email server to a dmz > running off a different interface on the firewall using proxyarp: > > I''ve got the loc zone working with masquerading and everything simple > seems to work fine (no samba yet!). > > I have got proxyarp working to some extent except that it seems to > block DNS lookups by the server in the dmz despite the fact that the > same rules allow lookups from the loc zone (with masquerading). That > cripples things but doesn''t generate shorewall error messages so I > think I''ve misunderstood proxyarp. Do I need different subnet masks > on the firewall & server in the dmz? One thing I read seems to say > "yes" another "no".Please read the Setup Guide once more -- I don''t think my explaination of subnet masks and subnetteing is THAT confusing....> > 3) Finally a philosophy issue almost. My reading around firewalling > suggests to me that I''d be safest with: > all all DROP info > as the only policy and then use explicit rules to allow only exactly > what I want, both outgoing and incoming. Most of the shorewall > examples I have read seem to start with more tolerant policies. > Anyone worked on my paranoid mode and willing to share config e.g.s >While a REJECT/DROP default policy is the most secure, most people trying to administer a firewall don''t know enough about what is going on in their network to administer such a policy. That''s why I have a default ACCEPT policy for loc->net. Also, a prefer a REJECT policy for local users trying to access something they shouldn''t -- why make them wait for protocol timeouts? -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net --------------ms040703010907000206010608 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJVDCC AwgwggJxoAMCAQICAwhOLTANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDkxODIxMTQxN1oXDTAzMDkxODIxMTQxN1owRzEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIGCSqGSIb3DQEJARYVdGVhc3Rl cEBzaG9yZXdhbGwubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvdDPv/q5 adQCmEtbNtdWcsmF7qO5Eg5JkvI50WkiCkcv89KfsRA6tFGtsgIOsgU5l3wDQSzqEVX0MfIV qpn7ycZJ6823cuvXXjBQwwpqVSlpJkHhpd1uCCLomkfPAxKdfBNAjh4E1ZgHuur7GAWc0iBd 2n9oJ9wBg8gDQP9ViYU4+x2z/7muvY4RuzL5eF+mtzx4UtSx9CFqu1n8uNIu44T4CXRZ8HwT Hg2eC61x6E6XFV48Oid9t8qmKXjUGINJ3hbXwQmees3K/ZrGYZ+FPoOJyWn+PpvrNQrVvkp5 a7YblgaoLX1dS5QGgsl9XhRz6sqzvklAd7eh4g0JoWOD4QIDAQABozIwMDAgBgNVHREEGTAX gRV0ZWFzdGVwQHNob3Jld2FsbC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDakl1XW6IrAL4ZG+WtwT5GqQLPnFgbHjo/s88xvvdQRRhgd//uW81hQUk5tHkBisJKgHcv F1trxcylWylrSSLf2TANtw0M8kvW9clJe5xZieyshemLvEWHsC4mItPiId9dWaZQX90L9yZz 0qi8iTlmU5i8JPeiJJVwwmQJNI93LzCCAwgwggJxoAMCAQICAwhOLTANBgkqhkiG9w0BAQQF ADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2Vz MSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDkxODIx MTQxN1oXDTAzMDkxODIxMTQxN1owRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJl cjEkMCIGCSqGSIb3DQEJARYVdGVhc3RlcEBzaG9yZXdhbGwubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAvdDPv/q5adQCmEtbNtdWcsmF7qO5Eg5JkvI50WkiCkcv89Kf sRA6tFGtsgIOsgU5l3wDQSzqEVX0MfIVqpn7ycZJ6823cuvXXjBQwwpqVSlpJkHhpd1uCCLo mkfPAxKdfBNAjh4E1ZgHuur7GAWc0iBd2n9oJ9wBg8gDQP9ViYU4+x2z/7muvY4RuzL5eF+m tzx4UtSx9CFqu1n8uNIu44T4CXRZ8HwTHg2eC61x6E6XFV48Oid9t8qmKXjUGINJ3hbXwQme es3K/ZrGYZ+FPoOJyWn+PpvrNQrVvkp5a7YblgaoLX1dS5QGgsl9XhRz6sqzvklAd7eh4g0J oWOD4QIDAQABozIwMDAgBgNVHREEGTAXgRV0ZWFzdGVwQHNob3Jld2FsbC5uZXQwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQDakl1XW6IrAL4ZG+WtwT5GqQLPnFgbHjo/s88x vvdQRRhgd//uW81hQUk5tHkBisJKgHcvF1trxcylWylrSSLf2TANtw0M8kvW9clJe5xZieys hemLvEWHsC4mItPiId9dWaZQX90L9yZz0qi8iTlmU5i8JPeiJJVwwmQJNI93LzCCAzgwggKh oAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2 aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0w NDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIw EAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNh dGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO40Qp imM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Y cvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMBAAGj TjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzASBgNVHRMB Af8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtHXfkBceX1 U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1MG7wD9LXr okefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZph39Ins6l n+eE2MliYq0FxjGCAycwggMjAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJT QSAyMDAwLjguMzACAwhOLTAJBgUrDgMCGgUAoIIBYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA5MjMwMTIyNDhaMCMGCSqGSIb3DQEJBDEWBBTrcldl e0uXOOnyWk/I7j/s+6nIljBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBrQYLKoZI hvcNAQkQAgsxgZ2ggZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCE4tMA0GCSqGSIb3DQEBAQUABIIBAEB0kJd2zWyx5ZHuJtF5OaW4LqXQxEomD7MclQnN 2jNCEgftV2HJG8qdK6LAPGxCc4K8rBsHrIP21MLMwPVwAMt6arIqgAKAHaHsLmqEgZvSYEJq HNnSlYOgV3ivUJIPsmAw3cMsj6+PZ4k7cxiHyw7z1kxcp8ED2YHGpQhNre49DtcD3hDgKWBH CjMopwq6AvoVnvlFroh0tb/m799/jY2VAWPYcmRNbor0zhv1lh2FxH9PQObqG9ZxBM5ExxN1 7jsaI2zKcEIVrdxIincG/9/x1RPSGgAH78W2lkBI8aOI0ki/sKpWSLuYfLfMBwdwzbVDigwf BEExsJ65wvDg7CYAAAAAAAA--------------ms040703010907000206010608--
Now that I''ve had some sleep, I''ll try to be a bit more helpful. Tom Eastep wrote:> > > The Archive Search feature has been removed from the Shorewall web site > until further notice.The Archive Search should be available again shortly -- thanks for bringing this to my attention.> >> I''ve installed 1.2.12 which is the package in the Debian stable >> release tree, it''s on kernel 2.4.18-586tsc and iptables 1.2.6a. I >> have an ADSL connection with a fixed IP and four IPs on top of that >> gateway one. Currently I use all four for wife, my and kids'' >> computers and the crucial server which serves up http,https,smtp,pop3 >> & ssh and runs ntp to keep time and whatever it needs for the DNS. At >> the moment I don''t need the >> server to do any more but would like to have a new local net behind >> the server running samba (as we all have to use M$ sadly) and I''d like >> to put more machines in there so I can get linux back in. >> >> I think I''m "firewall-IQ-challenged" so apologies if I''m looking >> through answers to these questions somewhere obvious. >> >> 1) is the 1.3 tree a development tree and 1.2 the stable? Even if so, >> am I right to guess from the development history that I should still >> be safe to point my sources.list at: >> deb http://security.dsi.unimi.it/~lorenzo/debian ./ and move to >> the 1.3.8 version? > > > Shorewall has ONE thread -- I can barely keep up with that...You should have no problems upgrading to 1.3.8 if you carefully review the Upgrade Issues page (http://www.shorewall.net/upgrade_issues.htm) first. Some things have changed incompatibly between 1.2 and 1.3.> >> >> 2) I want to put the firewall in front of some local machines which >> will run on a 100Mbs hub and move my www and Email server to a dmz >> running off a different interface on the firewall using proxyarp: >> I''ve got the loc zone working with masquerading and everything simple >> seems to work fine (no samba yet!). >> I have got proxyarp working to some extent except that it seems to >> block DNS lookups by the server in the dmz despite the fact that the >> same rules allow lookups from the loc zone (with masquerading).What do you have for the dmz->net policy? That may be what''s different about the local net and the dmz.>> That >> cripples things but doesn''t generate shorewall error messages so I >> think I''ve misunderstood proxyarp. Do I need different subnet masks >> on the firewall & server in the dmz? One thing I read seems to say >> "yes" another "no". > > > Please read the Setup Guide once more -- I don''t think my explaination > of subnet masks and subnetteing is THAT confusing.... >And the Setup Guide (http://www.shorewall.net/shorewall_setup_guide.htm) uses a setup very similar to yours as an example.>> >> 3) Finally a philosophy issue almost. My reading around firewalling >> suggests to me that I''d be safest with: >> all all DROP info >> as the only policy and then use explicit rules to allow only exactly >> what I want, both outgoing and incoming. Most of the shorewall >> examples I have read seem to start with more tolerant policies. >> Anyone worked on my paranoid mode and willing to share config e.g.s >> > > While a REJECT/DROP default policy is the most secure, most people > trying to administer a firewall don''t know enough about what is going on > in their network to administer such a policy. That''s why I have a > default ACCEPT policy for loc->net. Also, a prefer a REJECT policy forMake that "I prefer"...> local users trying to access something they shouldn''t -- why make them > wait for protocol timeouts?The only place where I advocate an ACCEPT policy is loc->net because otherwise, you have your local users always whining about "XYZ doesn''t work". So unless you have a restrictive environment (business environments usually) where you actually want to limit your local users'' internet access, ACCEPT makes the most sense. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On 23 Sep 2002 at 7:49, Tom Eastep wrote:> Now that I''ve had some sleep, I''ll try to be a bit more helpful.It was very helpful first time around and I was rather embarrassed and meant to say so but haven''t had time ... and now you''ve added more help - stunning!> The Archive Search should be available again shortly -- thanks for > bringing this to my attention.Good luck!> >> 1) is the 1.3 tree a development tree and 1.2 the stable? Even if so, > >> am I right to guess from the development history that I should still > >> be safe to point my sources.list at: > >> deb http://security.dsi.unimi.it/~lorenzo/debian ./ and move to > >> the 1.3.8 version? > > Shorewall has ONE thread -- I can barely keep up with that... > > You should have no problems upgrading to 1.3.8 if you carefully review the > Upgrade Issues page (http://www.shorewall.net/upgrade_issues.htm) first. > Some things have changed incompatibly between 1.2 and 1.3.Found it and will look through carefully and upgrade. Thanks.> What do you have for the dmz->net policy? That may be what''s different > about the local net and the dmz.I am pretty sure I had exactly the same and the problem was the same when I put masquerading in instead of proxyarp on the dmz. Odd thing was that when I swapped loc & dmz so that they were on the other combination of eth1 and eth2 they worked fine. Haven''t had the energy to work out why the old card (NE2000 compatible) maybe is causing the one machine to fail on the DNS but seems to work fine to the hub and the other machines ... and the hardware is probably a red herring and like you I need more sleep before I really try to get to the bottom of that ... so for now, I''m not fixing what''s suddenly not broke!> > Please read the Setup Guide once more -- I don''t think my explaination > > of subnet masks and subnetteing is THAT confusing....It wasn''t, it was perfect, I''d gone through it too fast first time, went back and felt ashamed!> And the Setup Guide (http://www.shorewall.net/shorewall_setup_guide.htm) > uses a setup very similar to yours as an example.Indeed and has been perfect for me!> >> 3) Finally a philosophy issue almost. My reading around firewalling > >> suggests to me that I''d be safest with: > >> all all DROP info > >> as the only policy and then use explicit rules to allow only exactly > >> what I want, both outgoing and incoming. Most of the shorewall > >> examples I have read seem to start with more tolerant policies. > >> Anyone worked on my paranoid mode and willing to share config e.g.s > >> > > > > While a REJECT/DROP default policy is the most secure, most people > > trying to administer a firewall don''t know enough about what is going on > > in their network to administer such a policy. That''s why I have a > > default ACCEPT policy for loc->net. Also, a prefer a REJECT policy for > > Make that "I prefer"...oops!> > local users trying to access something they shouldn''t -- why make them > > wait for protocol timeouts? > > The only place where I advocate an ACCEPT policy is loc->net because > otherwise, you have your local users always whining about "XYZ doesn''t > work". So unless you have a restrictive environment (business environments > usually) where you actually want to limit your local users'' internet > access, ACCEPT makes the most sense.Gotcha. I and family are only users and I know what we use so I''ve gone for a single all all DROP policy and filled in the rules I knew I needed. As services are few and defined it''s now working beautifully. Thanks: outstanding. Now a new question: do you or others have recommendations for good ways to check your firewall from the internet if you don''t have your own machine on the network from which to do the checking? Chris PSYCTC: Psychotherapy, Psychology, Psychiatry, Counselling and Therapeutic Communities; practice, research, teaching and consultancy. Chris Evans & Jo-anne Carlyle http://psyctc.org/ Email: chris@psyctc.org
* Chris Evans (chris@psyctc.org) [020923 11:03]: [snip]> Thanks: outstanding. Now a new question: do you or others have > recommendations for good ways to check your firewall from the > internet if you don''t have your own machine on the network from which > to do the checking?Do you mean something like: http://scan.sygatetech.com/