You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(93) |
Nov
(89) |
Dec
(68) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(229) |
Feb
(204) |
Mar
(314) |
Apr
(380) |
May
(367) |
Jun
(244) |
Jul
(300) |
Aug
(505) |
Sep
(359) |
Oct
(531) |
Nov
(427) |
Dec
(390) |
2003 |
Jan
(585) |
Feb
(623) |
Mar
(412) |
Apr
(315) |
May
(480) |
Jun
(394) |
Jul
(544) |
Aug
(768) |
Sep
(602) |
Oct
(680) |
Nov
(499) |
Dec
(398) |
2004 |
Jan
(407) |
Feb
(400) |
Mar
(410) |
Apr
(576) |
May
(619) |
Jun
(424) |
Jul
(513) |
Aug
(404) |
Sep
(433) |
Oct
(455) |
Nov
(550) |
Dec
(659) |
2005 |
Jan
(450) |
Feb
(472) |
Mar
(443) |
Apr
(465) |
May
(434) |
Jun
(273) |
Jul
(518) |
Aug
(484) |
Sep
(380) |
Oct
(400) |
Nov
(351) |
Dec
(265) |
2006 |
Jan
(335) |
Feb
(462) |
Mar
(498) |
Apr
(398) |
May
(280) |
Jun
(273) |
Jul
(229) |
Aug
(377) |
Sep
(201) |
Oct
(279) |
Nov
(247) |
Dec
(229) |
2007 |
Jan
(301) |
Feb
(190) |
Mar
(281) |
Apr
(444) |
May
(394) |
Jun
(247) |
Jul
(259) |
Aug
(391) |
Sep
(219) |
Oct
(306) |
Nov
(307) |
Dec
(257) |
2008 |
Jan
(256) |
Feb
(248) |
Mar
(330) |
Apr
(219) |
May
(194) |
Jun
(179) |
Jul
(183) |
Aug
(116) |
Sep
(260) |
Oct
(204) |
Nov
(274) |
Dec
(228) |
2009 |
Jan
(251) |
Feb
(160) |
Mar
(178) |
Apr
(196) |
May
(189) |
Jun
(239) |
Jul
(92) |
Aug
(155) |
Sep
(147) |
Oct
(169) |
Nov
(159) |
Dec
(205) |
2010 |
Jan
(63) |
Feb
(230) |
Mar
(94) |
Apr
(103) |
May
(113) |
Jun
(149) |
Jul
(158) |
Aug
(203) |
Sep
(255) |
Oct
(138) |
Nov
(122) |
Dec
(108) |
2011 |
Jan
(93) |
Feb
(100) |
Mar
(153) |
Apr
(175) |
May
(349) |
Jun
(210) |
Jul
(176) |
Aug
(179) |
Sep
(148) |
Oct
(151) |
Nov
(102) |
Dec
(83) |
2012 |
Jan
(179) |
Feb
(125) |
Mar
(211) |
Apr
(164) |
May
(195) |
Jun
(160) |
Jul
(137) |
Aug
(159) |
Sep
(214) |
Oct
(189) |
Nov
(71) |
Dec
(90) |
2013 |
Jan
(161) |
Feb
(99) |
Mar
(190) |
Apr
(133) |
May
(119) |
Jun
(97) |
Jul
(116) |
Aug
(109) |
Sep
(213) |
Oct
(175) |
Nov
(119) |
Dec
(90) |
2014 |
Jan
(104) |
Feb
(105) |
Mar
(125) |
Apr
(119) |
May
(141) |
Jun
(82) |
Jul
(193) |
Aug
(164) |
Sep
(160) |
Oct
(162) |
Nov
(44) |
Dec
(43) |
2015 |
Jan
(92) |
Feb
(67) |
Mar
(117) |
Apr
(67) |
May
(121) |
Jun
(39) |
Jul
(31) |
Aug
(87) |
Sep
(143) |
Oct
(130) |
Nov
(116) |
Dec
(67) |
2016 |
Jan
(66) |
Feb
(78) |
Mar
(127) |
Apr
(148) |
May
(56) |
Jun
(67) |
Jul
(30) |
Aug
(48) |
Sep
(87) |
Oct
(113) |
Nov
(64) |
Dec
(115) |
2017 |
Jan
(95) |
Feb
(73) |
Mar
(166) |
Apr
(27) |
May
(75) |
Jun
(94) |
Jul
(144) |
Aug
(94) |
Sep
(70) |
Oct
(98) |
Nov
(69) |
Dec
(176) |
2018 |
Jan
(140) |
Feb
(112) |
Mar
(68) |
Apr
(68) |
May
(97) |
Jun
(59) |
Jul
(75) |
Aug
(44) |
Sep
(44) |
Oct
(75) |
Nov
(64) |
Dec
(54) |
2019 |
Jan
(107) |
Feb
(100) |
Mar
(30) |
Apr
(31) |
May
(40) |
Jun
(14) |
Jul
(40) |
Aug
(37) |
Sep
(29) |
Oct
(78) |
Nov
(41) |
Dec
(42) |
2020 |
Jan
(43) |
Feb
(91) |
Mar
(86) |
Apr
(38) |
May
(70) |
Jun
(52) |
Jul
(48) |
Aug
(27) |
Sep
(48) |
Oct
(63) |
Nov
(61) |
Dec
(34) |
2021 |
Jan
(26) |
Feb
(4) |
Mar
(1) |
Apr
(5) |
May
(26) |
Jun
(13) |
Jul
(23) |
Aug
(14) |
Sep
(35) |
Oct
(13) |
Nov
(2) |
Dec
(33) |
2022 |
Jan
(32) |
Feb
(28) |
Mar
(29) |
Apr
(23) |
May
(15) |
Jun
(7) |
Jul
(6) |
Aug
(10) |
Sep
(3) |
Oct
|
Nov
(7) |
Dec
(3) |
2023 |
Jan
(7) |
Feb
(7) |
Mar
(6) |
Apr
(23) |
May
(1) |
Jun
(7) |
Jul
(4) |
Aug
(7) |
Sep
|
Oct
(27) |
Nov
(4) |
Dec
|
2024 |
Jan
(5) |
Feb
(28) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(10) |
Oct
|
Nov
|
Dec
|
From: <rc...@ed...> - 2024-02-13 19:16:47
|
Hi! with rocky try with shorewall 5.2.8 and masq dont work, but with centos7 the same version dont work, only work with 5.1.10. Exist some tips or parameters different? Thx El 2024-02-13 10:34, rc...@ed... escribió: > Hi! > > somebody know why masquerade dont work with rocky9? I dont found any > about that. > > Thx > _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users |
From: <rc...@ed...> - 2024-02-13 13:51:40
|
Hi! somebody know why masquerade dont work with rocky9? I dont found any about that. Thx |
From: Simon M. <sim...@in...> - 2024-01-08 18:21:30
|
> Shorewall version 5.2.8 on RHEL 7 virtualized on Ovirt hypervisors, > routing and filtering traffic between 5 networks full of VMs via VLANs > in Ovirt. > All virtual VM interfaces (including Shorewall VM), are on 10 Gbps. > > Effective speed between VMs on same network segment is full 10 Gbps. > > Speed between different networks that go trough Shorewall hardly ever > reaches 1 Gbps. > What can be done to achieve full throughput of traffic going trough > Shorewall? We don't know what exactly you're doing with Shorewall here, but, if you run your tests after 'shorewall clear', do you then see your expected throughput? Regards, Simon |
From: Ivica G. <ivi...@la...> - 2024-01-08 17:14:59
|
Shorewall version 5.2.8 on RHEL 7 virtualized on Ovirt hypervisors, routing and filtering traffic between 5 networks full of VMs via VLANs in Ovirt. All virtual VM interfaces (including Shorewall VM), are on 10 Gbps. Effective speed between VMs on same network segment is full 10 Gbps. Speed between different networks that go trough Shorewall hardly ever reaches 1 Gbps. What can be done to achieve full throughput of traffic going trough Shorewall? With regards Ivica |
From: Hosney O. <hos...@gm...> - 2024-01-03 13:03:17
|
do we have basic command should be applied to protect my network as recommendation On Tue, Jan 2, 2024 at 5:12 AM Nicola Ferrari (#554252) < nic...@po...> wrote: > Hi guys and happy new year! > > Just in case if someone will need this... > > To install shorewall on MicroOS, since it's an immutable distro and you > cannot modify the system root directly, you have to use the > transactional-update command which allows you to temporary access a > read-write shell on the system, install packages, and apply modifications. > > You'll have to: > > transactional-update pkg install shorewall > transactional-update apply > > It automatically takes shorewall from the zypper repos as a normal Suse > will do, install it and create a snapshot of the current state. By the > "apply" command you ask the system to activate the new snapshot without > having to reboot. > > Anyway this install approach should be used only for a minimum set of > system packages since normal software is supposed to be installed using > flatpak.. But I though shorewall is one of these rare cases. > > HtH, happy new year! > nik > > > _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users > |
From: Nicola F. (#554252) <nic...@po...> - 2024-01-02 13:11:02
|
Hi guys and happy new year! Just in case if someone will need this... To install shorewall on MicroOS, since it's an immutable distro and you cannot modify the system root directly, you have to use the transactional-update command which allows you to temporary access a read-write shell on the system, install packages, and apply modifications. You'll have to: transactional-update pkg install shorewall transactional-update apply It automatically takes shorewall from the zypper repos as a normal Suse will do, install it and create a snapshot of the current state. By the "apply" command you ask the system to activate the new snapshot without having to reboot. Anyway this install approach should be used only for a minimum set of system packages since normal software is supposed to be installed using flatpak.. But I though shorewall is one of these rare cases. HtH, happy new year! nik |
From: Steve H. <he...@he...> - 2024-01-02 03:07:53
|
Hello: I am a long time, very happy, Shorewall user. Many years ago I worked near Tom E. and we had lunch together a few times. Hello Tom. I had a stable configuration with a DSL provider and a cable provider and it ran for years without problems, again thanks to a suggestion from Tom. Recently I added a fiber provider but my system became unstable when I added it into the mix. And I haven't been able to duplicate my original DSL and cable configuration. The problem I have is that I haven't found the right options in my providers and rtrules files and I hope people on the list can help me out. My goal is to respond to any inbound traffic on the original provider link, that is, not having an asymmetric response. I am running Shorewall 5.2.8 on a gentoo system. I run my internet services on the firewall and have the rest of my machines on their own interface. One service is an ntp server in the ntppool.org system. When I first start Shorewall, everything seems ok. I can see ntp packets come in on my public IP, on the dsl/eth0 line and the return message immediately follows - for about 5 minutes, then the return packets start going out the faster fiber line, so, obviously I don't have proper tracking. I have attached my shorewall.conf file, a shorewall dump file, and a shorewall -T start log to this email. I do not have any mangle entries. Here are condensed versions of all configuration files I have changed: Any help is greatly appreciated. Thank you, Steve Herber. zones --------------------------------------------------------------------- fw firewall loc ipv4 dsl ipv4 fib ipv4 cbl ipv4 interfaces ---------------------------------------------------------------- dsl eth0 # I have a static public IP address on this interface loc eth1 cbl eth2 dhcp,optional fib eth3 dhcp,optional snat ---------------------------------------------------------------------- MASQUERADE - eth0 MASQUERADE - eth2 MASQUERADE - eth3 providers ----------------------------------------------------------------- #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY dsl 1 1 - eth0 detect track,primary - cbl 2 2 - eth2 detect track,fallback - fib 4 4 - eth3 detect track,fallback - rtrules ------------------------------------------------------------------- #SOURCE DEST PROVIDER PRIORITY MASK eth1 - fib 1500 eth1 - cbl 1000 eth1 - dsl 1600 policy -------------------------------------------------------------------- loc dsl ACCEPT loc cbl ACCEPT loc fib ACCEPT loc fw ACCEPT fw dsl ACCEPT fw cbl ACCEPT fw fib ACCEPT fw loc ACCEPT dsl all DROP none cbl all DROP info fib all DROP none all all REJECT none rules --------------------------------------------------------------------- ?SECTION NEW DNAT dsl loc:192.168.168.10:980 tcp 6980 ACCEPT dsl fw tcp 6622 - - 4/min:3 ACCEPT cbl fw tcp 6622 - - 4/min:3 ACCEPT fib fw tcp 6622 - - 4/min:3 ACCEPT dsl fw tcp domain,rndc ACCEPT dsl fw udp domain,rndc ACCEPT cbl fw tcp domain,rndc ACCEPT cbl fw udp domain,rndc ACCEPT fib fw tcp domain,rndc ACCEPT fib fw udp domain,rndc ACCEPT dsl fw tcp auth,http,https,smtp,ntp ACCEPT dsl fw udp http,https,ntp ACCEPT cbl fw tcp http,https,ntp ACCEPT cbl fw udp http,https,ntp ACCEPT fib fw tcp http,https,ntp ACCEPT fib fw udp http,https,ntp DROP fib fw tcp netbios-ns DROP fib fw udp netbios-ns DROP fib fw tcp mdns DROP fib fw udp mdns ACCEPT dsl fw udp 51820 ACCEPT cbl fw udp 51820 ACCEPT fib fw udp 51820 Ping(ACCEPT) dsl fw Ping(ACCEPT) cbl fw Ping(ACCEPT) fib fw Trcrt(ACCEPT) dsl fw Trcrt(ACCEPT) cbl fw Trcrt(ACCEPT) fib fw Steve Herber he...@he... cell: 425-281-0355 Software Engineer, UW Medicine, IT Services |
From: Phil S. <ph...@ca...> - 2023-11-10 21:00:30
|
On 11/10/23 15:42, John Covici wrote: > -----Original Message----- > From: Phil Stracchino <ph...@ca...> > Sent: Friday, November 10, 2023 1:41 PM > To: sho...@li... > Subject: Re: [Shorewall-users] unrecognized item on my internal nic, how to prevent phonning home > > On 11/10/23 11:28, John Covici wrote: >> Hi. I have a linux server using iptables 1.8 and shorewall version >> 5.2.8. I have two nics in the box, one for the outside world and an >> internal nic for various computers. I have two items in there which I >> cannot identify -- even using nmap and I would like to prevent them >> from accessing the outside. Any way to do this with shorewall? > > Something along the lines of: > > REJECT LOCALZONE:1.2.3.4 WANZONE > > should do it. > Thanks much for your quick response. Where should I put this statement, in the rules? Correct. Obviously the above needs to be adjusted to match your zones and the IPs in question. -- Phil Stracchino Babylon Communications ph...@ca... ph...@co... Landline: +1.603.293.8485 Mobile: +1.603.998.6958 |
From: John C. <co...@cc...> - 2023-11-10 20:50:32
|
-----Original Message----- From: Phil Stracchino <ph...@ca...> Sent: Friday, November 10, 2023 1:41 PM To: sho...@li... Subject: Re: [Shorewall-users] unrecognized item on my internal nic, how to prevent phonning home On 11/10/23 11:28, John Covici wrote: > Hi. I have a linux server using iptables 1.8 and shorewall version > 5.2.8. I have two nics in the box, one for the outside world and an > internal nic for various computers. I have two items in there which I > cannot identify -- even using nmap and I would like to prevent them > from accessing the outside. Any way to do this with shorewall? Something along the lines of: REJECT LOCALZONE:1.2.3.4 WANZONE should do it. Thanks much for your quick response. Where should I put this statement, in the rules? _______________________________________________ Shorewall-users mailing list Sho...@li... https://lists.sourceforge.net/lists/listinfo/shorewall-users |
From: Phil S. <ph...@ca...> - 2023-11-10 18:40:48
|
On 11/10/23 11:28, John Covici wrote: > Hi. I have a linux server using iptables 1.8 and shorewall version > 5.2.8. I have two nics in the box, one for the outside world and an > internal nic for various computers. I have two items in there which I > cannot identify -- even using nmap and I would like to prevent them > from accessing the outside. Any way to do this with shorewall? Something along the lines of: REJECT LOCALZONE:1.2.3.4 WANZONE should do it. -- Phil Stracchino Babylon Communications ph...@ca... ph...@co... Landline: +1.603.293.8485 Mobile: +1.603.998.6958 |
From: John C. <co...@cc...> - 2023-11-10 16:28:25
|
Hi. I have a linux server using iptables 1.8 and shorewall version 5.2.8. I have two nics in the box, one for the outside world and an internal nic for various computers. I have two items in there which I cannot identify -- even using nmap and I would like to prevent them from accessing the outside. Any way to do this with shorewall? Let me know if you need any more information. Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una co...@cc... |
From: Christophe P. <ch...@no...> - 2023-10-31 01:51:16
|
Le Fri, 27 Oct 2023 03:14:21 -0000 (UTC), Christophe PEREZ a écrit : > Not better: In your opinion, do I risk side effects (legitimate connection lost) if I put NotSyn(DROP) all all tcp in rules? |
From: Christophe P. <ch...@no...> - 2023-10-28 21:41:28
|
Le Fri, 27 Oct 2023 03:14:21 -0000 (UTC), Christophe PEREZ a écrit : >> Do I need to add ":$LOG_LEVEL" as: >> REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP),dropInvalid:$LOG_LEVEL" >> ? > > Not better: No news ? |
From: Christophe P. <ch...@no...> - 2023-10-27 03:14:41
|
Le Thu, 26 Oct 2023 22:01:19 -0000 (UTC), Christophe PEREZ a écrit : > Do I need to add ":$LOG_LEVEL" as: > REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP),dropInvalid:$LOG_LEVEL" > ? Not better: Oct 27 02:19:26 myserver kernel: [1647881.795002] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=45969 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 02:39:19 myserver kernel: [1649074.651136] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=24267 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 02:39:23 myserver kernel: [1649078.683137] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=24267 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 02:39:34 myserver kernel: [1649089.690784] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=62843 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 02:39:38 myserver kernel: [1649094.298718] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=62344 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 02:39:43 myserver kernel: [1649099.489891] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=32503 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 02:39:49 myserver kernel: [1649104.602563] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=40049 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 02:39:54 myserver kernel: [1649109.658463] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=615 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 02:40:12 myserver kernel: [1649127.577840] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=18660 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 02:40:34 myserver kernel: [1649149.593813] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=20117 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 04:38:26 myserver kernel: [1656222.112096] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=56497 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 04:53:42 myserver kernel: [1657137.490097] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=35623 WINDOW=0 RES=0x00 RST URGP=0 Oct 27 05:08:44 myserver kernel: [1658040.313037] fw-net DROP IN= OUT=eth0 SRC=myserverip DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=40715 WINDOW=0 RES=0x00 RST URGP=0 |
From: Christophe P. <ch...@no...> - 2023-10-26 22:01:40
|
Le Thu, 26 Oct 2023 19:20:06 -0000 (UTC), Christophe PEREZ a écrit : > I'll see how the logs evolve from now on. I still have them: Oct 26 21:47:33 myserver kernel: [1631569.333297] fw-net REJECT IN= OUT=eth0 SRC=myserverip DST=oneclientip LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=9856 DF PROTO=TCP SPT=465 DPT=36590 WINDOW=507 RES=0x00 ACK URGP=0 Oct 26 21:48:01 myserver kernel: [1631597.492820] fw-net REJECT IN= OUT=eth0 SRC=myserverip DST=oneclientip LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=9857 DF PROTO=TCP SPT=465 DPT=36590 WINDOW=507 RES=0x00 ACK URGP=0 Oct 26 21:48:59 myserver kernel: [1631655.347651] fw-net REJECT IN= OUT=eth0 SRC=myserverip DST=oneclientip LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=9858 DF PROTO=TCP SPT=465 DPT=36590 WINDOW=507 RES=0x00 ACK URGP=0 Oct 26 21:50:54 myserver kernel: [1631770.033392] fw-net REJECT IN= OUT=eth0 SRC=myserverip DST=oneclientip LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=9859 DF PROTO=TCP SPT=465 DPT=36590 WINDOW=507 RES=0x00 ACK URGP=0 Oct 26 21:52:05 myserver kernel: [1631841.220205] fw-net REJECT IN= OUT=eth0 SRC=myserverip DST=oneclientip LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=9860 DF PROTO=TCP SPT=465 DPT=36590 WINDOW=507 RES=0x00 ACK FIN URGP=0 Do I need to add ":$LOG_LEVEL" as: REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP),dropInvalid:$LOG_LEVEL" ? I humbly admit that I didn't understand much about the option. |
From: Christophe P. <ch...@no...> - 2023-10-26 19:20:25
|
Le Thu, 26 Oct 2023 21:00:41 +0300, Tuomo Soini a écrit : > Those are replies to clients which have actually already gone. So > completely normal. While your web server has been processing request, > client has gone and so netfilter has already closed the connection. I understand much better. It was the notion of closed connection that I lacked for understanding. >> Note that I have exactly the same question with the mail server and >> ports 25,110,143,465,993,995. > > Same for these. Of course. I suspected that the reason was the same, and that's why I stuck to the simple case of the Web. > You can remove these from logging by changing REJECT_DEFAULT in > shorewall.conf. If you add dropInvalid there those won't get logged any > more. Ok. I had the default: REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP)" I added dropInvalid REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP),dropInvalid" I'll see how the logs evolve from now on. > Web is not a standard protocol name, so shorewall developers decided to > add HTTP and HTTPS macros which are actual protocol names instead. But > to make sure old firewall installs won't break on shorewall upgrade, old > Web macro was left there. Ok. I'll switch to HTTP+HTTPS then. Thank you all for your valuable help. |
From: Tuomo S. <ti...@fo...> - 2023-10-26 18:20:02
|
On Thu, 26 Oct 2023 04:17:39 -0000 (UTC) Christophe PEREZ <ch...@no...> wrote: > Oct 26 03:57:04 myserver kernel: [1567341.969608] fw-net REJECT IN= > OUT=eth0 SRC=myipserver DST=oneclientip LEN=40 TOS=0x00 PREC=0x00 > TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=37615 WINDOW=0 RES=0x00 RST > URGP=0 Those are replies to clients which have actually already gone. So completely normal. While your web server has been processing request, client has gone and so netfilter has already closed the connection. > Note that I have exactly the same question with the mail server and > ports 25,110,143,465,993,995. Same for these. > I'm trying to understand, not necessarily to correct something if > it's not useful. You can remove these from logging by changing REJECT_DEFAULT in shorewall.conf. If you add dropInvalid there those won't get logged any more. Web is not a standard protocol name, so shorewall developers decided to add HTTP and HTTPS macros which are actual protocol names instead. But to make sure old firewall installs won't break on shorewall upgrade, old Web macro was left there. -- Tuomo Soini <ti...@fo...> Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> |
From: Simon M. <sim...@in...> - 2023-10-26 17:03:29
|
Hi, > >> Some comments: >> (1) It's recommended to use HTTP(ACCEPT) and HTTPS(ACCEPT) rather than >> Web(ACCEPT) which just combines the two. > > I don't understand why Web exist so, if not recommanded to use it. > I replaced Web by HTTP and HTTPS lines, and of course, nothing changed. > I guess Web was there first but it became clear that it's not always useful. In case you want only HTTPS then Web would be bad, I guess that's why HTTP and HTTPS were created. Web is just there for compatibility then - which is a good thing. Regards, Simon |
From: Norman a. A. H. <nor...@gm...> - 2023-10-26 16:32:12
|
I don't know nearly everything about shorewall nor IPTables. I notice however that using a sub-zone definition sshok:net is a bit unusual, and it's also unusual to have CONTINUE in policy. Maybe there are good reasons but I have a relatively complex installation and I haven't used nor seen either of those things before. Again I don't know everything :) Regarding your self-defined fw in the zones file versus the default $FW - no it doesn't matter, my error, $FW is only a shorthand for the zone defined as type "firewall". Regarding Web.macro : inside the macro there is a comment saying to use HTTP and HTTPS instead. I don't know why the developer made that comment. Hopefully you will be able to get a trace and maybe that will reveal the issue. If not I think you should post your entire configuration, with any public IP addresses etc. altered of course. On Thu, Oct 26, 2023 at 4:37 PM Christophe PEREZ <ch...@no...> wrote: > First, thanks for your answer. > > Le Thu, 26 Oct 2023 09:10:33 +0100, Norman and Audrey Henderson a écrit : > > > Hi, the one message you included is a normal response message from your > > web server to the client. The client (some random user on the Internet) > > has made a request with destination port 443 and a random source port, > > 37615. > > Apache replied with source port 443 and destination port 37615, that is > > completely normal. > > Ok. > > > With such limited information we can't see why there is a REJECT, plus > > you say the web server is working fine, so there is something else going > > on. > > I understand. > > > Some comments: > > (1) It's recommended to use HTTP(ACCEPT) and HTTPS(ACCEPT) rather than > > Web(ACCEPT) which just combines the two. > > I don't understand why Web exist so, if not recommanded to use it. > I replaced Web by HTTP and HTTPS lines, and of course, nothing changed. > > > (2) You only need rules for the incoming traffic. I think they should be > > HTTPS(ACCEPT) net $FW and HTTP(ACCEPT) net $FW ($FW refers to the > > firewall zone). > > I have zones: > fw firewall > net ipv4 > sshok:net ipv4 dynamic_shared > > In rules, should I use fw or $FW or nevermind ? > It seems that changing fw to $FW didn't change anything. > > > (3) Return traffic from the web server to the client is automatically > > permitted because of "connection tracking" - it's an established TCP > > connection. You may have some other rule that is blocking that (but > > then, > > the web server would not be working from the client's viewpoint). > > interfaces: > ?FORMAT 2 > net eth0 > > hosts: > sshok eth0:dynamic > > policy: > sshok all CONTINUE > all sshok CONTINUE > net all DROP info > all all REJECT info > > > > (4) To see what's actually happening you can do an iptrace: > > > > First make sure that logging is enabled in iptables (might be different > > depending on your distro): > > sudo modprobe nf_log_ipv4 > > sudo sysctl net.netfilter.nf_log.2=nf_log_ipv4 > > Not actually in my kernel > # grep -i log_ipv4 /usr/src/linux/.config > # CONFIG_NF_LOG_IPV4 is not set > > I'll have to recompile it with and reboot. I'll do it a bit later. > > > > _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users > |
From: Christophe P. <ch...@no...> - 2023-10-26 15:36:20
|
First, thanks for your answer. Le Thu, 26 Oct 2023 09:10:33 +0100, Norman and Audrey Henderson a écrit : > Hi, the one message you included is a normal response message from your > web server to the client. The client (some random user on the Internet) > has made a request with destination port 443 and a random source port, > 37615. > Apache replied with source port 443 and destination port 37615, that is > completely normal. Ok. > With such limited information we can't see why there is a REJECT, plus > you say the web server is working fine, so there is something else going > on. I understand. > Some comments: > (1) It's recommended to use HTTP(ACCEPT) and HTTPS(ACCEPT) rather than > Web(ACCEPT) which just combines the two. I don't understand why Web exist so, if not recommanded to use it. I replaced Web by HTTP and HTTPS lines, and of course, nothing changed. > (2) You only need rules for the incoming traffic. I think they should be > HTTPS(ACCEPT) net $FW and HTTP(ACCEPT) net $FW ($FW refers to the > firewall zone). I have zones: fw firewall net ipv4 sshok:net ipv4 dynamic_shared In rules, should I use fw or $FW or nevermind ? It seems that changing fw to $FW didn't change anything. > (3) Return traffic from the web server to the client is automatically > permitted because of "connection tracking" - it's an established TCP > connection. You may have some other rule that is blocking that (but > then, > the web server would not be working from the client's viewpoint). interfaces: ?FORMAT 2 net eth0 hosts: sshok eth0:dynamic policy: sshok all CONTINUE all sshok CONTINUE net all DROP info all all REJECT info > (4) To see what's actually happening you can do an iptrace: > > First make sure that logging is enabled in iptables (might be different > depending on your distro): > sudo modprobe nf_log_ipv4 > sudo sysctl net.netfilter.nf_log.2=nf_log_ipv4 Not actually in my kernel # grep -i log_ipv4 /usr/src/linux/.config # CONFIG_NF_LOG_IPV4 is not set I'll have to recompile it with and reboot. I'll do it a bit later. |
From: Norman a. A. H. <nor...@gm...> - 2023-10-26 08:10:55
|
Hi, the one message you included is a normal response message from your web server to the client. The client (some random user on the Internet) has made a request with destination port 443 and a random source port, 37615. Apache replied with source port 443 and destination port 37615, that is completely normal. With such limited information we can't see why there is a REJECT, plus you say the web server is working fine, so there is something else going on. Some comments: (1) It's recommended to use HTTP(ACCEPT) and HTTPS(ACCEPT) rather than Web(ACCEPT) which just combines the two. (2) You only need rules for the incoming traffic. I think they should be HTTPS(ACCEPT) net $FW and HTTP(ACCEPT) net $FW ($FW refers to the firewall zone). (3) Return traffic from the web server to the client is automatically permitted because of "connection tracking" - it's an established TCP connection. You may have some other rule that is blocking that (but then, the web server would not be working from the client's viewpoint). (4) To see what's actually happening you can do an iptrace: First make sure that logging is enabled in iptables (might be different depending on your distro): sudo modprobe nf_log_ipv4 sudo sysctl net.netfilter.nf_log.2=nf_log_ipv4 Then to see exactly how the return traffic from your web server is being processed by iptables: shorewall iptrace -p tcp --sport 443 -d your-client's-ip-address And to stop it: shorewall noiptrace -p tcp --sport 443 -d your-client's-ip-address You will need to know a bit about iptables works, if you don't, there are various handy flowcharts you can find by googling. sudo modprobe nf_log_ipv4 sThenudo sysctl net.netfilter.nf_log.2=nf_log_ipv4 On Thu, Oct 26, 2023 at 5:19 AM Christophe PEREZ <ch...@no...> wrote: > Hi, > > On one machine, I have a web server running (apache) and responding on > ports 80 and 443. On this machine, I have a firewall (shorewall) which > blocks EVERYTHING except what I authorize, and I therefore have the rules > (I have many others, but which are off topic here, so I keep it simple ): > > ?SECTION NEW > Web(ACCEPT) net fw > Web(ACCEPT) fw net > > Everything works perfectly. EXCEPT that in the firewall logs, I realize > that I have lots of outgoing requests rejected with SOURCE ports 80 and > 443. And I don't understand why these requests are sent, nor why rejecting > them is not not at all blocking the operation of the web server. > > Oct 26 03:57:04 myserver kernel: [1567341.969608] fw-net REJECT IN= > OUT=eth0 SRC=myipserver DST=oneclientip LEN=40 TOS=0x00 PREC=0x00 TTL=64 > ID=0 DF PROTO=TCP SPT=443 DPT=37615 WINDOW=0 RES=0x00 RST URGP=0 > > Note that I have exactly the same question with the mail server and ports > 25,110,143,465,993,995. > > I'm trying to understand, not necessarily to correct something if it's not > useful. > > > > _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users > |
From: Christophe P. <ch...@no...> - 2023-10-26 04:18:02
|
Hi, On one machine, I have a web server running (apache) and responding on ports 80 and 443. On this machine, I have a firewall (shorewall) which blocks EVERYTHING except what I authorize, and I therefore have the rules (I have many others, but which are off topic here, so I keep it simple ): ?SECTION NEW Web(ACCEPT) net fw Web(ACCEPT) fw net Everything works perfectly. EXCEPT that in the firewall logs, I realize that I have lots of outgoing requests rejected with SOURCE ports 80 and 443. And I don't understand why these requests are sent, nor why rejecting them is not not at all blocking the operation of the web server. Oct 26 03:57:04 myserver kernel: [1567341.969608] fw-net REJECT IN= OUT=eth0 SRC=myipserver DST=oneclientip LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=37615 WINDOW=0 RES=0x00 RST URGP=0 Note that I have exactly the same question with the mail server and ports 25,110,143,465,993,995. I'm trying to understand, not necessarily to correct something if it's not useful. |
From: David W. <wat...@gm...> - 2023-10-19 07:18:17
|
Thank you Vieri, that has sorted the problem. Thanks to Leandro too for their solution. I had already turned off Martian logging in shorewall.conf but I didn't know how to do it in the kernel log. That's a useful method to know about. Regards, On Wed, 18 Oct 2023 at 14:38, Vieri Di Paola <vie...@gm...> wrote: > Hi, > > Not sure about the log, but a quick workaround would be to add 172.26 as > an alias to the shorewall gateway. > > On Wed, Oct 18, 2023, 15:09 David Watkins <wat...@gm...> wrote: > >> Hi, >> >> I'm a long time shorewall user, but with very basic skills, running a >> simple 2 port firewall between my ISP and a home network. >> >> Home network is on 192.168.0.x >> >> My wife has configured her laptop NIC with both a 192.168 address and a >> 172.16.x address, so that she can connect to a private development system >> at her office (this system uses static IPs only). >> >> This means that when she connects at home the firewall machine log is >> flooded with kernel warnings about 172.16 martian packets. >> >> I can disable these warnings in the shorewall log but they still appear >> in the system log (journalctl). >> >> Can I use shorewall to drop them before the kernel sees them? or is >> there some other way of cleaning up the log? >> >> Thanks for any help. >> > > |
From: Leandro <lla...@ya...> - 2023-10-18 15:40:23
|
SHOREWALL You can turn off on shorewall.conf LOG_MARTIANS=No KERNEL You can turn off martian logging: echo 0 > /proc/sys/net/ipv4/conf/{all,default}/log_martians Regards. El 18/10/2023 a las 10:07, David Watkins escribió: > Hi, > > I'm a long time shorewall user, but with very basic skills, running a > simple 2 port firewall between my ISP and a home network. > > Home network is on 192.168.0.x > > My wife has configured her laptop NIC with both a 192.168 address and > a 172.16.x address, so that she can connect to a private development > system at her office (this system uses static IPs only). > > This means that when she connects at home the firewall machine log is > flooded with kernel warnings about 172.16 martian packets. > > I can disable these warnings in the shorewall log but they still > appear in the system log (journalctl). > > Can I use shorewall to drop them before the kernel sees them? or is > there some other way of cleaning up the log? > > Thanks for any help. > > > _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users |
From: Vieri Di P. <vie...@gm...> - 2023-10-18 13:37:56
|
Hi, Not sure about the log, but a quick workaround would be to add 172.26 as an alias to the shorewall gateway. On Wed, Oct 18, 2023, 15:09 David Watkins <wat...@gm...> wrote: > Hi, > > I'm a long time shorewall user, but with very basic skills, running a > simple 2 port firewall between my ISP and a home network. > > Home network is on 192.168.0.x > > My wife has configured her laptop NIC with both a 192.168 address and a > 172.16.x address, so that she can connect to a private development system > at her office (this system uses static IPs only). > > This means that when she connects at home the firewall machine log is > flooded with kernel warnings about 172.16 martian packets. > > I can disable these warnings in the shorewall log but they still appear in > the system log (journalctl). > > Can I use shorewall to drop them before the kernel sees them? or is there > some other way of cleaning up the log? > > Thanks for any help. > _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users > |