Hi, I have seen this come up in a couple of threads, but nothing recent. I was wondering a couple of things and was hoping someone could clarify. I have an existing working shorewall configuration (Details at end of post).>From within this config, I have a few ports redirected for use withportsentry (like the mini-howto directs forbidden port accesses to port 49999). This works correctly, and I receive notifications, and drops are saved to the /var/lib/shorewall/save file. It appeared as if everything is behgaving normally, but I wanted to know what ports people were hitting, so I turned on logging for the REDIRECT rules using REDIRECT:info. Once I did this, I see that dropped hosts are still redirected to the port 49999. Correct me if wrong, but wouldn''t it make sense that any dropped IP should never be allowed to hit the server? Shouldn''t it be immediately blocked if the shorewall drop x.x.x.x command was issued? Is this a behaviour that can be modified and if so, has anyone else done this or is there a howto to change this behaviour? I know in another post, Ted meantioned to a user he probably could use the start file to execute some script when starting shorewall. Would this work? Would it conflict with the existing shorewall drop/add? I would think that correcting the behaviour would be the more correct approach. Please, if anyone has a good solution, I''d like to know. Of courese, it''s possible I could be wrong, and the shorewall drop and REDIRECT functionality is behaving this way due to an option I have set or failed to set. If that''s the case, can anyone direct me to it? I''ve included the particulars for my setup below: shorewall version - 2.0.14 ip addr show - (I commented out IP on eth1 - my outside) 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:60:67:62:a0:c1 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0 inet6 fe80::260:67ff:fe62:a0c1/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 52:54:4c:04:a3:12 brd ff:ff:ff:ff:ff:ff inet w.x.y.z/22 brd w.x.y.255 scope global eth1 inet6 fe80::5054:4cff:fe04:a312/64 scope link valid_lft forever preferred_lft forever ip route show - (I commented out IP related on eth1 - my outside) 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 w.x.y.0/22 dev eth1 proto kernel scope link src w.x.y.z default via w.x.y.1 dev eth1 grep 205.251 /var/lib/shorewall/save DROP all -- 205.251.71.87 0.0.0.0/0 DROP all -- 205.251.103.140 0.0.0.0/0 DROP all -- 205.251.246.215 0.0.0.0/0 DROP all -- 205.251.64.69 0.0.0.0/0 DROP all -- 205.251.179.185 0.0.0.0/0 shorewall show log Shorewall-2.0.14 Log at yosemite - Mon Jan 10 11:02:16 NST 2005 Counters reset Sat Jan 8 21:01:36 NST 2005 Jan 10 10:56:25 net_dnat:REDIRECT:IN=eth1 OUT= SRC=205.251.179.185 DST=w.x.y.z LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=2731 DF PROTO=TCP SPT=4128 DPT=2745 WINDOW=16384 RES=0x00 SYN URGP=0 Jan 10 10:56:28 net_dnat:REDIRECT:IN=eth1 OUT= SRC=205.251.179.185 DST=w.x.y.z LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=3714 DF PROTO=TCP SPT=4128 DPT=2745 WINDOW=16384 RES=0x00 SYN URGP=0 Jan 10 10:56:34 net_dnat:REDIRECT:IN=eth1 OUT= SRC=205.251.179.185 DST=w.x.y.z LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=5408 DF PROTO=TCP SPT=4128 DPT=2745 WINDOW=16384 RES=0x00 SYN URGP=0 Notice that the IP 205.251.179.185 is in the save file (i.e. drop list), but it is still being allowed access via the REDIRECT to port 49999. Thanks in advance, Rod.
Hi, I have seen this come up in a couple of threads, but nothing recent. I was wondering a couple of things and was hoping someone could clarify. I have an existing working shorewall configuration (Details at end of post).>From within this config, I have a few ports redirected for use withportsentry (like the mini-howto directs forbidden port accesses to port 49999). This works correctly, and I receive notifications, and drops are saved to the /var/lib/shorewall/save file. It appeared as if everything is behgaving normally, but I wanted to know what ports people were hitting, so I turned on logging for the REDIRECT rules using REDIRECT:info. Once I did this, I see that dropped hosts are still redirected to the port 49999. Correct me if wrong, but wouldn''t it make sense that any dropped IP should never be allowed to hit the server? Shouldn''t it be immediately blocked if the shorewall drop x.x.x.x command was issued? Is this a behaviour that can be modified and if so, has anyone else done this or is there a howto to change this behaviour? I know in another post, Ted meantioned to a user he probably could use the start file to execute some script when starting shorewall. Would this work? Would it conflict with the existing shorewall drop/add? I would think that correcting the behaviour would be the more correct approach. Please, if anyone has a good solution, I''d like to know. Of courese, it''s possible I could be wrong, and the shorewall drop and REDIRECT functionality is behaving this way due to an option I have set or failed to set. If that''s the case, can anyone direct me to it? I''ve included the particulars for my setup below: shorewall version - 2.0.14 ip addr show - (I commented out IP on eth1 - my outside) 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:60:67:62:a0:c1 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0 inet6 fe80::260:67ff:fe62:a0c1/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 52:54:4c:04:a3:12 brd ff:ff:ff:ff:ff:ff inet w.x.y.z/22 brd w.x.y.255 scope global eth1 inet6 fe80::5054:4cff:fe04:a312/64 scope link valid_lft forever preferred_lft forever ip route show - (I commented out IP related on eth1 - my outside) 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 w.x.y.0/22 dev eth1 proto kernel scope link src w.x.y.z default via w.x.y.1 dev eth1 grep 205.251 /var/lib/shorewall/save DROP all -- 205.251.71.87 0.0.0.0/0 DROP all -- 205.251.103.140 0.0.0.0/0 DROP all -- 205.251.246.215 0.0.0.0/0 DROP all -- 205.251.64.69 0.0.0.0/0 DROP all -- 205.251.179.185 0.0.0.0/0 shorewall show log Shorewall-2.0.14 Log at yosemite - Mon Jan 10 11:02:16 NST 2005 Counters reset Sat Jan 8 21:01:36 NST 2005 Jan 10 10:56:25 net_dnat:REDIRECT:IN=eth1 OUT= SRC=205.251.179.185 DST=w.x.y.z LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=2731 DF PROTO=TCP SPT=4128 DPT=2745 WINDOW=16384 RES=0x00 SYN URGP=0 Jan 10 10:56:28 net_dnat:REDIRECT:IN=eth1 OUT= SRC=205.251.179.185 DST=w.x.y.z LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=3714 DF PROTO=TCP SPT=4128 DPT=2745 WINDOW=16384 RES=0x00 SYN URGP=0 Jan 10 10:56:34 net_dnat:REDIRECT:IN=eth1 OUT= SRC=205.251.179.185 DST=w.x.y.z LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=5408 DF PROTO=TCP SPT=4128 DPT=2745 WINDOW=16384 RES=0x00 SYN URGP=0 Notice that the IP 205.251.179.185 is in the save file (i.e. drop list), but it is still being allowed access via the REDIRECT to port 49999. Thanks in advance, Rod.
Roderick Greening wrote:> > > grep 205.251 /var/lib/shorewall/save > DROP all -- 205.251.71.87 0.0.0.0/0 > DROP all -- 205.251.103.140 0.0.0.0/0 > DROP all -- 205.251.246.215 0.0.0.0/0 > DROP all -- 205.251.64.69 0.0.0.0/0 > DROP all -- 205.251.179.185 0.0.0.0/0 > > shorewall show log > Shorewall-2.0.14 Log at yosemite - Mon Jan 10 11:02:16 NST 2005 > > Counters reset Sat Jan 8 21:01:36 NST 2005 > > Jan 10 10:56:25 net_dnat:REDIRECT:IN=eth1 OUT= SRC=205.251.179.185 > DST=w.x.y.z LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=2731 DF PROTO=TCP > SPT=4128 DPT=2745 WINDOW=16384 RES=0x00 SYN URGP=0 > Jan 10 10:56:28 net_dnat:REDIRECT:IN=eth1 OUT= SRC=205.251.179.185 > DST=w.x.y.z LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=3714 DF PROTO=TCP > SPT=4128 DPT=2745 WINDOW=16384 RES=0x00 SYN URGP=0 > Jan 10 10:56:34 net_dnat:REDIRECT:IN=eth1 OUT= SRC=205.251.179.185 > DST=w.x.y.z LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=5408 DF PROTO=TCP > SPT=4128 DPT=2745 WINDOW=16384 RES=0x00 SYN URGP=0 > > Notice that the IP 205.251.179.185 is in the save file (i.e. drop list), > but it is still being allowed access via the REDIRECT to port 49999.Filtering (including dynamic blacklisting) is done in the Netfilter ''filter'' table while REDIRECT occurs in the ''nat'' table. Logging of REDIRECT occurs in the ''nat'' table which is traversed prior to the ''filter'' table. If you look at the output of "shorewall show dynamic", you should see that the connection requests are being dropped in that chain. -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
Tom Eastep wrote:> > > Filtering (including dynamic blacklisting) is done in the Netfilter > ''filter'' table while REDIRECT occurs in the ''nat'' table. Logging of > REDIRECT occurs in the ''nat'' table which is traversed prior to the > ''filter'' table. > > If you look at the output of "shorewall show dynamic", you should see > that the connection requests are being dropped in that chain. >I might add that I originally logged REDIRECT/DNAT rules out of the ''filter'' table but people complained that they couldn''t see what the original connection request looked like. By logging these requests in the ''nat'' table, the pristine request is logged but there is no way to know if the modified request was later dropped or rejected via dynamic blacklisting. -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