2010/8/22 Robert Spangler :
> On Friday 20 August 2010 10:55, Brunner, Brian T. wrote:
>
>> 2: Log-ins through firewall allowed only from approved IPs/MACs
>> regardless of possession of correct password.
>
> One can never guarantee that they will be a at the approved IP/MAC Address
> when issues a
On Friday 20 August 2010 10:55, Brunner, Brian T. wrote:
> 2: Log-ins through firewall allowed only from approved IPs/MACs
> regardless of possession of correct password.
One can never guarantee that they will be a at the approved IP/MAC Address
when issues arise. For this reason I would use SS
On 8/20/2010 11:26 AM, Whit Blauvelt wrote:
> On Fri, Aug 20, 2010 at 11:21:49AM -0500, Les Mikesell wrote:
>
>> In some cases I've tried to edit in the right values but as the machine
>> came up it renamed all of the ifcfg-eth? files with a .bak extension and
>> created new ones using dhcp.
>
> Si
On 08/20/2010 05:26 PM, Whit Blauvelt wrote:
>> In some cases I've tried to edit in the right values but as the machine
>> came up it renamed all of the ifcfg-eth? files with a .bak extension and
>> created new ones using dhcp.
>
> Since you're bringing that up - I've seen it too - what does that a
On Fri, Aug 20, 2010 at 11:21:49AM -0500, Les Mikesell wrote:
> In some cases I've tried to edit in the right values but as the machine
> came up it renamed all of the ifcfg-eth? files with a .bak extension and
> created new ones using dhcp.
Since you're bringing that up - I've seen it too - what
On 8/20/2010 10:44 AM, Brunner, Brian T. wrote:
>
>>> 3: When you first build the system, ghost/image the boot/root/usr
>>> (bru) drive onto a spare backup, verify the backup boots
>>> the machine the same as the main drive.
>>> 4: have the backup bru drive mailed to you, dupe it, and rsync the
>>>
On 08/20/2010 03:59 PM, Jim Perrin wrote:
> Decent list. I might also consider disabling vaious unused or
> unnecessary hardware kernel modules like usb-storage or other things
> that might lend themselves to snooping by remote hands.
that's a good point. hald might be worth turning off completely
On 08/20/2010 03:55 PM, Brunner, Brian T. wrote:
> 1: Rebuild kernel to remove local KVM (Keyboard Video Mouse), run
> headless; the only access is via ssh.
that isnt going to help if the network card is dead. I dont want the
machine shipped back to me for looking at :)
> 3: When you first build
> > 3: When you first build the system, ghost/image the boot/root/usr
> > (bru) drive onto a spare backup, verify the backup boots
> > the machine the same as the main drive.
> > 4: have the backup bru drive mailed to you, dupe it, and rsync the
> > remote bru to your local copy whenever you
On 8/20/2010 9:55 AM, Brunner, Brian T. wrote:
>
> 3: When you first build the system, ghost/image the boot/root/usr (bru)
> drive onto a spare backup, verify the backup boots the machine the same
> as the main drive.
> 4: have the backup bru drive mailed to you, dupe it, and rsync the
> remote bru
From: Karanbir Singh
> What other, reasonable, steps should one consider ?
I think you can password protect the interactive editing in grub.
Did not see:
- Disable usb booting (and CD, if there is a CD/DVD drive).
- lock the server case (if there is a lock).
- enable case intrusion detection (if
On Fri, Aug 20, 2010 at 10:18 AM, Karanbir Singh wrote:
> A short list of things that I tend to always do is :
Decent list. I might also consider disabling vaious unused or
unnecessary hardware kernel modules like usb-storage or other things
that might lend themselves to snooping by remote hands
> I'm looking to put together a doc for the wiki.c.o on howto
> secure a remotely hosted machine. There is always the issue of remote
> hands, other facility users etc being able to get physical
> access of the machines.
1: Rebuild kernel to remove local KVM (Keyboard Video Mouse), run
headle
13 matches
Mail list logo
