# Best way to secure systems and networks

## LD

Just share your thoughts and ideas on this subject.

----------

## szczerb

Easy, just unplug them from any network ;]

----------

## aidanjt

Don't listen().

If you have no services running, your system has nothing to be exploited with, well, except maybe holes in the TCP/IP stack of your OS.

----------

## TNorthover

 *AidanJT wrote:*   

> Don't listen().
> 
> If you have no services running, your system has nothing to be exploited with, well, except maybe holes in the TCP/IP stack of your OS.

 

More correctly but even more uselessly, don't recv(). You can be exploited over a connection you've initiated just as easily as one you've received.

----------

## aidanjt

 *TNorthover wrote:*   

>  *AidanJT wrote:*   Don't listen().
> 
> If you have no services running, your system has nothing to be exploited with, well, except maybe holes in the TCP/IP stack of your OS. 
> 
> More correctly but even more uselessly, don't read(). You can be exploited over a connection you've initiated just as easily as one you've received.

 

Sure, but *you* have to initiate the connection, and *you* generally aren't a system process.

----------

## Bones McCracker

You can use my single-packet authentication script:   :Very Happy: 

https://forums.gentoo.org/viewtopic-t-687956-highlight-knocking.html

Or if you're lazy, you can just use fwknop (which has actually adopted a couple of ideas from my script).

----------

## think4urs11

some thoughts which come to mind

- key/certificate-based auth; if possible never password-auth, never ever plaintext

- sshd_config AllowUsers, AllowGroups, DenyGroups, AcceptEnv, Ciphers, ClientAlive*, LoginGraceTime, MaxAuthTries, Permit*, X11Forwarding, only ssh v2, _no_ v1

- maybe portknocking

- firewalling for incoming and outgoing traffic, where appropriate based on UID/PID

- when e.g. squid is in use implement sane ACLs which allow only your/internal IP addresses

- tcpwrapper for apps without own ACLs

- minimal rights per process

- no unneeded services listening

- mod_security for apache

- fail2ban/denyhosts

- system hardening - SELinux/RSBAC/hardened kernel+toolchain

- regular system scans both 'on box' like rkhunter/aide and 'off box' like nessus, nmap, etc.

- log everything to a second system, use event correlation (sec), if possible via stunnel

- (when using Cisco) no CDP/VTP, PVLAN per port, dhcp snooping, arp limits per switch port, broadcast controls/limits, prune vlans from trunks, trunks only where really needed

- case intrusion detection

- arpwatch

- full disk encryption (token+passphrase)

- (secure) ntp on all systems

- no unencrypted traffic (neither wired nor wireless)

- normal user without wheel-rights

- root-login disabled

- don't rely on WEP/WPA/WPA2, use an additional VPN 'above'

- use a dedicated authentication host

- snort

- !skype

- ....

----------

## wswartzendruber

Why not rely on WPA2?  Is anyone going to be breaking 256-bit AES anytime soon?

And I assume we're supposed to disable X11 port forwarding?

----------

## think4urs11

As long as we don't talk about an enterprise setup with 802.1x it depends on length and complexity of the PSK, most home users use (if active at all) what is preconfigured e.g. on their Fritzbox. I guess a complex 63 char PSK might be 'good enough' also, but with e.g. OpenVPN 'above' you can have a cert-based auth additionally.

And yes X11 forwarding disabled. After all we talk about (paranoid) security here.

----------

## bunder

i considered using snort at one time, but then i thought about the CPU usage on my router if i did... plus the fact i can't get updated rules without an oink code...   :Confused: 

edit: and what's wrong with WPA2+PSK?

----------

## Bones McCracker

 *Think4UrS11 wrote:*   

> tcpwrapper for apps without own ACLs

 

That's a very good checklist.

I have found that, for my purposes, tcpwrapper is redundant with xinetd.  So I remove it.

One thing I've also found useful is the ipset patch.

ipset is a collection of data structures that can store with great efficiency large sets of IP addresses (and related ports and what-not, if you like).  There are many uses, but I find it useful to maintain firewall blacklists.  Since they are stored in a few KiB of RAM, they can be very quickly matched by netfilter.  Other forms of blacklists tend to slow down traffic if they are large.  As an example, you can easily block all of the networks from geographical regions you don't need to accept syns from in less than 1 KiB, and you can create another ipset to handle your dynamic blacklist (fed by recent matches or whatever).  You can use an ipset anywhere in your iptables rules that you'd use a single address, and this is much more efficient than using rules that make use of address ranges (which are actually propagated to multiple logical matching steps within netfilter).

From what I understand, this was in the kernel tree for a while and then taken out for further development.  I don't know if it's going back in or not, but it works perfectly fine for me, and based on my admittedly non-expert understanding, it should be substantially speeding up my firewall (or enabling me to use blacklists without performance penalty, depending on how you want to look at it).  Other people use them for white-listing their own addresses, and you can multidimensional stuff (e.g. whitelisting certain address/port combinations).

http://ipset.netfilter.org/

----------

## think4urs11

 *bunder wrote:*   

> and what's wrong with WPA2+PSK?

 

as already written it depends on the complexity of the PSK

one more thing i've forgotten in the list: filter out all RFC3330 + all bogon ip addresses (+$far_away_hostile_countries) on your ingress/egress point, as listed e.g. here: http://www.cidr-report.org/bogons/freespace-prefix.txt

----------

## poly_poly-man

set fire to the ethernet cable... perfect firewall (no traffic gets through at all!)

----------

## think4urs11

somehow this thread better fits to   :Arrow:   Networking & Security, thus moved from OTW.

----------

## LD

Maybe, but it seems more general discussion to me but i defer to the admin.

If one were to switch to the hardened profile and simply rebuild off that and switched to hardened sources, how much of an increase in security would that provide? on it's own.

----------

## wswartzendruber

 *LD wrote:*   

> Maybe, but it seems more general discussion to me but i defer to the admin.
> 
> If one were to switch to the hardened profile and simply rebuild off that and switched to hardened sources, how much of an increase in security would that provide? on it's own.

 

I'm guessing a lot since that's going to add PaX (ASLR, NX) and PIE along with SSP.

Now, if you want SSP under GCC4, you're going to need to add either -fstack-protector or -fstack-protector-all to your CFLAGS.  This currently breaks Grub and something else.  The patch for Grub will eventually land in Portage.

So yeah, anything related to buffer overflows should be resolved right off the bat.

----------

## think4urs11

 *LD wrote:*   

> Maybe, but it seems more general discussion to me but i defer to the admin.

 

In a way you (and bunder) are right, on the other hand having it in N&S might get a bigger audience having a look at the topic - esp. people with interests in N&S department.

So in theory at the end of the day the outcome of the thread should be better in it's new location.

Maybe i've broken some unwritten OTW law now, who knows  :Wink: 

----------

## Bones McCracker

 *wswartzendruber wrote:*   

> Now, if you want SSP under GCC4, you're going to need to add either -fstack-protector or -fstack-protector-all to your CFLAGS.  This currently breaks Grub and something else.  The patch for Grub will eventually land in Portage.
> 
> So yeah, anything related to buffer overflows should be resolved right off the bat.

 

Really?  I don't have -fstack-protector or -fstack-protector-all in my CFLAGS (in make.conf), based on the following.  Am I making a mistake?

 *Quote:*   

> Do I need to pass any flags to LDFLAGS/CFLAGS in order to turn on PIE/SSP building?
> 
> No, the current toolchain implements the equivalent of CFLAGS="-fPIE -fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro" automatically through GCC's specfile which is a more proper solution.

 

http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#hardenedcflags

----------

## wswartzendruber

 *BoneKracker wrote:*   

>  *wswartzendruber wrote:*   I'm guessing a lot since that's going to add PaX (ASLR, NX) and PIE along with SSP.
> 
> Now, if you want SSP under GCC4, you're going to need to add either -fstack-protector or -fstack-protector-all to your CFLAGS.  This currently breaks Grub and something else.  The patch for Grub will eventually land in Portage.
> 
> So yeah, anything related to buffer overflows should be resolved right off the bat. 
> ...

 

I see in my crystal ball that the above documentation refers to GCC3.  The Hardened profile doesn't apply stack protection to GCC4 because the GNU devs did the implementation over again.  Among other things, GRUB broke with it.

----------

## Bones McCracker

 *wswartzendruber wrote:*   

>  *BoneKracker wrote:*    *wswartzendruber wrote:*   I'm guessing a lot since that's going to add PaX (ASLR, NX) and PIE along with SSP.
> 
> Now, if you want SSP under GCC4, you're going to need to add either -fstack-protector or -fstack-protector-all to your CFLAGS.  This currently breaks Grub and something else.  The patch for Grub will eventually land in Portage.
> 
> So yeah, anything related to buffer overflows should be resolved right off the bat. 
> ...

 

Gee, I wish I had known that.   :Confused: 

Well, it's easy enough to specify package-specific CFLAGS for GRUB.

What else broke?

And what bout the other flags?  Should these also be in make.conf then?

 *Quote:*   

> CFLAGS="-fPIE -fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro"

 

----------

## wswartzendruber

 *BoneKracker wrote:*   

>  *wswartzendruber wrote:*    *BoneKracker wrote:*    *wswartzendruber wrote:*   I'm guessing a lot since that's going to add PaX (ASLR, NX) and PIE along with SSP.
> 
> Now, if you want SSP under GCC4, you're going to need to add either -fstack-protector or -fstack-protector-all to your CFLAGS.  This currently breaks Grub and something else.  The patch for Grub will eventually land in Portage.
> 
> So yeah, anything related to buffer overflows should be resolved right off the bat. 
> ...

 

Here's my #gentoo-hardened log from earlier today:

 *Quote:*   

> <wswartz> Some of the stuff I'm seeing on Google says we do have SSP in GCC4 as long as we have glibc-2.5 or higher.
> 
> <wswartz> Built under the hardened toolchain, of couse.
> 
> <Zorry> yes but is nor enable by default
> ...

 

EDIT: solar on #gentoo-hardened just confirmed that no additions are necessary to LDFLAGS.

----------

## LD

Hmmm...

Ok, how about full disk encryption? Best ways to set it up? What to use? how to put it on an already functioning system?

----------

## wswartzendruber

 *LD wrote:*   

> Hmmm...
> 
> Ok, how about full disk encryption? Best ways to set it up? What to use? how to put it on an already functioning system?

 

I did LUKS once under EXT3 and had multiple "abrupt poweroffs" with no apparent data loss.  The thing is, you're boot partition has to stay plaintext unless you do that USB flash drive trick.

----------

## LD

Explain the use flash drive trick.

so LUKS on EXT3 is one option for full drive encryption.

ANy others?

----------

## wswartzendruber

 *LD wrote:*   

> Explain the use flash drive trick.
> 
> so LUKS on EXT3 is one option for full drive encryption.
> 
> ANy others?

 

More like full partition encryption.  I left my boot partition as plaintext (because GRUB won't understand it if it's encrypted) and encrypted my root partition.  I embedded initramfs inside the kernel directly and set it up to mount the root partition and boot the userland off that.  The thing is, someone who gets access to your machine can alter the kernel to send the password you enter back home.  The way to avoid this is to boot off a flash drive containing the bootloader and kernel.  But if you lose the flash drive, you're pretty much screwed.

----------

## LD

How would one do this sort of thing?

----------

## wswartzendruber

Google for a LUKS howto.  I don't remember where I found mine.

----------

## minor_prophets

I just wanted to ask where people are physically locating their snort apps/boxen on the network.

What are general opinions about locating snort directly on a Gentoo router pc thats routing, firewalling, dns/dhcp, squid and the usual suspects with base, apache2 and postesql on another internal machine?

Thanks all.

----------

## think4urs11

 *minor_prophets wrote:*   

> I just wanted to ask where people are physically locating their snort apps/boxen on the network.
> 
> What are general opinions about locating snort directly on a Gentoo router pc thats routing, firewalling, dns/dhcp, squid and the usual suspects with base, apache2 and postesql on another internal machine?
> 
> Thanks all.

 

Generally? At every point/segment of interest  :Smile: 

What is this?

Let's say you have

- link to internet

- DMZ segment where e.g. your public webserver is located, your mailserver etc.

- internal network - your normal workstations, printers etc.

Optimum would be to have in each of that segments one dedicated snort box - all of them correlating to one database to have one view onto 'what goes on'.

Means

- one box in front of your outmost interface towards internet - this box will see the most attacks as nothing is filtered; attacks to things you don't have but which are still probed for.

- one box in the DMZ where only attacks come in which are possible from internet towards your public servers/services (so only attacks to services you have public)

- one box in you internal LAN where (hopefully) nothing should be visible, expect e.g. when your DMZ box is hacked and the attacker wants 'more'

Running snort on a non-dedicating box is -from a pure security point of view- a no-go. As most of us don't have unlimited access to money or hardware or even power outlets though it can be a good compromise. What needs to be considered here is that snort can 'waste' a lot of CPU, I/O, etc. depending on the exact ruleset.

So when you have a busy webserver with a load of 20+ which needs to handle snort _additionally_ your users needing the webserver might not be amused.

----------

## ScarletPimpFromHell

I would strongly suggest (if you have the money) a good dedicated internet router with in-line Intrusion Prevention Sysytem software and a stateful inspection firewall. There are numerous cheap vendor systems available, most of which are built apon a Linux kernel.

In addition, invest some time in better understanding reconissance techniques at the http://insecure.org web site. Download/emerge nmap and try some pen testing against your network just to see what you are making available to the public internet.

----------

## LD

Would someone be willing to write up howtos or tips and tricks for the methods we have discussed?

It be nice to have a best practices for this sort of thing and how to switch from non-hardened to harderened setups.

Things like that, letskeep the discussion flowing.

----------

## cach0rr0

tidbit or two to add on the apache end

-jail apache. 

-look at mod_chroot, and suphp. disable file uploads for any vhosts where you can afford it

-mod_security is a nifty concept, but regex is expensive from a processing standpoint. I basically gut the default rules, and window shop a few that look useful 

-follow the hardened gentoo docs

other general things that either weren't discussed, or that i missed 

-AIDE is your friend. 

-go through the trouble of defining sensible grsec policies

-do a regular glsa-check, mail the results to yourself 

-snag nessus in addition to nmap, do periodic checks. 

what's been posted thus far is fairly extensive, i dont have heaps to add (partially because i myself am no true expert)

----------

## xtz

 *Think4UrS11 wrote:*   

> some thoughts which come to mind
> 
> - key/certificate-based auth; if possible never password-auth, never ever plaintext
> 
> - sshd_config AllowUsers, AllowGroups, DenyGroups, AcceptEnv, Ciphers, ClientAlive*, LoginGraceTime, MaxAuthTries, Permit*, X11Forwarding, only ssh v2, _no_ v1
> ...

 

U r kidding, right? When coming to work, a system administrator will have to spend at least 1 hr watching logs (if everything is normal  :Razz: ).

----------

## kernelOfTruth

 *Think4UrS11 wrote:*   

> some thoughts which come to mind
> 
> - key/certificate-based auth; if possible never password-auth, never ever plaintext
> 
> - sshd_config AllowUsers, AllowGroups, DenyGroups, AcceptEnv, Ciphers, ClientAlive*, LoginGraceTime, MaxAuthTries, Permit*, X11Forwarding, only ssh v2, _no_ v1
> ...

 

very very useful

thanks !

 *wswartzendruber wrote:*   

>  *LD wrote:*   Explain the use flash drive trick.
> 
> so LUKS on EXT3 is one option for full drive encryption.
> 
> ANy others? 
> ...

 

I'd keep an image of the flash-drive on the encrypted partitions for backup-purposes so that you can restore it later,

you can still access your encrypted data via key and liveCD with LUKS + cryptsetup support   :Smile: 

----------

## Mike Hunt

 *LD wrote:*   

> Would someone be willing to write up howtos or tips and tricks for the methods we have discussed?

 

There are some  here.

----------

