I give up and need help! I won''t add to the confusion by showing all the combinations I have tried unsuccessfully... and yes, I''ve read FAQ2 and FAQ2a many times! When googling the subject of this post there are many answers that boil down to using the same three iptables rules, two of which use nat. I won''t repeat them here. I don''t want to risk mixing raw iptables and shorewall rules on my production (two interface) firewall, so I need to achieve the same or better using just shorewall. I accept this is generally not a good idea on a firewall, but a general solution would be useful on other kinds of linux host that can run shorewall. A simple example would be to run a web server under a safe user account, listening on port 8080, but allowing clients to access the web server via port 80. My situation is unconventional, but very similar to the general case. I have a rogue web client (not sure if it is buggy software or malware) that occasionally tries to connect to my firewall''s snat external ip address on port 80. The syn''s are rejected by my default policy "all all REJECT info" because there isn''t an explicit rule to permit that traffic - and, besides, it should not be allowed! Unfortunately, wireshark on the firewall and netstat on the client don''t give me enough information to track down the offending program. I have deployed a fake web server on the firewall (listening on port 8080 and running under a unprivileged account) whose only purpose is to log the http headers after the rogue connection is established. I tried using REDIRECT, but had trouble stopping it intercepting all legitimate external web accesses. I also had trouble specifying the target port and address. ACCEPT doesn''t seem to allow me to remap the port. The raw iptables solution seems to use nat, presumably because the nat PREROUTING target can remap the port - I don''t need to change the target ip address. Have I overlooked something simple? I''m asking for help because I''ve just realised I''m going in circles! Thanks for your patience, Brian ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Hi Brian, REDIRECT net 80 tcp 8080 (FAQ 1h) How do I set shorewall to allow ssh on port 9022 from net? SSHD is listening on port 22. *Answer*: Use this rule. #ACTION SOURCE DEST PROTO DEST # PORT(S) REDIRECT net 22 tcp 902 ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
(FAQ 1h) How do I set shorewall to allow ssh on port 9022 from net? SSHD is listening on port 22. *Answer*: Use this rule. #ACTION SOURCE DEST PROTO DEST # PORT(S) REDIRECT net 22 tcp 9022 On Thu, Oct 10, 2013 at 9:55 AM, johnny bowen <jbowen7@gmail.com> wrote:> Hi Brian, > > REDIRECT net 80 tcp 8080 > > > (FAQ 1h) How do I set shorewall to allow ssh on port 9022 from net? SSHD > is listening on port 22. > > *Answer*: Use this rule. > > #ACTION SOURCE DEST PROTO DEST > # PORT(S) > REDIRECT net 22 tcp 902 > >------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
On 10/10/13 17:55, johnny bowen wrote:> REDIRECT net 22 tcp 902Thanks for thinking about it Johnny, but I said in my first post that I couldn''t make REDIRECT work in my situation. Still, I don''t want to seem ungrateful, so I reconfigured as follows: REDIRECT loc 80 tcp 8080 I then tried to access the fake web server on the firewall in 4 different ways: * http://<outside snat ip address>:80 and http://<inside lan ip address>:80 both failed with Shorewall:loc2fw:REJECT log messages. * http://<outside snat ip address>:8080 and http://<inside lan ip address>:8080 fail to reply, but nothing is logged. My fake server is listening on 0.0.0.0:8080, and "wget http://127.0.0.1:8080" from the firewall itself works fine. The good news is that my genuine clients can still successfully access web servers on the internet (via the snat ip address on the firewall). I''m still confused! Brian ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Actually I typed my REDIRECT line wrong, for you it should have been this: REDIRECT loc:$ipOfBadMachine 8080 tcp 80 notice the 8080 and 80 are switched.. On Thu, Oct 10, 2013 at 10:52 AM, Brian Burch <brian@pingtoo.com> wrote:> On 10/10/13 17:55, johnny bowen wrote: > > REDIRECT net 22 tcp 902 > > Thanks for thinking about it Johnny, but I said in my first post that I > couldn''t make REDIRECT work in my situation. > > Still, I don''t want to seem ungrateful, so I reconfigured as follows: > > REDIRECT loc 80 tcp 8080 > > I then tried to access the fake web server on the firewall in 4 > different ways: > > * http://<outside snat ip address>:80 and http://<inside lan ip > address>:80 both failed with Shorewall:loc2fw:REJECT log messages. > > * http://<outside snat ip address>:8080 and http://<inside lan ip > address>:8080 fail to reply, but nothing is logged. > > My fake server is listening on 0.0.0.0:8080, and "wget > http://127.0.0.1:8080" from the firewall itself works fine. > > The good news is that my genuine clients can still successfully access > web servers on the internet (via the snat ip address on the firewall). > > > I''m still confused! > > Brian > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> On 10 Oct 2013, at 18:52, Brian Burch <brian@pingtoo.com> wrote: > >> On 10/10/13 17:55, johnny bowen wrote: >> REDIRECT net 22 tcp 902 > > Thanks for thinking about it Johnny, but I said in my first post that I > couldn''t make REDIRECT work in my situation.Isn''t it possible to restrict the scope of the redirect using the ORIGINAL_DEST column - e.g.: REDIRECT loc 80 tcp 8080 - 1.2.3.4 (I haven''t tried, so I may be off here) ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Woops, try this: REDIRECT loc:$ipOfOffendingMachine 8080 tcp 80 Notice the 8080, and 80 positions have switched.. On Thu, Oct 10, 2013 at 10:52 AM, Brian Burch <brian@pingtoo.com> wrote:> On 10/10/13 17:55, johnny bowen wrote: > > REDIRECT net 22 tcp 902 > > Thanks for thinking about it Johnny, but I said in my first post that I > couldn''t make REDIRECT work in my situation. > > Still, I don''t want to seem ungrateful, so I reconfigured as follows: > > REDIRECT loc 80 tcp 8080 > > I then tried to access the fake web server on the firewall in 4 > different ways: > > * http://<outside snat ip address>:80 and http://<inside lan ip > address>:80 both failed with Shorewall:loc2fw:REJECT log messages. > > * http://<outside snat ip address>:8080 and http://<inside lan ip > address>:8080 fail to reply, but nothing is logged. > > My fake server is listening on 0.0.0.0:8080, and "wget > http://127.0.0.1:8080" from the firewall itself works fine. > > The good news is that my genuine clients can still successfully access > web servers on the internet (via the snat ip address on the firewall). > > > I''m still confused! > > Brian > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Basically the bad redirect line REDIRECT loc 80 tcp 8080 adds a rule that listens for connections on 8080, then redirects to 80 on the fw. So to answer your test cases: 1) * http://<outside snat ip address>:80 and http://<inside lan ip address>:80 both failed with Shorewall:loc2fw:REJECT log messages. This failed because there is no rule for dst port 80, so it hit your policy REJECT 2) * http://<outside snat ip address>:8080 and http://<inside lan ip address>:8080 fail to reply, but nothing is logged. This failed because though a rule was found for 8080, it redirected it to port 80 on the firewall, but your httpd server is listening on 8080, not 80, so there is no reply. On Thu, Oct 10, 2013 at 11:17 AM, johnny bowen <jbowen7@gmail.com> wrote:> Actually I typed my REDIRECT line wrong, for you it should have been this: > > REDIRECT loc:$ipOfBadMachine 8080 tcp 80 > > notice the 8080 and 80 are switched.. > > > On Thu, Oct 10, 2013 at 10:52 AM, Brian Burch <brian@pingtoo.com> wrote: > >> On 10/10/13 17:55, johnny bowen wrote: >> > REDIRECT net 22 tcp 902 >> >> Thanks for thinking about it Johnny, but I said in my first post that I >> couldn''t make REDIRECT work in my situation. >> >> Still, I don''t want to seem ungrateful, so I reconfigured as follows: >> >> REDIRECT loc 80 tcp 8080 >> >> I then tried to access the fake web server on the firewall in 4 >> different ways: >> >> * http://<outside snat ip address>:80 and http://<inside lan ip >> address>:80 both failed with Shorewall:loc2fw:REJECT log messages. >> >> * http://<outside snat ip address>:8080 and http://<inside lan ip >> address>:8080 fail to reply, but nothing is logged. >> >> My fake server is listening on 0.0.0.0:8080, and "wget >> http://127.0.0.1:8080" from the firewall itself works fine. >> >> The good news is that my genuine clients can still successfully access >> web servers on the internet (via the snat ip address on the firewall). >> >> >> I''m still confused! >> >> Brian >> >> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> > >------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Sorry about the double post.. my browser crashed and I didn''t think it sent the message, so I opened up another browser and retyped the same woops message On Thu, Oct 10, 2013 at 11:24 AM, johnny bowen <jbowen7@gmail.com> wrote:> Basically the bad redirect line REDIRECT loc 80 tcp 8080 > adds a rule that listens for connections on 8080, then redirects to 80 on > the fw. > > So to answer your test cases: > 1) > > * http://<outside snat ip address>:80 and http://<inside lan ip > address>:80 both failed with Shorewall:loc2fw:REJECT log messages. > > This failed because there is no rule for dst port 80, so it hit your > policy REJECT > > 2) > * http://<outside snat ip address>:8080 and http://<inside lan ip > address>:8080 fail to reply, but nothing is logged. > > This failed because though a rule was found for 8080, it redirected it to > port 80 on the firewall, but your httpd server is listening on 8080, not > 80, so there is no reply. > > > On Thu, Oct 10, 2013 at 11:17 AM, johnny bowen <jbowen7@gmail.com> wrote: > >> Actually I typed my REDIRECT line wrong, for you it should have been this: >> >> REDIRECT loc:$ipOfBadMachine 8080 tcp 80 >> >> notice the 8080 and 80 are switched.. >> >> >> On Thu, Oct 10, 2013 at 10:52 AM, Brian Burch <brian@pingtoo.com> wrote: >> >>> On 10/10/13 17:55, johnny bowen wrote: >>> > REDIRECT net 22 tcp 902 >>> >>> Thanks for thinking about it Johnny, but I said in my first post that I >>> couldn''t make REDIRECT work in my situation. >>> >>> Still, I don''t want to seem ungrateful, so I reconfigured as follows: >>> >>> REDIRECT loc 80 tcp 8080 >>> >>> I then tried to access the fake web server on the firewall in 4 >>> different ways: >>> >>> * http://<outside snat ip address>:80 and http://<inside lan ip >>> address>:80 both failed with Shorewall:loc2fw:REJECT log messages. >>> >>> * http://<outside snat ip address>:8080 and http://<inside lan ip >>> address>:8080 fail to reply, but nothing is logged. >>> >>> My fake server is listening on 0.0.0.0:8080, and "wget >>> http://127.0.0.1:8080" from the firewall itself works fine. >>> >>> The good news is that my genuine clients can still successfully access >>> web servers on the internet (via the snat ip address on the firewall). >>> >>> >>> I''m still confused! >>> >>> Brian >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >>> from >>> the latest Intel processors and coprocessors. See abstracts and register >>> > >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Shorewall-users mailing list >>> Shorewall-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/shorewall-users >>> >> >> >------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Dominic,
With the orginal destination column you can restrict the scope of
''traffic
to'', not ''traffic from''. In his case he''s
looking to trap some packets from
''traffic from'' .
I think the following example explains it better:
Example 5:All http requests from the internet to address 130.252.100.69 are
to be forwarded to 192.168.1.3
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69
On Thu, Oct 10, 2013 at 11:18 AM, Dominic Benson
<dominic@lenny.cus.org>wrote:
>
> > On 10 Oct 2013, at 18:52, Brian Burch <brian@pingtoo.com> wrote:
> >
> >> On 10/10/13 17:55, johnny bowen wrote:
> >> REDIRECT net 22 tcp 902
> >
> > Thanks for thinking about it Johnny, but I said in my first post that
I
> > couldn''t make REDIRECT work in my situation.
>
> Isn''t it possible to restrict the scope of the redirect using the
> ORIGINAL_DEST column - e.g.:
>
> REDIRECT loc 80 tcp 8080 - 1.2.3.4
>
> (I haven''t tried, so I may be off here)
>
>
>
>
------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register
>
>
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> On 10 Oct 2013, at 20:45, johnny bowen <jbowen7@gmail.com> wrote: > > Dominic, > > With the orginal destination column you can restrict the scope of ''traffic to'', not ''traffic from''. In his case he''s looking to trap some packets from ''traffic from'' .I thought from the original post that the *source* of the offending requests was unknown. Restricting traffic to would prevent redirection of requests to other port 80 services.> > I think the following example explains it better: > > Example 5: > All http requests from the internet to address 130.252.100.69 are to be forwarded to 192.168.1.3 > #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL > # PORT PORT(S) DEST > DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69 > > >> On Thu, Oct 10, 2013 at 11:18 AM, Dominic Benson <dominic@lenny.cus.org> wrote: >> >> > On 10 Oct 2013, at 18:52, Brian Burch <brian@pingtoo.com> wrote: >> > >> >> On 10/10/13 17:55, johnny bowen wrote: >> >> REDIRECT net 22 tcp 902 >> > >> > Thanks for thinking about it Johnny, but I said in my first post that I >> > couldn''t make REDIRECT work in my situation. >> >> Isn''t it possible to restrict the scope of the redirect using the ORIGINAL_DEST column - e.g.: >> >> REDIRECT loc 80 tcp 8080 - 1.2.3.4 >> >> (I haven''t tried, so I may be off here) >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
It sounded like he knew the offending machine, not the offending program. On Thu, Oct 10, 2013 at 2:51 PM, Dominic Benson <dominic@lenny.cus.org>wrote:> > > On 10 Oct 2013, at 20:45, johnny bowen <jbowen7@gmail.com> wrote: > > Dominic, > > With the orginal destination column you can restrict the scope of ''traffic > to'', not ''traffic from''. In his case he''s looking to trap some packets from > ''traffic from'' . > > > I thought from the original post that the *source* of the offending > requests was unknown. > > Restricting traffic to would prevent redirection of requests to other port > 80 services. > > > > I think the following example explains it better: > > Example 5: All http requests from the internet to address 130.252.100.69are to be forwarded to 192.168.1.3 > > #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL > # PORT PORT(S) DEST > DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69 > > > > On Thu, Oct 10, 2013 at 11:18 AM, Dominic Benson <dominic@lenny.cus.org>wrote: > >> >> > On 10 Oct 2013, at 18:52, Brian Burch <brian@pingtoo.com> wrote: >> > >> >> On 10/10/13 17:55, johnny bowen wrote: >> >> REDIRECT net 22 tcp 902 >> > >> > Thanks for thinking about it Johnny, but I said in my first post that I >> > couldn''t make REDIRECT work in my situation. >> >> Isn''t it possible to restrict the scope of the redirect using the >> ORIGINAL_DEST column - e.g.: >> >> REDIRECT loc 80 tcp 8080 - 1.2.3.4 >> >> (I haven''t tried, so I may be off here) >> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
I''m in the UK and have been asleep, so I apologise if it seems I was
ignoring your suggestions.
This post should bring everyone up to date, but it means I will have to
top-post so that my reply makes chronological sense.
1. I''ve been there before, but I reconfigured like this:
REDIRECT loc 8080 tcp 80
Yes, this properly intercepts request to port 80 and sends them to the
web server running on the firewall and listening to port 8080.
No good though, because REDIRECT is completely indiscriminate... ANY
port 80 connection from the loc zone to ANY host in the net zone will be
sent to port 8080 on the firewall. This is what REDIRECT does, but not
what I need - it is FAR too blunt an instrument.
2. I don''t know how to use the ORIGINAL DEST in my situation, because I
ONLY want to catch port 80 connections to one of the firewall
interfaces, while allowing all legitimate web traffic through for
masquerading.
3. Qualifying the SOURCE, e.g. "loc:10.1.252.200" isn''t
really relevant
in my case, because my "fake" web server would let me know whether I
have more than one trusted host that is misbehaving.
4. I really need to specify the ORIGINAL DEST as either $FW, or the
specific address of the ip address used by the firewall for its snat
traffic. I tried this:
REDIRECT loc 8080 tcp 80 -
217.154.193.215
and was surprised to discover it works the way I wanted - I /thought/I
had tried it before, but must have made a mistake.
This rule properly intercepts the rogue traffic from any host in the loc
zone, while masquerading all port 80 datagrams sent to the new zone.
Not surprisingly, I could also use my symbolic from the params file:
REDIRECT loc 8080 tcp 80 -
$INTERNET_CLIENTS
5. Just to learn more, I tried to intercept port 80 requests to ANY of
the firewall ip addresses, like this:
REDIRECT loc 8080 tcp 80 -
$FW
but it would not compile:
ERROR: Unknown Interface (fw) /etc/shorewall/rules (line 132)
6. I tried adding the firewall''s safe lan interface:
REDIRECT loc 8080 tcp 80 -
$INTERNET_CLIENTS,eth1
but that would not compile:
WARNING: Ipset eth1 does not exist /etc/shorewall/rules (line 138)
ERROR: Unknown Host (eth1) /etc/shorewall/rules (line 138)
... so I defined another param for that interface, which works fine:
REDIRECT loc 8080 tcp 80 -
$INTERNET_CLIENTS,$FW_ETH1
To summarise, rules 4a and 4b work for me. Thanks very much for your
help, Johnny and Dominic.
Regards,
Brian
On 10/10/13 20:45, johnny bowen wrote:> Dominic,
>
> With the orginal destination column you can restrict the scope of
> ''traffic to'', not ''traffic from''. In
his case he''s looking to trap some
> packets from ''traffic from'' .
>
> I think the following example explains it better:
>
> Example 5:
> All http requests from the internet to address 130.252.100.69 are to be
> forwarded to 192.168.1.3
>
> #ACTION SOURCE DEST PROTO DEST SOURCE
ORIGINAL
> # PORT PORT(S) DEST
> DNAT net loc:192.168.1.3 tcp 80 -
130.252.100.69
>
>
>
> On Thu, Oct 10, 2013 at 11:18 AM, Dominic Benson <dominic@lenny.cus.org
> <mailto:dominic@lenny.cus.org>> wrote:
>
>
> > On 10 Oct 2013, at 18:52, Brian Burch <brian@pingtoo.com
> <mailto:brian@pingtoo.com>> wrote:
> >
> >> On 10/10/13 17:55, johnny bowen wrote:
> >> REDIRECT net 22 tcp 902
> >
> > Thanks for thinking about it Johnny, but I said in my first post
> that I
> > couldn''t make REDIRECT work in my situation.
>
> Isn''t it possible to restrict the scope of the redirect using
the
> ORIGINAL_DEST column - e.g.:
>
> REDIRECT loc 80 tcp 8080 - 1.2.3.4
>
> (I haven''t tried, so I may be off here)
>
>
>
------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from
> the latest Intel processors and coprocessors. See abstracts and
> register >
>
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> <mailto:Shorewall-users@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
>
>
>
>
------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
> the latest Intel processors and coprocessors. See abstracts and register
>
>
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Glad we could help you. Thanks Dominic, I just had a big "duh" moment regarding original dest. On Oct 11, 2013 12:39 AM, "Brian Burch" <brian@pingtoo.com> wrote:> I''m in the UK and have been asleep, so I apologise if it seems I was > ignoring your suggestions. > > This post should bring everyone up to date, but it means I will have to > top-post so that my reply makes chronological sense. > > 1. I''ve been there before, but I reconfigured like this: > > REDIRECT loc 8080 tcp 80 > > Yes, this properly intercepts request to port 80 and sends them to the > web server running on the firewall and listening to port 8080. > > No good though, because REDIRECT is completely indiscriminate... ANY > port 80 connection from the loc zone to ANY host in the net zone will be > sent to port 8080 on the firewall. This is what REDIRECT does, but not > what I need - it is FAR too blunt an instrument. > > 2. I don''t know how to use the ORIGINAL DEST in my situation, because I > ONLY want to catch port 80 connections to one of the firewall > interfaces, while allowing all legitimate web traffic through for > masquerading. > > 3. Qualifying the SOURCE, e.g. "loc:10.1.252.200" isn''t really relevant > in my case, because my "fake" web server would let me know whether I > have more than one trusted host that is misbehaving. > > 4. I really need to specify the ORIGINAL DEST as either $FW, or the > specific address of the ip address used by the firewall for its snat > traffic. I tried this: > > REDIRECT loc 8080 tcp 80 - > 217.154.193.215 > > and was surprised to discover it works the way I wanted - I /thought/I > had tried it before, but must have made a mistake. > > This rule properly intercepts the rogue traffic from any host in the loc > zone, while masquerading all port 80 datagrams sent to the new zone. > > Not surprisingly, I could also use my symbolic from the params file: > REDIRECT loc 8080 tcp 80 - > $INTERNET_CLIENTS > > 5. Just to learn more, I tried to intercept port 80 requests to ANY of > the firewall ip addresses, like this: > > REDIRECT loc 8080 tcp 80 - > $FW > > but it would not compile: > ERROR: Unknown Interface (fw) /etc/shorewall/rules (line 132) > > 6. I tried adding the firewall''s safe lan interface: > REDIRECT loc 8080 tcp 80 - > $INTERNET_CLIENTS,eth1 > > but that would not compile: > WARNING: Ipset eth1 does not exist /etc/shorewall/rules (line 138) > ERROR: Unknown Host (eth1) /etc/shorewall/rules (line 138) > > ... so I defined another param for that interface, which works fine: > REDIRECT loc 8080 tcp 80 - > $INTERNET_CLIENTS,$FW_ETH1 > > > To summarise, rules 4a and 4b work for me. Thanks very much for your > help, Johnny and Dominic. > > Regards, > > Brian > > > On 10/10/13 20:45, johnny bowen wrote: > > Dominic, > > > > With the orginal destination column you can restrict the scope of > > ''traffic to'', not ''traffic from''. In his case he''s looking to trap some > > packets from ''traffic from'' . > > > > I think the following example explains it better: > > > > Example 5: > > All http requests from the internet to address 130.252.100.69 are to be > > forwarded to 192.168.1.3 > > > > #ACTION SOURCE DEST PROTO DEST SOURCE > ORIGINAL > > # PORT PORT(S) DEST > > DNAT net loc:192.168.1.3 tcp 80 - > 130.252.100.69 > > > > > > > > On Thu, Oct 10, 2013 at 11:18 AM, Dominic Benson <dominic@lenny.cus.org > > <mailto:dominic@lenny.cus.org>> wrote: > > > > > > > On 10 Oct 2013, at 18:52, Brian Burch <brian@pingtoo.com > > <mailto:brian@pingtoo.com>> wrote: > > > > > >> On 10/10/13 17:55, johnny bowen wrote: > > >> REDIRECT net 22 tcp 902 > > > > > > Thanks for thinking about it Johnny, but I said in my first post > > that I > > > couldn''t make REDIRECT work in my situation. > > > > Isn''t it possible to restrict the scope of the redirect using the > > ORIGINAL_DEST column - e.g.: > > > > REDIRECT loc 80 tcp 8080 - 1.2.3.4 > > > > (I haven''t tried, so I may be off here) > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > > most from > > the latest Intel processors and coprocessors. See abstracts and > > register > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > > _______________________________________________ > > Shorewall-users mailing list > > Shorewall-users@lists.sourceforge.net > > <mailto:Shorewall-users@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > > the latest Intel processors and coprocessors. See abstracts and register > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Shorewall-users mailing list > > Shorewall-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
Brian Burch
2013-Oct-11 16:57 UTC
Re: Remapping port below 1024 on the firewall (epilogue)
On 10/10/13 16:19, Brian Burch wrote:> My situation is unconventional, but very similar to the general case. I > have a rogue web client (not sure if it is buggy software or malware) > that occasionally tries to connect to my firewall's snat external ip > address on port 80. The syn's are rejected by my default policy "all all > REJECT info" because there isn't an explicit rule to permit that traffic > - and, besides, it should not be allowed! > > Unfortunately, wireshark on the firewall and netstat on the client don't > give me enough information to track down the offending program. I have > deployed a fake web server on the firewall (listening on port 8080 and > running under a unprivileged account) whose only purpose is to log the > http headers after the rogue connection is established.Gotcha! My fake web server trapped the rogue connection attempt. It was the Firefox NoScript plugin! --- Client.: /10.1.252.200:56934 --- URI....: / --- Method.: GET --- Headers: {cache-control=no-cache, connection=keep-alive, host=217.154.193.215, user-agent=Mozilla/5.0 (ABE, http://noscript.net/abe/wan), pragma=no-cache} Digging a little tookme to: http://hackademix.net/2010/07/28/abe-patrols-the-routes-to-your-routers/ <quote>Many routers will respond to requests to their public ip on the private interface. This allows an external site not merely to load the router config in an iframe by ip (without triggerring ABE LOCAL rule) but also by the site’s name (by dynamically dns binding it to the router’s public ip), thereby bypassing same origin check and gaining access to the router. I suppose NoScript could (optionally) lookup the public ip and include it in the abe LOCAL pseudo-list. And so it does now :) Since version 2.0rc5, released past week, NoScript detects your public (WAN) IP by sending a completely anonymous query on a secure channel to https://secure.informaction.com/ipecho, then treats it as a local address when enforcing its policies against CSRF and DNS Rebinding. There are a few optimizations, meant to reduce the traffic to less than two hundreds of bytes per user per day (and prevent my servers from melting down), but if you do notice this background request, now you know what it is about (it is also mentioned in the NoScript’s Privacy Policy, BTW). This new feature, enabled by default, can be disabled at any time by clearing the NoScript Options|Advanced|ABE|WAN IP ∈ LOCAL checkbox *.</quote> I'm satisfied with that explanation. Brian ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
johnny bowen
2013-Oct-11 17:08 UTC
Re: Remapping port below 1024 on the firewall (epilogue)
I''m really glad you posted that epilog. I actually woke up this morning thinking about what you might find. Thanks. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk