Hi all. The Shorewall documentation states: "If all you want to do is forward ports to servers behind your firewall, you do NOT want to use one-to-one NAT. Port forwarding can be accomplished with simple entries in the rules file. Also, in most cases Proxy ARP provides a superior solution to one-to-one NAT because the internal systems are accessed using the same IP address internally and externally." What it does not include is, when SHOULD you use one-to-one NAT? Are there situations where one-to-one NAT is a better choise than basic port forwarding or Proxy ARP? Thanks --Dan
On Thursday 11 March 2004 07:12 am, Dan Delaney wrote:> Hi all. The Shorewall documentation states: > > "If all you want to do is forward ports to servers behind your > firewall, you do NOT want to use one-to-one NAT. Port forwarding can > be accomplished with simple entries in the rules file. Also, in most > cases Proxy ARP provides a superior solution to one-to-one NAT > because the internal systems are accessed using the same IP address > internally and externally." > > > What it does not include is, when SHOULD you use one-to-one NAT? Are > there situations where one-to-one NAT is a better choise than basic > port forwarding or Proxy ARP?Dan, The documentation goes on to say: One-to-one NAT is a way to make systems behind a firewall and configured with private IP addresses (those reserved for private use in RFC 1918) appear to have public IP addresses. So if the local system is part of an RFC 1918 network, changing it''s IP address in order to use Proxy ARP makes it awkward for that system to access the other hosts on the same physical LAN. In that case, one-on-one NAT is a better solution. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> So if the local system is part of an RFC 1918 network, changing it''s IP > address in order to use Proxy ARP makes it awkward for that system to access > the other hosts on the same physical LAN. In that case, one-on-one NAT is a > better solution.Dig it! Thanks. That''s the explanation I was looking for on when to use one-to-one NAT instead of Proxy ARP. What about using port forwarding in the rules file? If I have a server with a private (RFC1918) address and I want SSH, DNS, WWW, and SMTP connections to one of my public addresses to go to that private server, wouldn''t port forwarding also make it look to the outside world that the internal server had a public address? (Jeez, that''s a mouthful!) --Dan
On Thursday 11 March 2004 07:56 am, Dan Delaney wrote:> Tom Eastep wrote: > > So if the local system is part of an RFC 1918 network, changing it''s IP > > address in order to use Proxy ARP makes it awkward for that system to > > access the other hosts on the same physical LAN. In that case, one-on-one > > NAT is a better solution. > > Dig it! Thanks. That''s the explanation I was looking for on when to > use one-to-one NAT instead of Proxy ARP. > > What about using port forwarding in the rules file? If I have a > server with a private (RFC1918) address and I want SSH, DNS, WWW, > and SMTP connections to one of my public addresses to go to that > private server, wouldn''t port forwarding also make it look to the > outside world that the internal server had a public address? (Jeez, > that''s a mouthful!)Partly. Any outbound connections made by that internal server still appear to the outside world to come from the address used for SNAT/MASQUERADE of the local network. Also, if you have a large number of DNAT rules, it is a bit more efficient to use one-to-one NAT and the same number of ACCEPT rules. That''s because each DNAT rule generates a nat table rule wnile one-to-one NAT generates a single nat table rule for all traffic sent to the specified external IP address. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Hi everybody.
The April issue of Linux Journal has an article about cool things
you can do with iptables. One of those things is to set up a port as
a TARPIT, which doesn''t let go of the connection that an attacker
establishes. Here''s an example they give:
iptables -A INPUT -p tcp -m tcp -m mport \
--dports 135,139,1025 -j TARPIT
Interesting idea, and I wouldn''t mind doing that to all the dorks
who keep trying to connect to Windows Networking and SQL Server
ports on my FreeBSD box! Is there any way to specify this in Shorewall?
Thanks
--Dan
On Tuesday 16 March 2004 07:58 am, Dan Delaney wrote:> Hi everybody. > > The April issue of Linux Journal has an article about cool things > you can do with iptables. One of those things is to set up a port as > a TARPIT, which doesn''t let go of the connection that an attacker > establishes. Here''s an example they give: > > iptables -A INPUT -p tcp -m tcp -m mport \ > --dports 135,139,1025 -j TARPIT > > Interesting idea, and I wouldn''t mind doing that to all the dorks > who keep trying to connect to Windows Networking and SQL Server > ports on my FreeBSD box! Is there any way to specify this in Shorewall? >No. The TARPIT target isn''t available in standard kernels from kernel.org and hence Shorewall has no support for it. You can of course use extension scripts to add your own rules of the above type -- be sure to read the extension script documentation carefully because simply placing the above command in an extension script won''t work. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 16 March 2004 07:58 am, Dan Delaney wrote:> Hi everybody. > > The April issue of Linux Journal has an article about cool things > you can do with iptables. One of those things is to set up a port as > a TARPIT, which doesn''t let go of the connection that an attacker > establishes. Here''s an example they give: > > iptables -A INPUT -p tcp -m tcp -m mport \ > --dports 135,139,1025 -j TARPIT > > Interesting idea, and I wouldn''t mind doing that to all the dorks > who keep trying to connect to Windows Networking and SQL Server > ports on my FreeBSD box! Is there any way to specify this in > Shorewall?Wow.. Now that sounds very crafty. Please keep the list informed of your progress. I don''t know much about Snort but it would almost seem that fits the job description.. Venus Fly(Crack) Trap. With the way my connection is on Comcast I would have to have a machine soley dedicated to just this task. The Cpu would need to be refrigarated for sure.. Joshua Banks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAWo/lp9X7q/XgeyYRAtNdAJ9lktjJoAhVO8SPMQeYQdHrIGiACQCdHSIW fmbpDWpq8BJIRNgcpUCM8ho=7yUB -----END PGP SIGNATURE-----
Joshua Banks wrote:> Wow.. Now that sounds very crafty. Please keep the list informed of your > progress. I don''t know much about Snort but it would almost seem that > fits the job description.. Venus Fly(Crack) Trap. With the way my > connection is on Comcast I would have to have a machine soley dedicated > to just this task. The Cpu would need to be refrigarated for sure..Hahaha. I''ll do that. I''d like to get it set up. There''s a great article about it here: http://www.securityfocus.com/infocus/1723. Apparently the TARPIT patch for netfilter was fairly new back in August of 2003 when the article was written, so by now more distros should have it included in the kernel (gentoo had it at the time of that article). I''m using the SentryFirewallCD for my system but haven''t checked to see if he has included the TARPIT patch. --Dan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 19 March 2004 07:49 am, Dan Delaney wrote: http://www.securityfocus.com/infocus/1723. Cool. Thanks. I run Gentoo on two systems right now. I''ll let you know if I ever decide to mess around with this. Thanks, Joshua Banks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAW96qp9X7q/XgeyYRAvsbAJ9DH1K4jmF11ExdHF6a6XaNIC8n1gCfRSGz cQK0gsBHtvFA9OgjraH5c9Q=mREU -----END PGP SIGNATURE-----