From: nt4admin <nt4...@tr...> - 2003-01-14 15:45:09
|
I would like to cut down on packets logged from "loc2net". I have modified my policy file so that the logging for loc2net is "err" but dns packets and smtp are still being logged. Is it possible to filter these out? On a separate note, if I define ULOG in policy, I get an error on shorewall startup "ULOG not defined" or something of that nature. Sorry about being so vague, I last tried it a couple of days ago and did not write the error down. ulogd is started and running. Thanks for your time, Steve Postma System Admin Travizon |
From: Richard B. <ri...@gb...> - 2003-07-29 13:33:57
|
Hi is it possible to get shorewall to use a dedicated log file instead of syslog, ie /var/log/shorewall thanks Richard -- Richard Bown <ri...@gb...> |
From: Peter E. <ei...@ha...> - 2003-07-29 13:48:52
|
On Tue, Jul 29, 2003 at 02:33:46PM +0100, Richard Bown wrote: > Hi > is it possible to get shorewall to use a dedicated log file instead of > syslog, > ie /var/log/shorewall it's in the doc's http://www.shorewall.net/FAQ.htm#faq6 Bye, Peter > > thanks > Richard > -- > Richard Bown <ri...@gb...> > > _______________________________________________ > Shorewall-users mailing list > Post: Sho...@li... > Subscribe/Unsubscribe: http://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm -- _______________________________ Dr. Hagen&Partner GmbH Am Weichselgarten 7 91058 Erlangen Tel: (0049)9131/691-330 Fax: (0049)9131/691-248 _______________________________ |
From: Mohamed B. <mb...@gm...> - 2005-04-05 12:15:41
|
Is it possible to define a file log such as for example /dev/tty2 in the configuration of shorewall. greetings. |
From: Karsten <k.b...@da...> - 2005-04-05 14:42:50
|
> Is it possible to define a file log such as for example /dev/tty2 in > the configuration of shorewall. greetings. You will need to use ulogd if you want to log Shorewall messages to a different place than your kernel messages. See "Shorewall Logging" accessible from the Documentation: http://shorewall.net/shorewall_logging.html karsten --=20 Davision - Atelier fuer Gestaltung / Internet / Multimedia UNIX / Linux Netzwerke und Schulungen Telefon 06151/273859 Fax 06151/273862 |
From: Tom A. <to...@ta...> - 2008-11-30 01:00:44
|
OK, I got the note about using the policy "redundancy" to separate the logging rules. Making great progress. Shorewall is relatively intuitive if you are familiar with the whole iptables thing. But it has been a few years since I wrote my own firewalls. 'nuther question: I have this: Nov 29 19:38:01 voyager kernel: Shorewall:mangle:PREROUTING:IN=eth1 OUT= MAC=01:00:5e:00:00:fb:00:19:e3:d6:1c:50:08:00 SRC=192.168.1.102 DST=224.0.0.251 LEN=118 TOS=0x18 PREC=0x00 TTL=255 ID=51329 PROTO=UDP SPT=5353 DPT=5353 LEN=98 Nov 29 19:38:01 voyager kernel: Shorewall:nat:PREROUTING:IN=eth1 OUT= MAC=01:00:5e:00:00:fb:00:19:e3:d6:1c:50:08:00 SRC=192.168.1.102 DST=224.0.0.251 LEN=118 TOS =0x18 PREC=0x00 TTL=255 ID=51329 PROTO=UDP SPT=5353 DPT=5353 LEN=98 From what I can figure out this is a macbook that is sending out some kind of Multicast DNS. Never heard of it. It's not handled by the DNS macro. I guess this is part of Bonjour (which I'm liking less and less all the time -- why must they reinvent everything). I'm going to guess that bind9 doesn't support this and doesn't seem to need to. So it would be safe to set a rule like: DROP loc all tcp 5353 DROP loc all udp 5353 Yes/No? |
From: Shorewall G. <sho...@co...> - 2008-11-30 01:14:49
|
Tom Allison wrote: > OK, I got the note about using the policy "redundancy" to separate the > logging rules. > > > Making great progress. Shorewall is relatively intuitive if you are > familiar with the whole iptables thing. But it has been a few years > since I wrote my own firewalls. > > > 'nuther question: > > I have this: > Nov 29 19:38:01 voyager kernel: Shorewall:mangle:PREROUTING:IN=eth1 OUT= > MAC=01:00:5e:00:00:fb:00:19:e3:d6:1c:50:08:00 SRC=192.168.1.102 > DST=224.0.0.251 LEN=118 > TOS=0x18 PREC=0x00 TTL=255 ID=51329 PROTO=UDP SPT=5353 DPT=5353 LEN=98 > Nov 29 19:38:01 voyager kernel: Shorewall:nat:PREROUTING:IN=eth1 OUT= > MAC=01:00:5e:00:00:fb:00:19:e3:d6:1c:50:08:00 SRC=192.168.1.102 > DST=224.0.0.251 LEN=118 TOS > =0x18 PREC=0x00 TTL=255 ID=51329 PROTO=UDP SPT=5353 DPT=5353 LEN=98 > > > From what I can figure out this is a macbook that is sending out some > kind of Multicast DNS. Never heard of it. It's not handled by the DNS > macro. I guess this is part of Bonjour (which I'm liking less and less > all the time -- why must they reinvent everything). > > I'm going to guess that bind9 doesn't support this and doesn't seem to > need to. So it would be safe to set a rule like: > > DROP loc all tcp 5353 > DROP loc all udp 5353 > > Yes/No? Why don't you just turn off LOGALLNEW like everyone else who uses Shorewall does? |
From: Tom A. <to...@ta...> - 2008-11-30 01:28:06
|
Shorewall Geek wrote: > Tom Allison wrote: >> OK, I got the note about using the policy "redundancy" to separate the >> logging rules. >> >> >> Making great progress. Shorewall is relatively intuitive if you are >> familiar with the whole iptables thing. But it has been a few years >> since I wrote my own firewalls. >> >> >> 'nuther question: >> >> I have this: >> Nov 29 19:38:01 voyager kernel: Shorewall:mangle:PREROUTING:IN=eth1 OUT= >> MAC=01:00:5e:00:00:fb:00:19:e3:d6:1c:50:08:00 SRC=192.168.1.102 >> DST=224.0.0.251 LEN=118 >> TOS=0x18 PREC=0x00 TTL=255 ID=51329 PROTO=UDP SPT=5353 DPT=5353 LEN=98 >> Nov 29 19:38:01 voyager kernel: Shorewall:nat:PREROUTING:IN=eth1 OUT= >> MAC=01:00:5e:00:00:fb:00:19:e3:d6:1c:50:08:00 SRC=192.168.1.102 >> DST=224.0.0.251 LEN=118 TOS >> =0x18 PREC=0x00 TTL=255 ID=51329 PROTO=UDP SPT=5353 DPT=5353 LEN=98 >> >> >> From what I can figure out this is a macbook that is sending out some >> kind of Multicast DNS. Never heard of it. It's not handled by the DNS >> macro. I guess this is part of Bonjour (which I'm liking less and less >> all the time -- why must they reinvent everything). >> >> I'm going to guess that bind9 doesn't support this and doesn't seem to >> need to. So it would be safe to set a rule like: >> >> DROP loc all tcp 5353 >> DROP loc all udp 5353 >> >> Yes/No? > > Why don't you just turn off LOGALLNEW like everyone else who uses > Shorewall does? Actually, I did. I think it's logging on my loglevel setting and not the logallnew (which is no). But part of this answer is to ensure that I'm understanding this shorewall structure. LOGALLNEW=No doesn't help that part of the process. |
From: Shorewall G. <sho...@co...> - 2008-11-30 01:35:23
|
Tom Allison wrote: > Shorewall Geek wrote: >> Tom Allison wrote: >>> OK, I got the note about using the policy "redundancy" to separate the >>> logging rules. >>> >>> >>> Making great progress. Shorewall is relatively intuitive if you are >>> familiar with the whole iptables thing. But it has been a few years >>> since I wrote my own firewalls. >>> >>> >>> 'nuther question: >>> >>> I have this: >>> Nov 29 19:38:01 voyager kernel: Shorewall:mangle:PREROUTING:IN=eth1 OUT= >>> MAC=01:00:5e:00:00:fb:00:19:e3:d6:1c:50:08:00 SRC=192.168.1.102 >>> DST=224.0.0.251 LEN=118 >>> TOS=0x18 PREC=0x00 TTL=255 ID=51329 PROTO=UDP SPT=5353 DPT=5353 LEN=98 >>> Nov 29 19:38:01 voyager kernel: Shorewall:nat:PREROUTING:IN=eth1 OUT= >>> MAC=01:00:5e:00:00:fb:00:19:e3:d6:1c:50:08:00 SRC=192.168.1.102 >>> DST=224.0.0.251 LEN=118 TOS >>> =0x18 PREC=0x00 TTL=255 ID=51329 PROTO=UDP SPT=5353 DPT=5353 LEN=98 >>> >>> >>> From what I can figure out this is a macbook that is sending out some >>> kind of Multicast DNS. Never heard of it. It's not handled by the DNS >>> macro. I guess this is part of Bonjour (which I'm liking less and less >>> all the time -- why must they reinvent everything). >>> >>> I'm going to guess that bind9 doesn't support this and doesn't seem to >>> need to. So it would be safe to set a rule like: >>> >>> DROP loc all tcp 5353 >>> DROP loc all udp 5353 >>> >>> Yes/No? >> Why don't you just turn off LOGALLNEW like everyone else who uses >> Shorewall does? > > Actually, I did. I think it's logging on my loglevel setting and not > the logallnew (which is no). But part of this answer is to ensure that > I'm understanding this shorewall structure. LOGALLNEW=No doesn't help > that part of the process. > The log entries you posted are only generated when LOGALLNEW=Yes |
From: Tom A. <to...@ta...> - 2008-11-30 01:41:49
|
Shorewall Geek wrote: > Tom Allison wrote: > > The log entries you posted are only generated when LOGALLNEW=Yes > Maybe I forgot to restart it... Anyways, shorewall seems to be doing it's job. Now it's back to DHCP, DNS and all the rest of the network "stuff". Thank you. |
From: Shorewall G. <sho...@co...> - 2008-11-30 01:51:03
|
Tom Allison wrote: > Shorewall Geek wrote: >> Tom Allison wrote: > >> The log entries you posted are only generated when LOGALLNEW=Yes >> > > Maybe I forgot to restart it... > > Anyways, shorewall seems to be doing it's job. Now it's back to DHCP, > DNS and all the rest of the network "stuff". A few hints: a) Be sure that you are following one of the HOWTOs at shorewall.net b) You are running Debian; the version of Shorewall that is included with Etch is 3.2.6 which *isn't even supported anymore*. c) There is a repository (maintained by the Debian Shorewall maintainer) that has Shorewall 4 packages; see the Shorewall download page. d) No Shorewall newbie should be running anything but Shorewall-perl which isn't even available in Shorewall 3.2.6. |
From: Tom A. <to...@ta...> - 2008-11-30 01:55:47
|
> A few hints: > > a) Be sure that you are following one of the HOWTOs at shorewall.net > b) You are running Debian; the version of Shorewall that is included > with Etch is 3.2.6 which *isn't even supported anymore*. > c) There is a repository (maintained by the Debian Shorewall maintainer) > that has Shorewall 4 packages; see the Shorewall download page. > d) No Shorewall newbie should be running anything but Shorewall-perl > which isn't even available in Shorewall 3.2.6. a) yup. b) testing has 4.0 so I'm running that. c) don't know if I need that if I'm running testing but I can look into it. d) This intrigues me. Why Shorewall-perl? debugging support? This is the first I heard someone promoting the perl implimentation. |
From: Shorewall G. <sho...@co...> - 2008-11-30 02:30:14
|
Tom Allison wrote: > d) This intrigues me. Why Shorewall-perl? debugging support? This is > the first I heard someone promoting the perl implimentation. a) The shell implementation hasn't had any active development in two years. So all new features introduced in the last year and a half are only available in the perl version. b) The perl implementation is an order of magnitude faster compiling the firewall configuration. c) The perl implementation is an order of magnitude faster instantiating the firewall configuration. d) The perl implementation doesn't disable new connections during start/restart. e) The perl diagnostics are much better and the perl implementation catches many more configuration errors at compile time. |
From: Tom A. <to...@ta...> - 2008-11-30 13:13:25
|
Shorewall Geek wrote: > Tom Allison wrote: > >> d) This intrigues me. Why Shorewall-perl? debugging support? This is >> the first I heard someone promoting the perl implimentation. > > a) The shell implementation hasn't had any active development in two > years. So all new features introduced in the last year and a half are > only available in the perl version. > b) The perl implementation is an order of magnitude faster compiling the > firewall configuration. > c) The perl implementation is an order of magnitude faster instantiating > the firewall configuration. > d) The perl implementation doesn't disable new connections during > start/restart. > e) The perl diagnostics are much better and the perl implementation > catches many more configuration errors at compile time. > > This should be a large red label on the beginning of the README (or at least the Debian install). I see this mentioned in the docs, but I missed it. Sounds like the shell is deprecated. Should people think if migrating? OK, now that I've already gotten it implemented in the shell version I have to re-do this for perl. I know that there are some command differences in there, but I wasn't paying attention to them thinking that I wasn't going to be required to migrate. I don't suppose there is a short list of what to check? |
From: Shorewall G. <sho...@co...> - 2008-11-30 15:09:32
|
Tom Allison wrote: > This should be a large red label on the beginning of the README (or at > least the Debian install). I see this mentioned in the docs, but I > missed it. Sounds like the shell is deprecated. Should people think if > migrating? Yes. > > OK, now that I've already gotten it implemented in the shell version I > have to re-do this for perl. I know that there are some command > differences in there, but I wasn't paying attention to them thinking > that I wasn't going to be required to migrate. I don't suppose there is > a short list of what to check? http://www.shorewall.net/Shorewall-perl.html#Incompatibilities |
From: Tom A. <to...@ta...> - 2008-11-30 15:19:17
|
Shorewall Geek wrote: > Tom Allison wrote: > >> This should be a large red label on the beginning of the README (or at >> least the Debian install). I see this mentioned in the docs, but I >> missed it. Sounds like the shell is deprecated. Should people think if >> migrating? > > Yes. > >> OK, now that I've already gotten it implemented in the shell version I >> have to re-do this for perl. I know that there are some command >> differences in there, but I wasn't paying attention to them thinking >> that I wasn't going to be required to migrate. I don't suppose there is >> a short list of what to check? > > http://www.shorewall.net/Shorewall-perl.html#Incompatibilities > Excellent! I thought USE_ACTIONS was a previous implementation and macros are the favored method. So I'm not sure why USE_ACTIONS=No is not supported. Maybe I'm reading too much into this? |
From: Shorewall G. <sho...@co...> - 2008-11-30 15:47:40
|
Tom Allison wrote: > > I thought USE_ACTIONS was a previous implementation and macros are the > favored method. So I'm not sure why USE_ACTIONS=No is not supported. > Maybe I'm reading too much into this? > As clearly described in the shorewall.conf man page, USE_ACTIONS=No allows the disk (and RAM) footprint of Shorewall-shell to be reduced in embedded applications. |
From: Tom E. <te...@sh...> - 2003-01-14 18:39:14
|
--On Tuesday, January 14, 2003 10:45:00 AM -0500 nt4admin <nt4...@tr...> wrote: > I would like to cut down on packets logged from "loc2net". I have > modified my policy file so that the logging for loc2net is "err" but dns > packets and smtp are still being logged. Is it possible to filter these > out? If you don't want loc->net messages then why are you specifying logging of them at all? > > On a separate note, if I define ULOG in policy, I get an error on > shorewall startup "ULOG not defined" or something of that nature. Sorry > about being so vague, I last tried it a couple of days ago and did not > write the error down. ulogd is started and running. > I guess I have to ask if you a looking for help or sympathy? With this report, about all I can offer you is the latter. If you want our help, see http://shorewall.sf.net/support.htm for guidance about what we need to help you solve problems. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ te...@sh... |