Protecting the Network with Homogeneous servers

We have a case where all of our machines are homogeneous w.r.t. the
security configuration. All of them are part of the VPN network.
If an attacker can attack one machine, he can attack the rest of the
machines also very easily and quickly, due to the homogeneity among
these machines.

Are there standard solutions already available to deal such kind of
scenarios? Is automatic detection of security breaching and dynamic
changing of the security settings recommended in such cases?

Re: Protecting the Network with Homogeneous servers

qazmlp1209@rediffmail.com wrote:
> We have a case where all of our machines are homogeneous w.r.t. the
> security configuration. All of them are part of the VPN network.
> If an attacker can attack one machine, he can attack the rest of the
> machines also very easily and quickly, due to the homogeneity among
> these machines.
>
> Are there standard solutions already available to deal such kind of
> scenarios? Is automatic detection of security breaching and dynamic
> changing of the security settings recommended in such cases?

IDS software exists for that problem. But also the usual advice is
worth repeating

1. Turn off services you don't need
2. Patch, update, keep up to date about security problems
3. Don't use the same root password for all of your boxes
4. Don't run Windows
5. Keep backups
6. Use privilege separation where possible

Some UNIX specific tricks that annoy script kiddies

1. Remove the "root" user and rename it something they won't guess
2. Put honeypots on your box
3. Use iptables [in conjunction with #2] to block IPs that scan you
4. Put SSH on a non-standard port
5. With #4, rotate which port SSH is on daily, hourly, whatever [*,
**]
6. A decoy box is always worth having

[*] Cron jobs are wonderful things.

[**] You can use something as trivial as ssh.port = (hmac(key,
time/300) % 1000) + 1000 to move your ssh around over time.

Tom

Re: Protecting the Network with Homogeneous servers

In comp.security.misc Tom St Denis wrote:
> Some UNIX specific tricks that annoy script kiddies
> 1. Remove the "root" user and rename it something they won't guess

Will not help. UID 0 is needed, not a user named "root".

> 2. Put honeypots on your box

Good idea.

> 3. Use iptables [in conjunction with #2] to block IPs that scan you

Or the packet filter of the OS however it is named.

> 4. Put SSH on a non-standard port

Will not help. There is port scanning.

> 5. With #4, rotate which port SSH is on daily, hourly, whatever [*,
> **]

Nonsense.

> 6. A decoy box is always worth having

You already noticed honey pots.

Yours,
VB.
--
Ich würde schätzen, dass ca. 87% aller spontanen Schätzungen völlig für
den Arsch sind.

Ralph Angenendt in debate@ccc.de

Re: Protecting the Network with Homogeneous servers

Volker Birk wrote:
> In comp.security.misc Tom St Denis wrote:
> > Some UNIX specific tricks that annoy script kiddies
> > 1. Remove the "root" user and rename it something they won't guess
>
> Will not help. UID 0 is needed, not a user named "root".

Script kiddies often try to login as "root". A quick and dirty trick
is to rename it something else. Sure it's still UID 0 but it's also a
useful RED FLAG if someone tries "root" you can iptables them right
away.

> > 4. Put SSH on a non-standard port
>
> Will not help. There is port scanning.

You do know what honey pots are for right? Or are you just nodding to
look like you know what the hell you're talking about?

> > 5. With #4, rotate which port SSH is on daily, hourly, whatever [*,
> > **]
>
> Nonsense.

Um, combined with honey pots you have a very effective way of trapping
ips of attackers.

If you always login to port 2222 for SSH someone sniffing your network
[or who did a scan] can see the connection. Note, you're not always
directly connected to the net, you could be colo'ed or over a rogue AP
or something.

No if you change the port SSH is on even if they know that you used
port 8713 5 minutes ago they won't guess the correct port now and be
iptable'ed off.

Tom

Re: Protecting the Network with Homogeneous servers

In comp.security.misc Tom St Denis wrote:
> > > 5. With #4, rotate which port SSH is on daily, hourly, whatever [*,
> > > **]
> > Nonsense.
> Um, combined with honey pots you have a very effective way of trapping
> ips of attackers.

Or for trapping legal users, for which those provisions only are
complicated, while they're adding no extra value of security.

> If you always login to port 2222 for SSH someone sniffing your network
> [or who did a scan] can see the connection. Note, you're not always
> directly connected to the net, you could be colo'ed or over a rogue AP
> or something.
> No if you change the port SSH is on even if they know that you used
> port 8713 5 minutes ago they won't guess the correct port now and be
> iptable'ed off.

That doesn't matter at all.

The SSH implementation has to be secure. Then it's secure. If it's not,
then chaning ports changes nothing with security.

Maybe you can say, that if you're not using port 22 but some other
not so common port, then maybe simple SSH scans are ommitting your box
and you're sparing traffic.

Yours,
VB.
--
Ich würde schätzen, dass ca. 87% aller spontanen Schätzungen völlig für
den Arsch sind.

Ralph Angenendt in debate@ccc.de

Re: Protecting the Network with Homogeneous servers

Volker Birk wrote:
> > Um, combined with honey pots you have a very effective way of trapping
> > ips of attackers.
>
> Or for trapping legal users, for which those provisions only are
> complicated, while they're adding no extra value of security.

Um, well first off it depends on the use cases of the server. If you
want SSH for remote admin only do you care if you lockout people who
try to SSH who shouldn't?

> The SSH implementation has to be secure. Then it's secure. If it's not,
> then chaning ports changes nothing with security.

Your attackers will try to login via SSH [and other services]. Even if
SSH is secure I'd still rather iptables out attackers. In the not to
impossible case that there is a bug in the implementation totally
blocking their request seems a reasonable added precaution.

> Maybe you can say, that if you're not using port 22 but some other
> not so common port, then maybe simple SSH scans are ommitting your box
> and you're sparing traffic.

It's been my experience that people will nmap your box looking for any
randomly open port. If you start having TCP connects to [say] port 79
from nmap when 79 is your honeypot, chances are the remote side is an
attacker. firewall them off and boom, no more scans, no more attacks,
yada yada.

You have to keep in mind, MOST of your attacks will come from mindless
2600 reading script kiddies who think a port scan is a "hack". They
might not be smart people, but they can download scripts/tools to cause
problems. Defeating most of them is a fairly trivial matter.

Sure, organized criminals may be smarter and use more advanced tricks
against companies like Amazon, but that doesn't mean a root exploit on
your small private server is any more welcomed.

Tom

Re: Protecting the Network with Homogeneous servers

Tom St Denis wrote:

> Volker Birk wrote:
>>> Um, combined with honey pots you have a very effective way of trapping
>>> ips of attackers.
>>
>> Or for trapping legal users, for which those provisions only are
>> complicated, while they're adding no extra value of security.
>
> Um, well first off it depends on the use cases of the server. If you
> want SSH for remote admin only do you care if you lockout people who
> try to SSH who shouldn't?
>
>> The SSH implementation has to be secure. Then it's secure. If it's not,
>> then chaning ports changes nothing with security.
>
> Your attackers will try to login via SSH [and other services]. Even if
> SSH is secure I'd still rather iptables out attackers. In the not to
> impossible case that there is a bug in the implementation totally
> blocking their request seems a reasonable added precaution.
>
>> Maybe you can say, that if you're not using port 22 but some other
>> not so common port, then maybe simple SSH scans are ommitting your box
>> and you're sparing traffic.
>
> It's been my experience that people will nmap your box looking for any
> randomly open port. If you start having TCP connects to [say] port 79
> from nmap when 79 is your honeypot, chances are the remote side is an
> attacker. firewall them off and boom, no more scans, no more attacks,
> yada yada.
>
> You have to keep in mind, MOST of your attacks will come from mindless
> 2600 reading script kiddies who think a port scan is a "hack". They
> might not be smart people, but they can download scripts/tools to cause
> problems. Defeating most of them is a fairly trivial matter.
>
> Sure, organized criminals may be smarter and use more advanced tricks
> against companies like Amazon, but that doesn't mean a root exploit on
> your small private server is any more welcomed.


One more trick - keep ports closed, so they do not respond to a port scan,
but open a port for SSH for two seconds only after two or three other ports
have been scanned in a particular order.



--
Peter Fairbrother

Re: Protecting the Network with Homogeneous servers

qazmlp1209@rediffmail.com wrote:
> We have a case where all of our machines are homogeneous w.r.t. the
> security configuration. All of them are part of the VPN network.
> If an attacker can attack one machine, he can attack the rest of the
> machines also very easily and quickly, due to the homogeneity among
> these machines.
>
> Are there standard solutions already available to deal such kind of
> scenarios? Is automatic detection of security breaching and dynamic
> changing of the security settings recommended in such cases?

No, there are none that I am aware of. The closest thing I can think of
the NSA hardening guide for Windows XP [1] but this focuses on
individual computers and not network architecture. It's probably a good
idea to follow these guidelines anyway.

The point you make is very lucid. The way corporate networks are
constructed is loosely coupled to the type of business they're used in.


Therefore, standardisation of such designs (with security designed in
from the ground up) would be very effective way of improving security
for everybody. If anybody who reads this group is in a position to
write and put forward such a standard, I urge you to do so.

Coming on to your question, you're right. It's not a nice position to
be in where anyone who VPNs in can attack any machine also connected to
the VPN. In most of the cases I've seen you can get away with enforcing
complete seperation of clients on the VPN. In a nutshell, make sure
they can't send any data to each other.

This leaves your other assets such as your servers as the central point
for attack. This is not a bad thing really as it reduces the problem
from "Guard everything" to "Guard this collection of machines." You
will find the latter problem considerably easier to solve.

The usual solutions work well for this: IDS, Firewalls, Anti-virus,
reducing the number of services running on each server, not running
services as the root user etc.

One thing I will mention. Do not underestimate the human dimension to
security. Who can get access to the servers? Are there too many people
who have access? Who knows the root password? Are there too many people
in this loop. Always try to trust as few people as possible. If
somebody doesn't need privilege then don't give it to them.

People often miss this dimension completely. I can tell you a very
short story about one of my gutsier/stupider friends from Sixth Form
[2]. He managed to get root access to the entire network. Quite a feat,
however wreckless it might be.

However, he did not achieve this through any cryptoanalytic subterfuge
but from doing things the old fashioned way: waiting until the
administrators went out for lunch and installing a trojan on the
server.

Physical access is *just* as important in these things as getting the
software element right.

You have to understand that to some extent, you're fighting an
impossible battle. You will be broken in to at some point. This is not
a failure on your part. A company exists to make money - it does not
exist to be a shining a becon of computer security.

Necessary trade-offs will be made and it's important that you make your
superiors aware that trade-offs have to be made somewhere. Too often
the security guy is the fall guy when things go wrong.

Once you've got your infrastructure in place, get someone to
penetration test it. This expert evaluation will likely throw light on
things you haven't considered.

My parting word of advice is to log absolutely everything. This will
make determining the depth of an attack much easier when you do have a
security failure.

Remember, the key to desgining anything is to make it simple but no
simpler.

Simon.

[1] - http://nsa2.www.conxion.com/winxp/

[2] - Sixth Form, for those who aren't up to speed with the British
education system, is the period of education between High School and
University. High Schools starts at 11 and runs to 16. Sixth Form from
16-18 and University from 18 onwards.

Re: Protecting the Network with Homogeneous servers

"Simon Johnson" wrote in message
news:1154461204.392766.103490@i42g2000cwa.googlegroups.com.. .
|
| qazmlp1209@rediffmail.com wrote:
| > We have a case where all of our machines are homogeneous w.r.t. the
| > security configuration. All of them are part of the VPN network.
| > If an attacker can attack one machine, he can attack the rest of the
| > machines also very easily and quickly, due to the homogeneity among
| > these machines.
| >
| > Are there standard solutions already available to deal such kind of
| > scenarios? Is automatic detection of security breaching and dynamic
| > changing of the security settings recommended in such cases?
|
| No, there are none that I am aware of. The closest thing I can think of
| the NSA hardening guide for Windows XP [1] but this focuses on
| individual computers and not network architecture. It's probably a good
| idea to follow these guidelines anyway.
|
| The point you make is very lucid. The way corporate networks are
| constructed is loosely coupled to the type of business they're used in.
|
|
| Therefore, standardisation of such designs (with security designed in
| from the ground up) would be very effective way of improving security
| for everybody. If anybody who reads this group is in a position to
| write and put forward such a standard, I urge you to do so.
|
| Coming on to your question, you're right. It's not a nice position to
| be in where anyone who VPNs in can attack any machine also connected to
| the VPN. In most of the cases I've seen you can get away with enforcing
| complete seperation of clients on the VPN. In a nutshell, make sure
| they can't send any data to each other.
|
| This leaves your other assets such as your servers as the central point
| for attack. This is not a bad thing really as it reduces the problem
| from "Guard everything" to "Guard this collection of machines." You
| will find the latter problem considerably easier to solve.
|
| The usual solutions work well for this: IDS, Firewalls, Anti-virus,
| reducing the number of services running on each server, not running
| services as the root user etc.
|
| One thing I will mention. Do not underestimate the human dimension to
| security. Who can get access to the servers? Are there too many people
| who have access? Who knows the root password? Are there too many people
| in this loop. Always try to trust as few people as possible. If
| somebody doesn't need privilege then don't give it to them.
|
| People often miss this dimension completely. I can tell you a very
| short story about one of my gutsier/stupider friends from Sixth Form
| [2]. He managed to get root access to the entire network. Quite a feat,
| however wreckless it might be.
|
| However, he did not achieve this through any cryptoanalytic subterfuge
| but from doing things the old fashioned way: waiting until the
| administrators went out for lunch and installing a trojan on the
| server.
|
| Physical access is *just* as important in these things as getting the
| software element right.
|
| You have to understand that to some extent, you're fighting an
| impossible battle. You will be broken in to at some point. This is not
| a failure on your part. A company exists to make money - it does not
| exist to be a shining a becon of computer security.
|
| Necessary trade-offs will be made and it's important that you make your
| superiors aware that trade-offs have to be made somewhere. Too often
| the security guy is the fall guy when things go wrong.
|
| Once you've got your infrastructure in place, get someone to
| penetration test it. This expert evaluation will likely throw light on
| things you haven't considered.
|
| My parting word of advice is to log absolutely everything. This will
| make determining the depth of an attack much easier when you do have a
| security failure.
|
| Remember, the key to desgining anything is to make it simple but no
| simpler.
|
| Simon.
|
| [1] - http://nsa2.www.conxion.com/winxp/
|
| [2] - Sixth Form, for those who aren't up to speed with the British
| education system, is the period of education between High School and
| University. High Schools starts at 11 and runs to 16. Sixth Form from
| 16-18 and University from 18 onwards.
|

You might want to look at
http://www.microsoft.com/windowsserver2003/technologies/clus tering/default.mspx

-- Ed.

-----------------------------------------------------
Less than a week after Ken Lay's death, and hell was already declaring
bankruptcy...
F9E7707A2AF502D0A899C6ACB43A2D35EB7E->bin->b64

Re: Protecting the Network with Homogeneous servers

Ed Weir (ComCast) wrote:
> You might want to look at
> http://www.microsoft.com/windowsserver2003/technologies/clus tering/default.mspx

How about next time you don't quote an entire long message with a one
line response?

Fucking newbs...

tom

Re: Protecting the Network with Homogeneous servers

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6DA2E5A2496BB010D58B47A6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Tom St Denis wrote:
> Ed Weir (ComCast) wrote:
>> You might want to look at
>> http://www.microsoft.com/windowsserver2003/technologies/clus tering/def=
ault.mspx
>=20
> How about next time you don't quote an entire long message with a one
> line response?
>=20
> Fucking newbs...
>=20
> tom
>=20
Fucking Tom...

tim


--------------enig6DA2E5A2496BB010D58B47A6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Quae Sursum Volo Videre

iD8DBQFEz/M4viZ6RvnZfawRAvwWAJ9GfipPcWkmbOnltVEGDU61gkkg1gCg i4vI
zbK4wKuAGGvh6iEzLOMtI70=
=lw5T
-----END PGP SIGNATURE-----

--------------enig6DA2E5A2496BB010D58B47A6--

Re: Protecting the Network with Homogeneous servers

Timoleon wrote:
> Tom St Denis wrote:
>> Ed Weir (ComCast) wrote:
>>> You might want to look at
>>> http://www.microsoft.com/windowsserver2003/technologies/clus tering/default.mspx
>> How about next time you don't quote an entire long message with a one
>> line response?
>>
>> Fucking newbs...
>>
>> tom
>>
> Fucking Tom...

Fucking tim with his MIME postings. Really shouldn't be that hard to use
OpenPGP/Inline or not any OpenPGP at all (because this is Usenet and no
one cares a fuck for genuine postings).

Re: Protecting the Network with Homogeneous servers

"Timoleon" wrote in message
news:XqSzg.2672$sy2.2666@trndny01...
>> Fucking newbs...
>Fucking Tom...

Doesn't interest me

--
LTP

:)

USA NSA SNAC ONED Guide to Securing Microsoft Windows XP [Was: Protectingthe Network with Homogeneou

Simon Johnson wrote:
> qazmlp1209@rediffmail.com wrote:
>> We have a case where all of our machines are homogeneous w.r.t. the
>> security configuration. All of them are part of the VPN network.
>> If an attacker can attack one machine, he can attack the rest of the
>> machines also very easily and quickly, due to the homogeneity among
>> these machines.
>>
>> Are there standard solutions already available to deal such kind of
>> scenarios? Is automatic detection of security breaching and dynamic
>> changing of the security settings recommended in such cases?
>
> No, there are none that I am aware of. The closest thing I can think of
> the NSA hardening guide for Windows XP [1] but this focuses on
> individual computers and not network architecture. It's probably a good
> idea to follow these guidelines anyway.
>
>
>
> Simon.
>
> [1] - http://nsa2.www.conxion.com/winxp/
>
Get it from the original source:
http://www.nsa.gov/snac/os/winxp/C44-026-02.pdf