Hello, I''m new to shorewall and new to the list. My question is related to aliased interface and the proper configuration of shorewall for my setup. I currently have a VPS running at linode and it has the following configuration: eth0 primary address is publicly routed eth0:1 is a private address and internal only What I''d like to do is: - limit traffic from the Internet to the FW (which is standard and makes sense). But I''d also like to - limit traffic on the private aliased interface as there are other VPS''s on that same network which have nothing to do with me. I want to limit traffic on the internal private network to only the VPS''s that I own and no others. I''ve played around with a few different configurations, but really don''t think I''m understanding what needs to happen here with respect to shorewall. From a firewall perspective it would seem simple enough to only allow traffic between my VPS''s on the backend network but I''m not having luck translating that... Currently I''ve got a one-to-one NAT setup from my Internet IP to the private IP. This is working great but I''m not sure what to do next. Was wondering is someone could point me in the right direction. I''d send my configuration but there really isn''t much to it. Like I said I''m using a basic configuration to do NAT and have three zones setup: fw, loc, and net. I''ve RTFM, esp the aliased interfaces page but still don''t think I''ve grokked how to setup the rules. Thanks for the help! -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Hi, I’m no Shorewall expert, so please regard this answer as possibly incomplete. I think I can help you a little with the aliased configuration, not with the NAT part. It’s important to understand that the aliased ‘interface’ actually isn’t a separate interface: eth0 and eth0:1 are regarded as the same thing. If you want to differentiate between them, you will have to specify an IP address in the SOURCE or DESTINATION column of the rules file. For example: # Public interface ACCEPT net $FW:12.34.56.78 icmp echo-request # Private interface DROP net $FW:98.76.54.32 icmp echo-request It is possible to create variables to hold the IP addresses in the Shorewall params file, for example: PUB_IP=12.34.56.78 PRV_IP=98.76.54.32 FW_PUB=fw:$PUB_IP FW_PRV=fw:$PRV_IP Then you could say: ACCEPT net $FW_PUB icmp echo-request DROP net $FW_PRV icmp echo-request Note that the 'fw' zone is mentioned in the variable declarations. This should be the same name as the firewall zone declared in the zones file. Hope this helps a little bit, Sascha Sanches From: Aaron St. Pierre Sent: Saturday, June 09, 2012 4:31 AM To: shorewall-users@lists.sourceforge.net Subject: [Shorewall-users] Aliased interfaces proper setup Hello, I'm new to shorewall and new to the list. My question is related to aliased interface and the proper configuration of shorewall for my setup. I currently have a VPS running at linode and it has the following configuration: eth0 primary address is publicly routed eth0:1 is a private address and internal only What I'd like to do is: - limit traffic from the Internet to the FW (which is standard and makes sense). But I'd also like to - limit traffic on the private aliased interface as there are other VPS's on that same network which have nothing to do with me. I want to limit traffic on the internal private network to only the VPS's that I own and no others. I've played around with a few different configurations, but really don't think I'm understanding what needs to happen here with respect to shorewall. From a firewall perspective it would seem simple enough to only allow traffic between my VPS's on the backend network but I'm not having luck translating that... Currently I've got a one-to-one NAT setup from my Internet IP to the private IP. This is working great but I'm not sure what to do next. Was wondering is someone could point me in the right direction. I'd send my configuration but there really isn't much to it. Like I said I'm using a basic configuration to do NAT and have three zones setup: fw, loc, and net. I've RTFM, esp the aliased interfaces page but still don't think I've grokked how to setup the rules. Thanks for the help! -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Sascha, Thanks a lot for this! It was exactly what I needed. The thing that I wasn''t getting was the zone. Since there is only one interface with two addressed defined everything will be coming from the NET zone. Your example makes perfect sense! As far as the NAT goes I''m still a bit confused since things like SSH/DROP net $FW_PUB does nothing. I guess that makes sense since it''s actually translating the address to $FW_PRV and this works: SSH/ACCEPT net $FW_PRV BUT I''ve found that SSH/DROP net $FW operates as I would expect and drops all SSH traffic to the host. My only other question is wouldn''t it make sense to differentiate this as a zone? Or does it follow that zones are separate networks on physically separate interfaces (and not aliased as in my case)? Thanks again Sascha your example was really helpful! On Sat, Jun 9, 2012 at 9:27 AM, Sascha Sanches <saschasanches@webdreamz.nl>wrote:> Hi, > > I’m no Shorewall expert, so please regard this answer as possibly > incomplete. I think I can help you a little with the aliased configuration, > not with the NAT part. > > It’s important to understand that the aliased ‘interface’ actually isn’t a > separate interface: eth0 and eth0:1 are regarded as the same thing. If you > want to differentiate between them, you will have to specify an IP address > in the SOURCE or DESTINATION column of the rules file. For example: > > # Public interface > ACCEPT net $FW:12.34.56.78 icmp echo-request > # Private interface > DROP net $FW:98.76.54.32 icmp echo-request > > It is possible to create variables to hold the IP addresses in the > Shorewall > params file, for example: > > PUB_IP=12.34.56.78 > PRV_IP=98.76.54.32 > > FW_PUB=fw:$PUB_IP > FW_PRV=fw:$PRV_IP > > Then you could say: > > ACCEPT net $FW_PUB icmp echo-request > DROP net $FW_PRV icmp echo-request > > Note that the ''fw'' zone is mentioned in the variable declarations. This > should be the same name as the firewall zone declared in the zones file. > > Hope this helps a little bit, > > Sascha Sanches > > > > From: Aaron St. Pierre > Sent: Saturday, June 09, 2012 4:31 AM > To: shorewall-users@lists.sourceforge.net > Subject: [Shorewall-users] Aliased interfaces proper setup > > Hello, > > I''m new to shorewall and new to the list. My question is related to aliased > interface and the proper configuration of shorewall for my setup. > > I currently have a VPS running at linode and it has the following > configuration: > > eth0 primary address is publicly routed > eth0:1 is a private address and internal only > > What I''d like to do is: > > - limit traffic from the Internet to the FW (which is standard and makes > sense). > > But I''d also like to > > - limit traffic on the private aliased interface as there are other VPS''s > on > that same network which have nothing to do with me. I want to limit traffic > on the internal private network to only the VPS''s that I own and no others. > > I''ve played around with a few different configurations, but really don''t > think I''m understanding what needs to happen here with respect to > shorewall. > From a firewall perspective it would seem simple enough to only allow > traffic between my VPS''s on the backend network but I''m not having luck > translating that... > > Currently I''ve got a one-to-one NAT setup from my Internet IP to the > private > IP. This is working great but I''m not sure what to do next. > > Was wondering is someone could point me in the right direction. I''d send my > configuration but there really isn''t much to it. Like I said I''m using a > basic configuration to do NAT and have three zones setup: fw, loc, and net. > I''ve RTFM, esp the aliased interfaces page but still don''t think I''ve > grokked how to setup the rules. > > Thanks for the help! > > -- > > Aaron > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >-- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/09/2012 07:32 AM, Aaron St. Pierre wrote:> > As far as the NAT goes I''m still a bit confused since things like > > SSH/DROP net $FW_PUB > > does nothing.What NAT rules do you have in place? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Hi Tom, I setup a one-to-one nat. Or at least that is what I think I did: [root@w1-atl shorewall]# more nat # # Shorewall version 4 - Nat File # # For information about entries in this file, type "man shorewall-nat" # # For additional information, see http://shorewall.net/NAT.htm # ############################################################################### #EXTERNAL INTERFACE INTERNAL ALL LOCAL # INTERFACES 64.22.y.y eth0:1 192.168.x.x no no On Sat, Jun 9, 2012 at 10:39 AM, Tom Eastep <teastep@shorewall.net> wrote:> On 06/09/2012 07:32 AM, Aaron St. Pierre wrote: > > > > > As far as the NAT goes I''m still a bit confused since things like > > > > SSH/DROP net $FW_PUB > > > > does nothing. > > What NAT rules do you have in place? > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >-- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/09/2012 07:45 AM, Aaron St. Pierre wrote:> Hi Tom, > > I setup a one-to-one nat. Or at least that is what I think I did: > > [root@w1-atl shorewall]# more nat > # > # Shorewall version 4 - Nat File > # > # For information about entries in this file, type "man shorewall-nat" > # > # For additional information, see http://shorewall.net/NAT.htm > # > ############################################################################### > #EXTERNAL INTERFACE INTERNAL ALL LOCAL > # INTERFACES > 64.22.y.y eth0:1 192.168.x.x no noThat means that no rule of the form XXX net $FW:66.22.y.y ... will ever match. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/09/2012 07:51 AM, Tom Eastep wrote:> > > That means that no rule of the form > > XXX net $FW:66.22.y.y ... > > will ever match. >Actually, that isn''t true. The rule will match if XXX is any of the following: ACCEPT+ DNAT NONAT REDIRECT -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Thanks Tom. Could you explain this a bit more or point me in the right direction to the documentation? On Sat, Jun 9, 2012 at 10:59 AM, Tom Eastep <teastep@shorewall.net> wrote:> On 06/09/2012 07:51 AM, Tom Eastep wrote: > > > > > > > That means that no rule of the form > > > > XXX net $FW:66.22.y.y ... > > > > will ever match. > > > > Actually, that isn''t true. The rule will match if XXX is any of the > following: > > ACCEPT+ > DNAT > NONAT > REDIRECT > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >-- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 06/09/2012 08:11 AM, Aaron St. Pierre wrote:> Thanks Tom. Could you explain this a bit more or point me in the right > direction to the documentation? >Please don''t top-post, Aaron. Refer to the diagram at http://www.shorewall.net/NetfilterOverview.html. Entries in /etc/shorewall/nat file add rules to the PREROUTING chain of the nat table. Those rules rewrite the destination IP address in the packet to the address of a host in your local network (192.168.x.x in your case). That means that when the ''routing decision'' occurs, the packet will be sent up through the FORWARD and POSTROUTING chains. With respect to the rules file, these will be controlled by rules of the form: XXX net loc:192.168.x.x proto port - 64.22.y.y which are added to the FORWARD chain of the filter table. Rules like this: DROP net $FW:... are added to the INPUT chain of the filter table. As noted above, packets that are NATted by /etc/shorewall/nat aren''t sent through that chain. The ACCEPT+, DNAT, NONAT and REDIRECT rules insert rules into the PREROUTING chain of the nat table *ahead of* the nat rules added by /etc/shorewall/nat. They therefore override those rules and can allow connections to be directed to the firewall rather than the system in the local network. HTH, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On Sat, Jun 9, 2012 at 11:29 AM, Tom Eastep <teastep@shorewall.net> wrote:> On 06/09/2012 08:11 AM, Aaron St. Pierre wrote: > > Thanks Tom. Could you explain this a bit more or point me in the right > > direction to the documentation? > > > > Please don''t top-post, Aaron. > > Refer to the diagram at http://www.shorewall.net/NetfilterOverview.html. > > Entries in /etc/shorewall/nat file add rules to the PREROUTING chain of > the nat table. Those rules rewrite the destination IP address in the > packet to the address of a host in your local network (192.168.x.x in > your case). That means that when the ''routing decision'' occurs, the > packet will be sent up through the FORWARD and POSTROUTING chains. With > respect to the rules file, these will be controlled by rules of the form: > > XXX net loc:192.168.x.x proto port - 64.22.y.y > > which are added to the FORWARD chain of the filter table. > > Rules like this: > > DROP net $FW:... > > are added to the INPUT chain of the filter table. As noted above, > packets that are NATted by /etc/shorewall/nat aren''t sent through that > chain. > > The ACCEPT+, DNAT, NONAT and REDIRECT rules insert rules into the > PREROUTING chain of the nat table *ahead of* the nat rules added by > /etc/shorewall/nat. They therefore override those rules and can allow > connections to be directed to the firewall rather than the system in the > local network. > > HTH, > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >Sorry about that Tom. Thanks for the awesome explanation! This is making much more sense to me now! Thanks again, -- Aaron ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/