hi, it''d be very useful to add some kind of "log everything" option to shorewall. currently the logging is useful if you know what you would like to log. but if you don''t know than it''s a problem... another problem that currently it''s not possible to log the nat table. at least i can''t find any way (can''t add logging into masq and nat file). the real reason is that we find some strange packages, ie. there are many (thousends of) ESTABLISHED direct connections in our firewall''s conntract table. after we examine them we realized that these connections never can be establised according to our wish, but they are there. so we try to find the reason. currently only the last line of the policy (reject all) has logged, but of course it''s not enough since these connections are not rejected. our sysadms look through the rules and can''t find the reason. after that list all iptables rules (ie. iptables -L -t ...) and examine that (which is ~900 lines) and can''t find the reason. to put into all policy and rules file a logging directive is rather uggly and still can''t put lines into masq and nat files. i don''t insert here our rules since imho the problem is not specific to us (our rules) rather than someone who don''t know or can''t find the reason a general logging would be useful. my sugestion would be a shorewall.conf option (yes/no) which add a log rules to filter''s, nat''s and mangel''s default tables. yours. ps. we still don''t know the reason may be tomorrow we will know more:-( -- Levente "Si vis pacem para bellum!"
Hello Levente, Farkas Levente said the following on 18-Oct-04 18:38:> hi, > it''d be very useful to add some kind of "log everything" option to > shorewall. currently the logging is useful if you know what you would > like to log. but if you don''t know than it''s a problem...You don''t mention anything in regards to the amount of traffic / number of sessions etc. Looking at syslog and the difficulties I personally had in the past with syslog and it''s capability to keep up. The minute you start logging every packet on a host that is transfering only a few 100Kb/sec you will run into disk IO and/or disk space issues. Maybe it''s an option to look at using tcpdump for this. If you want to know which connection is natted and why check cat /proc/net/ip_conntrack you could use lsconntrack for this. See: http://www.hensema.net/software/lsconntrack/ lsconntrack makes it a lot better readable/understandable imho.> another problem that currently it''s not possible to log the nat table. > at least i can''t find any way (can''t add logging into masq and nat file). > the real reason is that we find some strange packages, ie. there areWhat NAT modules do you have loaded (lsmod), if you look at FTP or IRC with DCC you might see some strange "non-authorized" connections but actually they are "indirectly" allowed by the module. Because for active FTP there is a data channel and a command channel. And the command channel is using port 21, the data channel is "random" high ports normally (AND doesn''t have to use port 20). The same goes for IRC/DCC, the ports are dynamicly assigned.> many (thousends of) ESTABLISHED direct connections in our firewall''s > conntract table. after we examine them we realized that these > connections never can be establised according to our wish, but they are > there. so we try to find the reason. currently only the last line of the > policy (reject all) has logged, but of course it''s not enough sinceDid you check you configuration with a port scanner on a remote network and checking with tcpdump on your external interface, of just looking at the log? At the end a long email, no anwser but I hope it helps you in the right direction. Stijn -- Met Vriendelijke groet/Yours Sincerely Stijn Jonker <SJCJonker@sjc.nl>
Stijn Jonker wrote:> Hello Levente, > > > Farkas Levente said the following on 18-Oct-04 18:38: > >> hi, >> it''d be very useful to add some kind of "log everything" option to >> shorewall. currently the logging is useful if you know what you would >> like to log. but if you don''t know than it''s a problem... > > > You don''t mention anything in regards to the amount of traffic / number > of sessions etc. Looking at syslog and the difficulties I personally had > in the past with syslog and it''s capability to keep up. The minute you > start logging every packet on a host that is transfering only a few > 100Kb/sec you will run into disk IO and/or disk space issues.we use ulogd and not syslogd. anyway for testing/debuging prupose just a few minutes of "full-logging" are may be enough.> Maybe it''s an option to look at using tcpdump for this. > > If you want to know which connection is natted and why check cat > /proc/net/ip_conntrack you could use lsconntrack for this. > See: http://www.hensema.net/software/lsconntrack/ > > lsconntrack makes it a lot better readable/understandable imho.we use conntrack-viewer.pl:-)>> another problem that currently it''s not possible to log the nat table. >> at least i can''t find any way (can''t add logging into masq and nat file). >> the real reason is that we find some strange packages, ie. there are > > > What NAT modules do you have loaded (lsmod), if you look at FTP or IRC > with DCC you might see some strange "non-authorized" connections but > actually they are "indirectly" allowed by the module. Because for active > FTP there is a data channel and a command channel. And the command > channel is using port 21, the data channel is "random" high ports > normally (AND doesn''t have to use port 20). > > The same goes for IRC/DCC, the ports are dynamicly assigned.we don''t know whether they are nat-ed we just would like to see ALL packets traverse through the firewall, to find out how can it be possible. we''got such lines: tcp 6 51583 ESTABLISHED src=81.183.30.75 dst=81.182.143.107 sport=135 dport=4340 [UNREPLIED] src=81.182.143.107 dst=81.183.30.75 sport=4340 dport=135 use=1 tcp 6 63358 ESTABLISHED src=81.183.30.75 dst=81.183.144.245 sport=135 dport=3955 [UNREPLIED] src=81.183.144.245 dst=81.183.30.75 sport=3955 dport=135 use=1>> many (thousends of) ESTABLISHED direct connections in our firewall''s >> conntract table. after we examine them we realized that these >> connections never can be establised according to our wish, but they >> are there. so we try to find the reason. currently only the last line >> of the policy (reject all) has logged, but of course it''s not enough >> since > > > Did you check you configuration with a port scanner on a remote network > and checking with tcpdump on your external interface, of just looking at > the log?no. we can''t see the log (that''s what we like to see) we just look into /proc/net/ip_conntrack. -- Levente "Si vis pacem para bellum!"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Farkas Levente wrote:> > > we don''t know whether they are nat-ed we just would like to see ALL > packets traverse through the firewall, to find out how can it be > possible. we''got such lines: > tcp 6 51583 ESTABLISHED src=81.183.30.75 dst=81.182.143.107 > sport=135 dport=4340 [UNREPLIED] src=81.182.143.107 dst=81.183.30.75 > sport=4340 dport=135 use=1 > tcp 6 63358 ESTABLISHED src=81.183.30.75 dst=81.183.144.245 > sport=135 dport=3955 [UNREPLIED] src=81.183.144.245 dst=81.183.30.75 > sport=3955 dport=135 use=1 >a) Because the addresses and ports on the right hand side of the entries is the reverse of the left side, there is no NAT involved. b) The connections you show are being initiated by 81.183.30.75. c) Your firewall is not seeing a reply from the destination hosts -- possibly because of an MTU problem (routing problems usually produce SYN-SENT rather than UNREPLIED). I would pick one of these "stuck" tcp sessions and try to look at it with tcpdump (e.g., tcpdump -ni any host 81.130.30.75 and host 81.182.143.107). - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBdFjkO/MAbZfjDLIRAnv5AJ4mK3CywD6nZGJwlloX01/ir2XEzgCgyefE RRNugvOexzrebhNUFMpLKa4=muSb -----END PGP SIGNATURE-----
Tom Eastep wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Farkas Levente wrote: > >> >>we don''t know whether they are nat-ed we just would like to see ALL >>packets traverse through the firewall, to find out how can it be >>possible. we''got such lines: >>tcp 6 51583 ESTABLISHED src=81.183.30.75 dst=81.182.143.107 >>sport=135 dport=4340 [UNREPLIED] src=81.182.143.107 dst=81.183.30.75 >>sport=4340 dport=135 use=1 >>tcp 6 63358 ESTABLISHED src=81.183.30.75 dst=81.183.144.245 >>sport=135 dport=3955 [UNREPLIED] src=81.183.144.245 dst=81.183.30.75 >>sport=3955 dport=135 use=1 >> > > > a) Because the addresses and ports on the right hand side of the entries > is the reverse of the left side, there is no NAT involved.yes we know that:-)> b) The connections you show are being initiated by 81.183.30.75.we also know that.> c) Your firewall is not seeing a reply from the destination hosts -- > possibly because of an MTU problem (routing problems usually produce > SYN-SENT rather than UNREPLIED). I would pick one of these "stuck" tcp > sessions and try to look at it with tcpdump (e.g., tcpdump -ni any host > 81.130.30.75 and host 81.182.143.107).we finally find the reason and simply switch to NEWNOTSYN=No. anyway imho it should be the default. the reason outlined in the conf file is not too ''real'' for me. an ESTABLISHED conntract has 5 days timeout. is there any tcp application timeout longer than this? and those who has redundant firewall can switch this to yes. but (as i wrote in my original mail) the problem is probably not with shorewall and that''s why i didn''t write the detail. my problem with shorewall is the logging possibility. as i always think about shorewall as a frontend to the iptables/netfilter, i always would like to do ALL of my netfilter wish with shorewall. in this current case (and anytime when someone would like to debug what''s happend) i''d like to see all packets in all table for a few seconds/minutes. so i''d like to turn on logging and see where the packets come and which tables reached. how can i do it with iptables? - put a logging into filter''s INPUT, FORWARD, OUTPUT table as a fist rule. - put a logging into nat''s PREROUTING, OUTPUT, POSTROUTING table as a fist rule. - put a logging into mangle''s PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING table as a fist rule. can i do it with shoreall? no. first off all a global option in shorewall.conf would be the best solution. but currently i can define as rules: LOG:ULOG all all but this never put a logging into nat''s and mangle''s tables! and i can''t put logging directive into masq or nat files. (ok i can put iptables command into initdone, but ...) that was my problem with shorewall, and that''s why i wrote this mail. what''s more i realy think it can be a good and useful feature for everyone. yours. -- Levente "Si vis pacem para bellum!"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Farkas Levente wrote:> - put a logging into filter''s INPUT, FORWARD, OUTPUT table as a fist rule. > - put a logging into nat''s PREROUTING, OUTPUT, POSTROUTING table as a > fist rule. > - put a logging into mangle''s PREROUTING, INPUT, FORWARD, OUTPUT, > POSTROUTING table as a fist rule. > can i do it with shoreall? > no.And I am frankly very reluctant to add that feature to Shorewall since turning it on will bring most firewalls instantly to their knees and the only way to regain control might be to reboot. Then there is the case where remote logging is being used and the user accidentally turns on this LOGALL feature. Again, it will probably not be possible to regain control of the system. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBdm5YO/MAbZfjDLIRAnPCAKCjcz0/h8/LJ+339etqadf/bjhRrACguzsk Kyz7SpmDupCzhnyzZdL4Dw8=qRGn -----END PGP SIGNATURE-----
Tom Eastep wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Farkas Levente wrote: > > >>- put a logging into filter''s INPUT, FORWARD, OUTPUT table as a fist rule. >>- put a logging into nat''s PREROUTING, OUTPUT, POSTROUTING table as a >>fist rule. >>- put a logging into mangle''s PREROUTING, INPUT, FORWARD, OUTPUT, >>POSTROUTING table as a fist rule. >>can i do it with shoreall? >>no. > > > And I am frankly very reluctant to add that feature to Shorewall since > turning it on will bring most firewalls instantly to their knees and the > only way to regain control might be to reboot. Then there is the case > where remote logging is being used and the user accidentally turns on > this LOGALL feature. Again, it will probably not be possible to regain > control of the system.ok. but than at least the possibility to add separate logging for each tables would be useful. currently only policy and rules files (filter''s and PREROUTING dnat) logging are possible (no log for masq and nat). and here comes my previous request to add SNAT to the rules file too. anyway currently a LOG:ULOG all all is useful enough for me (and our firewall stall). -- Levente "Si vis pacem para bellum!"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Farkas Levente wrote:> > ok. but than at least the possibility to add separate logging for each > tables would be useful. currently only policy and rules files (filter''s > and PREROUTING dnat) logging are possible (no log for masq and nat). and > here comes my previous request to add SNAT to the rules file too. > anyway currently a > LOG:ULOG all all > is useful enough for me (and our firewall stall). >What *might* be useful and wouldn''t kill firewalls would be something like: LOGALLNEW=<log level> If set, all packets in the NEW connection state would be logged at the head of each of the builtin tables and chains. That would produce 8-9 messages per new connection (logging everything produces 8-9 messages *per packet*). - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBdoJuO/MAbZfjDLIRAgmBAKCovlExaWRGDe3zwsR6ET6BERqZcACgt0WQ l2s73xp4W0NvYphaRjlQi/8=LbVO -----END PGP SIGNATURE-----
Tom Eastep wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Farkas Levente wrote: > > >>ok. but than at least the possibility to add separate logging for each >>tables would be useful. currently only policy and rules files (filter''s >>and PREROUTING dnat) logging are possible (no log for masq and nat). and >>here comes my previous request to add SNAT to the rules file too. >>anyway currently a >>LOG:ULOG all all >>is useful enough for me (and our firewall stall). >> > > > What *might* be useful and wouldn''t kill firewalls would be something like: > > LOGALLNEW=<log level> > > If set, all packets in the NEW connection state would be logged at the > head of each of the builtin tables and chains. > > That would produce 8-9 messages per new connection (logging everything > produces 8-9 messages *per packet*).this can be also good. but the problem with this is what happend with us. if you set NEWNOTSYN=Yes then we never find how those conntract become ESTABILISED. the reason that poeple can accidently turn on LOGALL is not a real good reason. since someone can do the above LOG:ULOG all all which has half of the LOGALL effect... -- Levente "Si vis pacem para bellum!"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Farkas Levente wrote:> Tom Eastep wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Farkas Levente wrote: >> >> >>> ok. but than at least the possibility to add separate logging for each >>> tables would be useful. currently only policy and rules files (filter''s >>> and PREROUTING dnat) logging are possible (no log for masq and nat). and >>> here comes my previous request to add SNAT to the rules file too. >>> anyway currently a >>> LOG:ULOG all all >>> is useful enough for me (and our firewall stall). >>> >> >> >> What *might* be useful and wouldn''t kill firewalls would be something >> like: >> >> LOGALLNEW=<log level> >> >> If set, all packets in the NEW connection state would be logged at the >> head of each of the builtin tables and chains. >> >> That would produce 8-9 messages per new connection (logging everything >> produces 8-9 messages *per packet*). > > > this can be also good. but the problem with this is what happend with > us. if you set NEWNOTSYN=Yes then we never find how those conntract > become ESTABILISED. the reason that poeple can accidently turn on LOGALL > is not a real good reason. since someone can do the above > LOG:ULOG all all > which has half of the LOGALL effect... >It is about 1/8th of the LOGALLNEW effect - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBdtMAO/MAbZfjDLIRAiqqAKDEa4oyJt3MSMqDxr2Rq8iTBiWhlwCdFHjs jmyOm7rTcra7uWySlgWtVek=bZIC -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote:>>>this can be also good. but the problem with this is what happend with >>>us. if you set NEWNOTSYN=Yes then we never find how those conntract >>>become ESTABILISED. the reason that poeple can accidently turn on LOGALL >>>is not a real good reason. since someone can do the above >>>LOG:ULOG all all >>>which has half of the LOGALL effect... >>> > > > It is about 1/8th of the LOGALLNEW effect >You do realize that Shorewall rules only deal with packets in the NEW connection state, right? So what I''m proposing with LOGALLNEW is a natural extension of your rule. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBdtTOO/MAbZfjDLIRAofdAJ927+LocnYdql7ixrybPbNKtg23aACeNhMn TRY148gRedB1Zpy1+zA4nnU=ictK -----END PGP SIGNATURE-----
On Mon, 18 Oct 2004 16:59:32 -0700, Tom Eastep <teastep@shorewall.net> wrote:> c) Your firewall is not seeing a reply from the destination hosts -- > possibly because of an MTU problem (routing problems usually produce > SYN-SENT rather than UNREPLIED). I would pick one of these "stuck" tcp > sessions and try to look at it with tcpdump (e.g., tcpdump -ni any host > 81.130.30.75 and host 81.182.143.107).I might take this opputunity to recommend tethereal to people. its the console version of ethereal. I find it heaps easier to read than tcpdump. http://www.ethereal.com/docs/man-pages/tethereal.1.html thanks dave