Prev: REQ: Sonicwall SOHO3 Firmware
Next: Firewall port 1105 (FTRANHC) & port 1239 (NMSD) ?
From: DigitalVinyl on 29 Nov 2005 17:57
Ansgar -59cobalt- Wiechers <usenet-2005(a)planetcobalt.net> wrote:

>Leythos wrote:
>> In article <3v3o3nF13n3meU1(a)individual.net>, usenet-2005(a)planetcobalt.net says...
>>> However, you still don't want any server in the DMZ to be able to
>>> initiate connections to hosts inside tha LAN.
>>
>> Again, it's not going to hold in a web to database design. You should
>> never put the database server in the DMZ and you would never put the web
>> server in the LAN -
>
>Please tell me: why would I punch a hole into the firewall protecting my
>LAN rather than putting a DB server into a (separate) DMZ and opening
>that hole only between the two DMZs? Or (if the requirements allow this)
>do put a DB server into the DMZ, and have the "real" DB server in the
>LAN from where only the required subset is pushed to the DMZ-DB?

The only problem I see with putting a critical DB in a DMZ off the
Internet-edge firewall is that it is now on the doorstep of the
internet. If the firewall is comprimised you've lost the DB already.
Further in, you can have a critical DB behind a second firewall or
implement acl control. Also combining DMZs on one firewall is common,
but can result in rule confusion and unintended opening of access.

Other than that you can do exactly that. However it is common for DB
to interact with multiple backend servers and applications, not to
mention admin/desktops. Rather than open one rule WEB->DBport, you now
have to open many more to allow all the different internal servers to
access the DMZ-DB or possbily in the reverse direction--although I
imagine you wouldn't allow any such thing. And think about that...
you may be placing a DB in a less-secure DMZ than INSIDE. In a PIX all
inside hosts would have access to the DB by default. The DB would be
consider an insecure network by definition. Typically the DB is
considered the most secure element so the DB would run batch jobs and
reach out to other servers. This is a common structure. However, if it
had to reach out to an Internal server that wouldn't be permitted,
because the DMZ-DB is less secure.

>> so, you punch a IP:PORT hole through the DMZ>LAN for 1433 between the
>> exact two IP, and then your web app can access the MSSQL Server in the
>> protected LAN.
>
>No, I don't think I'm going to do this.
>
>> Port 1433 isn't going to allow access to Enterprise manager, and as
>> long as your DB Server is patched, then allowing 1433 from the DMZ to
>> LAN vial IP:PORT>IP:PORT won't compromise the network.
>
>And with one of the setups I described above, my network wouldn't be
>compromised even *if* the webserver got compromised *and* there was an
>unpatched vulnerability in the DBMS *and* an attacker had a 0-day.
>Defense in depth.
>
>cu
>59cobalt

From: Somebody. on 30 Nov 2005 07:30

"Leythos" <void(a)nowhere.lan> wrote in message
news:dh3jf.126591$Hs.74605(a)tornado.ohiordc.rr.com...
> In article <3v3o3nF13n3meU1(a)individual.net>, usenet-2005
> @planetcobalt.net says...
>> However, you still don't want any server in the DMZ to be able to
>> initiate connections to hosts inside tha LAN.
>
> Again, it's not going to hold in a web to database design. You should
> never put the database server in the DMZ and you would never put the web
> server in the LAN - so, you punch a IP:PORT hole through the DMZ>LAN for
> 1433 between the exact two IP, and then your web app can access the
> MSSQL Server in the protected LAN. Port 1433 isn't going to allow access
> to Enterprise manager, and as long as your DB Server is patched, then
> allowing 1433 from the DMZ to LAN vial IP:PORT>IP:PORT won't compromise
> the network.
>

You can put the DB server and th DB App server in separate DMZ's though, and
apply IPS to the in-band traffic to filter out attacks for the few ports and
protocols you have to allow in and out of each zone -- an IPS is going to
update faster than Microsoft patches.

Though this takes a more powerful firewall.

-Russ.


From: Somebody. on 30 Nov 2005 12:55

"Leythos" <void(a)nowhere.lan> wrote in message
news:IUkjf.244394$lI5.78042(a)tornado.ohiordc.rr.com...
> In article <3v5rhjF13va87U2(a)individual.net>, usenet-2005
> @planetcobalt.net says...
>> Leythos wrote:
>> > In article <3v40jiF13hjo6U1(a)individual.net>,
>> > usenet-2005(a)planetcobalt.net says...
>> >> Leythos wrote:
>> >>> Port 1433 isn't going to allow access to Enterprise manager, and as
>> >>> long as your DB Server is patched, then allowing 1433 from the DMZ
>> >>> to LAN vial IP:PORT>IP:PORT won't compromise the network.
>> >>
>> >> And with one of the setups I described above, my network wouldn't be
>> >> compromised even *if* the webserver got compromised *and* there was
>> >> an unpatched vulnerability in the DBMS *and* an attacker had a 0-day.
>> >> Defense in depth.
>> >
>> > Wrong - If the database server in DMZ2 is compromised by a 0-Day
>> > exploit, and you've setup replication between the DMZ1 DB server, so
>> > that you have real-time information available, then the same 0-Day
>> > exploit will reach through and compromise that server too.
>>
>> No. Simply because replication and web application use different
>> mechanisms to access the server. Besides, I didn't say anything about
>> real-time replication.
>
> No, you didn't, but lets take an online ordering system, or a project
> management system or anything else that doesn't use a Static DB, and
> then you either punch a hole or setup replication, so you're back to
> having a security issue that you have to deal with one way or another.

Data lives in DMZ1. Only connection to it is an administrative interface
like RDP, from the trust zone, and some sort of file transfer method like
sftp, both initiated from particular trusted, hardened hosts.

Server lives in DMZ 2. Only connection to DMZ1 is SQL. Only connection to
outside is via incoming http. No connection to trust.

Hacker must compromise web server first using only inline in-line port 80,
and then inject an in-line SQL compromise to the DB server in DMZ1, which in
fact has no outbound policies to anywhere, and therefore can only reply to
SQL sessions initiated from that web server.

-Russ.


From: Frankster on 30 Nov 2005 13:22
> It does work in the real world, though many people
> seem to be reluctant to do it right, because the other
> way is so much easier.

It's not about "easy", it's about money. A realistic risk analysis verses
costs. Some's worth it, some's not.

-Frank


From: Frankster on 30 Nov 2005 17:23
>> It's not about "easy", it's about money.
>
> Anything not easy is going to cost money, so it's the same.

Disagree. Often the easiest thing is to throw money on it.

>> A realistic risk analysis verses costs. Some's worth it, some's not.
>
> Honestly, don't most of those "realistic" risk analyses amount to "it's
> more likely to hit others first, so we don't need to spend money on that
> now", until they actually get hit?

Nope. Not if they are done right.

Another thing... it's kind of ridiculous to spend much time and money to
protect a system without real data storage that you can rebuild and have
back to original in an hour. Just depends. OTOH, it could be that an hour of
downtime would cost your company thousands or millions. Just depends.

-Frank


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: REQ: Sonicwall SOHO3 Firmware
Next: Firewall port 1105 (FTRANHC) & port 1239 (NMSD) ?