> Non root users can't write to it because of file permissions, root users
> can remount it read write. You haven't convinced me. Reading other peoples
> responses I can see some value in it.
You've said it yourself - root can remount rw.. again, you're assuming
initial root access. :)
> Are you talking about syslog out a serial port?
> Is that a trick?
It's an oldie but a goodie. Or alternatively encrypted syslog to another
machineor a compromise with cron jobs and scp etc... it depends on your
environment.
I've even seen a box with a cd writer and a cron job whch writes
multisession disks every hour or so (can't remember exactly) and they
change disks once a day.. :)
> > temporary files in ram,
>
> I guess I should check the archives for this one.
Bad karma. Volatile logs are not good.
> > boot off CD,
>
> If someone has physical access there is little that you can
> do to stop them getting in. You could slow them down but thats all.
> ie password protect the bios, disable booting off removable media,
> password protect lilo, etc. But that still doesn't protect the box
> from physical access. And if someone has physical access, why bother
> with the firewall at all? Just disconnect the firewall and plug a laptop
> in.
First rule of security - if it's not physically protected, you can ignore
the rest. Don't bother. I can do anytihng I want to your box, password
protected, whatever.. just give me time. And as you said, if I want access
to your network, and a little subterfuge is ok, just plug in a laptop ora
smaller machine and hide it and put an "any, any, any" rule on it..
A lot of security is handled by the "three B's": "Burglary, Bribery,
Blackmail" (phrase courtesty of some ex-NSA person whose name I can't
remember.. :)
> I may not know as much as someone like yourself, but that is the reason we got
> the security audit.
Remember, as long as you're trying, you're in the right direction. It may
take time and it may be complicated, but every bit helps. Fiddle to your
hearts content, and ask for advice often. :)
> > if someone gets in, man pages help them know the particular variety of
> > your box.
>
> Are you serious? if someone gets in the game is over, they already know enough
> about the box, wouldn't you say?
The above statement is not exactly correct, but yes they do know about the
box somewhat, and even if the man pages help them for 30 seconds, it's too
much.
> There are bigger give aways than man pages though.
> less /var/lib/dpkg/status, and I assume a similar way for redhat.
Correct. As well as seemingly harmles binaries like "uname" and even the
layout of the filesystem.
> > Yes, but they still have to upload them, which takes time, which
> > increase the chances of discovery, etc. If you don't need it, then it
> > shouldn't be there.
>
> I agree, but really, you're over stating how hard it is to upload files.
It's piss easy to suck down a root kit onto your average firewall that
you've broken into and have a shell of some sort.Especially since every
forgets about outbound rules and concentrates on inbound rules only.
> Users can't get an interactive shell on the firewall, at least thats the aim.
> We are in the near future going to remove X forwarding via ssh and remove the
> need for having user accounts on the firewall.
> We have been advised to run ntp on the firewall so log time stamps are in
> sync. Another potential access point.
Bind ntp to a particular interface and only allow port 123 from your ntp
server, also turn on the funky auth features (or you could do ipsec to
your ntp box ;) Or another method I've seen is to have a private network
(a separate nic just for ntp and syslog traffic - but remember, this
becomes another layer to secure and protect etc..)
But yes,timestamps are extremely important.
Even on the inodes themselves.
shameless_plug();
sub shameless_plug {
print <<EOF;
Speaking of inodes and forensics, I'm currently in the process of writing
a forensics package which will generate a full report on the box after a
compromise, normalize and sanitize the data as evidence to aid in
prosecution/analysis etc..
Coming soon (err.. well in a few months anyway.. :)
EOF
}
//umar.
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
