Sponsored Content
Special Forums Cybersecurity DMZ systems having internal IP, ok or not? Post 302501946 by Neo on Saturday 5th of March 2011 11:14:28 PM
Old 03-06-2011
The answer is yes and yes; but your questions are too vague for a definitive answer.

First of all, if you are going to ask questions about assigning IP addresses to servers, shouldn't you name the hardware and software you are using?

Second, what does "security issues" mean? This has no meaning because it is just a vague statement without any context.

If you want to discuss security topics, please be very specific. Thanks!
 

9 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

Forwarding internal internet packets to internal webserver using iptables

Hi, I need to redirect internal internet requests to a auth client site siting on the gateway. Currently users that are authenticated to access the internet have there mac address listed in the FORWARD chain. All other users need to be redirected to a internal site for authentication. Can... (1 Reply)
Discussion started by: mshindo
1 Replies

2. Linux

routing rules for dmz in debian router.

Hi to all. There are eth0(wan) eth1(lan) and eth3(dmz) in my debian router. In dmz is planing dns, ad, dhcp, smtp/pop/imap, https(web-based imap client). I don't configured rules on "iptables" and "route" loads for right relation lan clients with dmz services. Please explain me example... (0 Replies)
Discussion started by: sotich82
0 Replies

3. UNIX for Advanced & Expert Users

How do you manage your DMZ server accounts?

I'd just like to know what you use for user account management on your DMZ servers? Do you use the same authentication realm as internally? Do you use a different authentication realm, perhaps only for the DMZ? Do you use local accounts? (2 Replies)
Discussion started by: humbletech99
2 Replies

4. Solaris

Setting up a DMZ webserver using Zones

I've been looking at various articles about Zones/Containers, from SUN's website, and through numerous Google searches, and although there's a lot of info out there, I've not got a definitive answer for what I'd like to do.....so here we go..... I'm installing a webserver, which is sitting on a... (3 Replies)
Discussion started by: in2deep
3 Replies

5. Shell Programming and Scripting

SFTP and DMZ boxes

Hi I would like write a script that will do sftp frm a box that resides inside the FW to a box that resides in DMZ.Any ideas guys.I tried generating rsa keys for a particular user, however just want to know is there any other solution or not. Your help is much appreciated. Thanks CK (2 Replies)
Discussion started by: coolkid
2 Replies

6. What is on Your Mind?

From Systems Admin to Systems Eng.

I have been wondering how do Systems Administrators do the jump into Systems Engineering? Is it only a matter of time and experience or could I actually help myself get there? Opinions? Books I could read? Thanks a lot for your help! (0 Replies)
Discussion started by: svalenciatech
0 Replies

7. Shell Programming and Scripting

Create new users in DMZ box using script

I remote to many DMZ boxes every day to run batch file that allows me to create users. I create users in 17 DMZ boxes every day which takes a lot of my time. Is there any script that would do this job from my local computer? Thank you for your help! (3 Replies)
Discussion started by: idiazza
3 Replies

8. UNIX and Linux Applications

One DMZ server reverse proxy for 2 websites

Hi All, Hope this is the correct thread to ask this, if not, can an admin please move it to the correct thread. Got a wee problem I hope someone can point me in the right direction. I have Network A with two servers hosting separate webpages (I will call these WP1 & WP2). A DMZ server... (6 Replies)
Discussion started by: dakelly
6 Replies

9. UNIX for Beginners Questions & Answers

Sendmail - issue within DMZ for some servers but not all

Hi All, I have a strange issue and I am not sure where the problem lies. I have about six Ubuntu servers on our DMZ two of which were built on 18.04 from scratch the others were upgraded to 18.04 from 16.04. The servers built from scratch can send emails from the server via sendmail fine, so... (4 Replies)
Discussion started by: dakelly
4 Replies
SHOREWALL-NESTING(5)						  [FIXME: manual]					      SHOREWALL-NESTING(5)

NAME
nesting - Shorewall Nested Zones SYNOPSIS
child-zone[:parent-zone[,parent-zone]...] DESCRIPTION
In shorewall-zones[1](5), a zone may be declared to be a sub-zone of one or more other zones using the above syntax. The child-zone may be neither the firewall zone nor a vserver zone. The firewall zone may not appear as a parent zone, although all vserver zones are handled as sub-zones of the firewall zone. Where zones are nested, the CONTINUE policy in shorewall-policy[2](5) allows hosts that are within multiple zones to be managed under the rules of all of these zones. EXAMPLE
/etc/shorewall/zones: #ZONE TYPE OPTION fw firewall net ipv4 sam:net ipv4 loc ipv4 /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - eth0 detect dhcp,norfc1918 loc eth1 detect /etc/shorewall/hosts: #ZONE HOST(S) OPTIONS net eth0:0.0.0.0/0 sam eth0:206.191.149.197 /etc/shorewall/policy: #SOURCE DEST POLICY LOG LEVEL loc net ACCEPT sam all CONTINUE net all DROP info all all REJECT info The second entry above says that when Sam is the client, connection requests should first be processed under rules where the source zone is sam and if there is no match then the connection request should be treated under rules where the source zone is net. It is important that this policy be listed BEFORE the next policy (net to all). You can have this policy generated for you automatically by using the IMPLICIT_CONTINUE option in shorewall.conf[3](5). Partial /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) ... DNAT sam loc:192.168.1.3 tcp ssh DNAT net loc:192.168.1.5 tcp www ... Given these two rules, Sam can connect to the firewall's internet interface with ssh and the connection request will be forwarded to 192.168.1.3. Like all hosts in the net zone, Sam can connect to the firewall's internet interface on TCP port 80 and the connection request will be forwarded to 192.168.1.5. The order of the rules is not significant. Sometimes it is necessary to suppress port forwarding for a sub-zone. For example, suppose that all hosts can SSH to the firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects to the firewall's external IP, he should be connected to the firewall itself. Because of the way that Netfilter is constructed, this requires two rules as follows: #ACTION SOURCE DEST PROTO DEST PORT(S) ... ACCEPT+ sam $FW tcp ssh DNAT net loc:192.168.1.3 tcp ssh ... The first rule allows Sam SSH access to the firewall. The second rule says that any clients from the net zone with the exception of those in the "sam" zone should have their connection port forwarded to 192.168.1.3. If you need to exclude more than one zone, simply use multiple ACCEPT+ rules. This technique also may be used when the ACTION is REDIRECT. Care must be taken when nesting occurs as a result of the use of wildcard interfaces (interface names ends in '+'). Here's an example. /etc/shorewall/zones: /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net ppp0 loc eth1 loc ppp+ dmz eth2 Because the net zone is declared before the loc zone, net is an implicit sub-zone of loc and in the absence of a net->... CONTINUE policy, traffic from the net zone will not be passed through loc->... rules. But DNAT and REDIRECT rules are an exception! o DNAT and REDIRECT rules generate two Netfilter rules: a 'nat' table rule that rewrites the destination IP address and/or port number, and a 'filter' table rule that ACCEPTs the rewritten connection. o Policies only affect the 'filter' table. As a consequence, the following rules will have unexpected behavior: #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT net dmz tcp 80 REDIRECT loc 3128 tcp 80 The second rule is intended to redirect local web requests to a proxy running on the firewall and listening on TCP port 3128. But the 'nat' part of that rule will cause all connection requests for TCP port 80 arriving on interface ppp+ (including ppp0!) to have their destination port rewritten to 3128. Hence, the web server running in the DMZ will be inaccessible from the web. The above problem can be corrected in several ways. The preferred way is to use the ifname pppd option to change the 'net' interface to something other than ppp0. That way, it won't match ppp+. If you are running Shorewall version 4.1.4 or later, a second way is to simply make the nested zones explicit: #ZONE TYPE OPTION fw firewall loc ipv4 net:loc ipv4 dmz ipv4 If you take this approach, be sure to set IMPLICIT_CONTINUE=No in shorewall.conf. When using other Shorewall versions, another way is to rewrite the DNAT rule (assume that the local zone is entirely within 192.168.2.0/23): #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT net dmz tcp 80 REDIRECT loc:192.168.2.0/23 3128 tcp 80 Another way is to restrict the definition of the loc zone: /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net ppp0 loc eth1 - ppp+ dmz eth2 /etc/shorewall/hosts: #ZONE HOST(S) OPTIONS loc ppp+:192.168.2.0/23 FILES
/etc/shorewall/zones /etc/shorewall/interfaces /etc/shorewall/hosts /etc/shorewall/policy /etc/shorewall/rules SEE ALSO
shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) NOTES
1. shorewall-zones http://www.shorewall.net/manpages/shorewall-zones.html 2. shorewall-policy http://www.shorewall.net/manpages/shorewall-policy.html 3. shorewall.conf http://www.shorewall.net/manpages/shorewall.conf.html [FIXME: source] 06/28/2012 SHOREWALL-NESTING(5)
All times are GMT -4. The time now is 06:46 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy