Re: [SLUG] Firewall security audit report

[chesty]

On Wed, Feb 28, 2001 at 10:15:13AM +1100, Umar Goldeli wrote:
> > Removing binaries just means the attackers have to get them in via
> > some other means.
> 
> Indeed. You're buying time. Time is good. If your attacker can't readily
> telnet, ftp, ssh, scp, rcp, wget, lynx etc - he's going to have to try
> much harder. And what also happens if there's no compiler on the box? 

Theres no c compiler (but they could upload bin's I suppose) but there is
perl, I'll have to check if perl is needed. 

> better yet, your border router acls do not allow connections ORIGINATING
> from your firewall outbound?

Unforunately, at the moment it has a proxy running.

> Agreed throughly about the turn of all listening services bit. :)

Sorry, did you say something?

> As for logging - the safest way to keep logs is to have a serial printer
> attached to your console and dumpit all on to paper and focus on physical
> secrity of the box. Do what the military does... not veyr practical, but
> once written, your logs are there forever. ;)

Printers run out of paper (printer DoS), with some printers you can reverse 
the paper back and write over stuff making it unreadable.

-- 
chesty


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[chesty]

On Wed, Feb 28, 2001 at 10:49:32AM +1100, Umar Goldeli wrote:

> > 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.

Theres actually nothing very interesting on the firewall (except for the man
pages), if someone gets a shell (root or otherwise) then game is over, they
can bounce off the firewall and attack the hosts its trying to protect. Non
root will have to work around the filters, both input and output are 
filtered, but that won't stop them. If a cracker wants to spend time rooting
the firewall I wish them well, at least while they are trying to get root on
the firewall, they aren't trying to attack other hosts.

> Correct. As well as seemingly harmles binaries like "uname" and even the
> layout of the filesystem.

Removing uname isn't going to buy me much.
find  /proc -exec less {} \;
/proc is bad, mmmkay.

I've never tried to run a box without proc, I might give it a go.

> > 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 ;) 

You bring up a good point about ntp auth, obviously ntp will be filtered, but that
won't stop forged packets (and unfortunately, neither will some of our routers
(yet)). I wonder if someone could send bogus ntp packets and shift the time on 
the firewall?


-- 
chesty


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Re: Security Breaches

[Crossfire]

Umar Goldeli was once rumoured to have said:
> > ...or keep this discussion on list for those who cannot get to SLUG
> > meetings.
> 
> Or both.. I'd be happy to do a presentation or a QA session on security if
> anyone's interested.. and consdering that a lot of people on this list are
> admins or working in IT - it'd be quite good to keep it on methodology as
> opposed to specific products/tools.. this way general solaris admins or
> network engineers could also benefit..?

Give me some time to brush up on netfilter and I'll happily do a
NetFilter/IpChains, whats new, good, why, and how do we use it?  type
presentation at a SLUG meeting sometime.  I just haven't gotten around
to setting up the new firewall here (at work) yet :/

> The only problem with atime records is when you're playing with squid etc
> and a lot of people put their cache partition in /var/cache or similar and
> mount /var noatime - which sucks for forensics, but will certainly make
> your squid fly. ;)

Squid should be caching to its own dedicated partition, perferably to
its own dedicated spindle if possible, both for reasons of performance
and sanity (ok, mostly sanity ;) ).  Then the noatime thing only
becomes an issue if the cache spindle is used as part of the attack.

> (you should whack squid elsewhere btw! :)

Undoubtably.  See my previous comments about leaving no services to
compromise.

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Re: Security Breaches

[Umar Goldeli]

> BTW, when you do a backup to tape, would that not alter the atime?

Oh one more thing - it will alter the atime on /dev/sdb1 (or whatever) -
but that's not exactly going to be useful anyway.

With the /dev tree - mainly you're concerned with dodgy devices - a lot of
people make a /dev/rpty123 or some other unixy sounding device filename to
hide things..

One of the things that Umar's Dodgy Forensics Package(tm) will do is go
through /dev and yell if it sees plain files that should be there.. I'm
thinking of having an option like "Lookfordodgythings" and allowing
various levels of paranoia.. but I want to keep the tool out of the
analysis side of things and keep it purely for reporting/sanitization
etc..

//umar.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Re: Security Breaches

[Howard Lowndes]

...or keep this discussion on list for those who cannot get to SLUG
meetings.

BTW, when you do a backup to tape, would that not alter the atime?

-- 
Howard.

LANNet Computing Associates 
"...well, it worked before _you_ touched it!"   --me
"I trust just one person,
 and there are times when I don't even trust myself"
--me

On Wed, 28 Feb 2001, Umar Goldeli wrote:

> Perhaps we should have another SLUG meeting on security with a QA session
> or a BOF session (or even a BOFH session ;)


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Re: Security Breaches

[Umar Goldeli]

> ...or keep this discussion on list for those who cannot get to SLUG
> meetings.

Or both.. I'd be happy to do a presentation or a QA session on security if
anyone's interested.. and consdering that a lot of people on this list are
admins or working in IT - it'd be quite good to keep it on methodology as
opposed to specific products/tools.. this way general solaris admins or
network engineers could also benefit..?

> BTW, when you do a backup to tape, would that not alter the atime?

Note - not "backup" - a "dd" - atime only changes if you access the inode
directly - a dd will use the device (e.g. /dev/sdb1) as opposed to the
separate files on that filesystem.

dd is your friend.. I always have a statically compiled version handy when
going on-site.. don't use the dd on the compromised box if you can help
it!

And if at all possible, try not to touch the keyboard much when you get to
the scene.. take a photo beforehand if possible and maintain a log of who
comes in/out of the area where the compromised box is.

Remember - you can't prosecute unless you have perfect details which
aren't "questionable" - be surgically precise.

The only problem with atime records is when you're playing with squid etc
and a lot of people put their cache partition in /var/cache or similar and
mount /var noatime - which sucks for forensics, but will certainly make
your squid fly. ;)

(you should whack squid elsewhere btw! :)



//umar.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Silly eth question.

[Howard Lowndes]

I had this the other day.  Both cards identical, but one had a cable
connected  and the other didn't.  The one with the cable connected got
eth0 even though it was in the further PCI slot than the other card.  So I
guess there must be a number of factors.  I shall have to try them with
the cable swapped to the other card.

-- 
Howard.

LANNet Computing Associates 
"...well, it worked before _you_ touched it!"   --me
"I trust just one person,
 and there are times when I don't even trust myself"
--me

On Wed, 28 Feb 2001, John Ferlito wrote:

> On Wed, Feb 28, 2001 at 03:52:42PM +1100, Martin wrote:
> > 2 ethernet cards, both Netgear FA310tx
> >
> > both detected fine.
> >
> > question is, is there any way to tell which physical card is eth0 and
> > which is eth1 ?
>
>   I just usually plug some ethernet in and bring one device up and
> swap the ethernet cable to work out which one it is. Then label it :)
> >
> > and, will they always be detected in the same order ? (ie. so that eth0
> > will always refer to the same physical card)
>
>   As long as you don't move where the cards are in the pci slots
> then yes. I think there might be some sort of rule like the card closest
> the cpu is eth0 or something but I'm not sure. If so this is only the
> case if the cards are of the same type. If they're different types and
> they;re compiled into the kernel then the interface is chosen by the
> order they get detected which is which ever order it is in the .c file.
> This wil always remain the same no matter what slot the cards are in. If
> you use modules it depends on how you pout in the aliases eg alias tulip
> eth0 will determin which is which.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Basic Unix commands

[Michael Lake]

Ken Foskey wrote:
> How do I create a floppy disk from Unix.

1. to format a floppy disk under Linux you use the 'fdformat' command.
   The man pages for this ie 'man fdformat' will tell you heaps. 

   Example: to format the first floppy disk which is fd0 to High Density
1.44 Meg we use:
   (the $ is the prompt) 

$ fdformat /dev/fd0H1440 
$ Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.
$ Formatting ... done
$ Verifying ... Problem reading cylinder 3, expected 18432, read 12288

Oh... a bad floppy well.
(You can even try for fdformat /dev/fd0H1722)

2. Now we actually put a file system on it. With DOS/Windows you can
only put one type of file system on a floppy but Linux can read and
write many different systems from DOS to Windows to Macintosh and dozens
more so we have to use another comand to say what we want to put on it.
Windows users have it easy eh :-) In the next few commands read the man
pages for mkfs (short for make file system) to find out what the -c and
-v are for :-)

This is how to write a msdos file system to your newly formatted floppy:
/sbin/mkfs -t msdos -c -v /dev/fd0

This is how to write a Windows file system to your newly formatted
floppy:
/sbin/mkfs -t vfat -c -v /dev/fd0

This is how to write a Linux file system to your newly formatted floppy:
/sbin/mkfs -t ext2 -c -v /dev/fd0

Here is a transcript of when I just did it a few mins ago
$ /sbin/mkfs -t ext2 -c -v /dev/fd0
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
184 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
1 block group
8192 blocks per group, 8192 fragments per group
184 inodes per group

Running command: badblocks -b 1024 -s /dev/fd0 1440
Checking for bad blocks (read-only test): done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

3. Now its ready. But before we can write to it we have to mount it.
Again 'man mount' for fun.

mount -t ext2 /dev/fd0 /mnt

Now you can copy to it like so:
cp myfile /mnt

Don't forget to unmount it before you pull out the floppy
umount /mnt


Next read up on the fstab file as putting some info in there about the
/dev/fd0 will make life easier and you wont have to type as much next
time. Thats for another day :-)

Best wishes
Mike
-- 

Michael Lake
University of Technology, Sydney
Email: mailto:[EMAIL PROTECTED] Ph: 02 9514 1724 Fx: 02 9514 1628 
URL: http://www.science.uts.edu.au/~michael-lake/
Linux enthusiast, active caver and interested in anything technical.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Re: Security Breaches

[Crossfire]

Umar Goldeli was once rumoured to have said:
> Perhaps we should have another SLUG meeting on security with a QA
> session or a BOF session (or even a BOFH session ;)

I'll be up for a BOFH session >:) Maybe we'll have to declare thursday
night at the SLUG stand as BOFH night ;)

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Re: Security Breaches

[Umar Goldeli]

> > a "netstat -an | grep LISTEN" will show you "evilthings(tm)" ;)
> 
> Not necessarily.  Some rootkits have nobbled the "netstat", "ps" and other 
> system binaries, so that they don't show up suspicious processes/listening 
> ports/logged in users.  

Agreed thoroughly. But remember, this is assuming you have made the
executive decision and considered your box compromised.

Every admin should also have a statically compiled set of tools on CD
btw. Not only can binaires be trojaned, but so can libraries.

> If anyone has managed to get access illegally, you _MUST_ assume that they have 
> root access.  There is no way you can assume that they got in as a normal user, 
> and managed to find a way to access privileged information.

I agree with you. However it really depends on your motives and your
course of action. This discussion is academic.

> > It could be anything.. either way - you know that something has
> > happened. Make an executive decision to decide if it has (I think it
> > has) and pull the box from production, rebuild it, secure it, patch it,
> > then change all user passwords (if any).
> 
> If possible it would be good to pull the box out, and compare the system to the 
> distribution RPMS - you can compare the RPMS and see if anything has changed.  
> That way, you can send information to AusCERT and CERT. 

Bollocks. Before even *thinking* of doing analysis, dump the filesystems
with dd onto tape, make two copies and impound the compromised
box. Start a log in a notebook (paper) and note exactly what you do and 
who has which tapes to preserve the "chain of custody". Then take one tape
as your analysis copy and remount those filesystems on loopback (ro) on
another box. Then and only then should you analyze.

Remember boys and girls, the instant you do a cat /etc/shadow or anything
- you are destroying evidence. You are modifying the atime records on the
inodes at the very least. There is no chance in hell you will prosecute
after this.

Maintaining integrity of forensic data is an art form (especially if you
wish to prosecute - well your CIO will want to anyway).

> Then you rebuild from distribution media.  I wouldn't rely on backups, as you 
> don't know exactly when they managed to hack into your machine. 

I agree with Rebecca here in regards to not trusting backups. But this
brings me to another point.. well argued with many people.. why backup
whole filesystems at all? Especially in a secure/firewalled
environment.. I tend to believe in backing up config files only - no
binaries.. as you may see, there are pros and cons of doing this.. but it
depends on your environment and requirements.

> And you expect them to give you any clues?  You should assume that they broke 
> in, and removed most traces of the hack.  A casual inspection would most likely 
> not show anything to be amiss.

They have already left many clues. /etc/inetd.conf is a big one. ;)

> However, if you have Tripwire or something similar, you can determine which 
> files have been changed.

You'd have better luck with Veracity.

> Another thing to consider is to use IP Chains or IP Tables or something to 
> provide some form of defense against portscans and stuff.  It's not going to 
> stop them cold, but it can help slow them down.

Portscans are fine. Everybody gets portscanned everyday. The important
thing is to not have any vulnerable services or a vulnerable kernel. Use
ipchains etc to only accept packets destined to services which you intend
to provide. Don't forget your outbound acl's on your border router!

Also - don't forget to protect your routers.. and also use them to protect
you.

Perhaps we should have another SLUG meeting on security with a QA session
or a BOF session (or even a BOFH session ;)


//umar.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Apt cache file corrupt...

[Matthew Dalton]

Steven downing wrote:
> 'Apt-get update'  updates the list of available packages yeah?
> 
> And I was thinking that the packages cache file
> (/var/cache/apt/packages.bin??), was an index of files which had
> been downloaded from a network source (and possibly not
> yet installed on the system)


Read this:
http://groups.yahoo.com/group/newbiedoc/files/apt-get-intro.html


Matthew

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Silly eth question.

[Martin]

> Ping them and watch the traffic from the port.

i'll give that a go...

> In a given hardware setup, yes. Once you swap slots, change
> motherboards, things may change.

i read something just after i sent that message that detection order
(and hence the numbering) was reliant on which PCI slot each card was
in...

so, in theory, if you don't move them they won't change...

thanks
marty

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Silly eth question.

[Crossfire]

John Ferlito was once rumoured to have said:
> On Wed, Feb 28, 2001 at 03:52:42PM +1100, Martin wrote:
>> 2 ethernet cards, both Netgear FA310tx
>> 
>> both detected fine.
>> 
>> question is, is there any way to tell which physical card is eth0 and
>> which is eth1 ?
> 
>   I just usually plug some ethernet in and bring one device up and
> swap the ethernet cable to work out which one it is. Then label it :)

Better way is to copy the hardware address onto the back of the card
where you can see it, and check them against data from ifconfig.

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Re: Security Breaches

[Crossfire]

Rebecca Richards was once rumoured to have said:
> Hi Everyone,

Hey There!

>> From: Umar Goldeli <[EMAIL PROTECTED]>
>> To: Sean Carmody <[EMAIL PROTECTED]>
>> Subject: Re: [SLUG] Security Breach
>> 
>>> Feb 28 01:53:07 emu portmap[12152]: connect from 202.157.133.184 to
>>> getport(status): request from unauthorized host
>> 
>> Why are you rnning the portmapper? Turn it off if youdon't specifically
>> need it.
> 
> I would agree with you on this one.  RPC services is a favourite for script-
> kiddies, and buffer overflows will often give remote root access.
> 
>> a "netstat -an | grep LISTEN" will show you "evilthings(tm)" ;)
> 
> Not necessarily.  Some rootkits have nobbled the "netstat", "ps" and other 
> system binaries, so that they don't show up suspicious processes/listening 
> ports/logged in users.  

This is a common trick with the average rootkit.  Other things that
are somtimes affected include ls, login, and a few other vital
programs.  And don't count on strings showing you such changes - some
people handle this most subtlely.

The root kits that were used against named on ix86/linux against the
ANU in '98 had a login replacement which had a backdoor account
"rewt".  Of course, strings wouldn't show up "rewt" in the binary.
Other fun tricks included traffic sniffing to get plaintext passwords,
which were stored in a directory named "~/. ".  ls was patched not to
show this directory, ps tools and netstat were patched not to show the
sniffer, and inetd was also replaced with a buggy version that died
when you HUP'd it!  [I got hired to clean up and maintain the OS lab
after the attacks]
 
>> Remember - root access is generally the *eventual* goal... just because he
>> got in as userx, doesn't mean he has root, or even a shell for that
>> matter. 
> 
> Yes, it is the eventual goal, but on some occasions, they get it
> first up.  If anyone has managed to get access illegally, you _MUST_
> assume that they have root access.  There is no way you can assume
> that they got in as a normal user, and managed to find a way to
> access privileged information.

Basic rule: Assume your attacker knows what he's doing, that way the
idiots don't come close.

>> From: Simon Bowden <[EMAIL PROTECTED]>
>> Subject: Re: [SLUG] Security Breach
> 
>> I think this is because somewhere in teh process of getting in,
>> they broke my local named (i wasnt working in the morning) - that or
>> somewhere upstream someone hurt DNS - I was getting a lot of "Lame
>> server
> 
> Sounds like they are using BIND exploits.

Given that the ANU attack was through a vunerable named, and that
named has always been a popular target, its hardly surprising.

If you want to keep ahead of these things, you want to be on CERT
lists, and you want to keep an eye on news sites which are likely to
make noise over such holes.  IIRC, /. made a significant amount of
noise over the recent bind exploits.

>> The ISP I was on was Telstra bigpond - if its the same, maybe they were
>> scanning that range of addresses.
> 
> Bigpond what? Cable, ADSL, dial-up?
> 
> Suspiciously, this afternoon their ADSL service went on the blink.  I wonder 
> whether that outage is connected or not...

I doubt it.  Telstra just seems to be very good at screwing up.  Never
mind that the network is already overprovisioned.

Fortunately the network just came back online.

>> The other change I found was the following entry on the end of
>> /etc/inetd.conf:
>> 1008 stream tcp nowait root /bin/sh sh

This is a definate sign that you've been compromised quite seriously.

>> 
>> which you may want to check for and remove/comment.
> 
> I would remove it - in fact a rebuild should be the only option at
> this point, as you can't be sure of anything on the system anymore.

Definately.

>> The fact taht they edited /etc/inetd.conf and cat-d shadow indicates root
>> priveleges. However, there doesnt seem to be any evidence of things inside
>> or other changes, so possibly a buffer of exploit type deal?
>
> And you expect them to give you any clues?  You should assume that
> they broke in, and removed most traces of the hack.  A casual
> inspection would most likely not show anything to be amiss.

This is another arugment for remote logging in conjunction with local
logging - if your logs are being echoed to a second machine, they need
to break into both machines to remove evidence.  Packet/Firewall logs
are excellent evidence of such attacks.

> However, if you have Tripwire or something similar, you can determine which 
> files have been changed.

Only if you have tripware status logs on live RO media, or backed up
somewhere safe.

Same applies for rpm's verify features.
 
> Another thing to consider is to use IP Chains or IP Tables or something to 
> provide some form of defense against portscans and stuff.  It's not going to 
> stop them cold, but it can help slow them down.

ipchains wouldn't help much - ipchains is stateless, and you need to
leave services that you want acc

Re: [SLUG] Silly eth question.

[John Ferlito]

On Wed, Feb 28, 2001 at 03:52:42PM +1100, Martin wrote:
> 2 ethernet cards, both Netgear FA310tx
> 
> both detected fine.
> 
> question is, is there any way to tell which physical card is eth0 and
> which is eth1 ?

I just usually plug some ethernet in and bring one device up and
swap the ethernet cable to work out which one it is. Then label it :)
> 
> and, will they always be detected in the same order ? (ie. so that eth0
> will always refer to the same physical card)

As long as you don't move where the cards are in the pci slots
then yes. I think there might be some sort of rule like the card closest
the cpu is eth0 or something but I'm not sure. If so this is only the
case if the cards are of the same type. If they're different types and
they;re compiled into the kernel then the interface is chosen by the
order they get detected which is which ever order it is in the .c file.
This wil always remain the same no matter what slot the cards are in. If
you use modules it depends on how you pout in the aliases eg alias tulip
eth0 will determin which is which.

> 
> thanks
> marty
> 
> -- 
> SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
> More Info: http://slug.org.au/lists/listinfo/slug

-- 
John Ferlito
Senior Engineer - Bulletproof Networks
ph: +61 (0) 410 519 382
http://www.bulletproof.net.au/

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] Silly eth question.

[Martin]

Hi guys,

situation:

2 ethernet cards, both Netgear FA310tx

both detected fine.

question is, is there any way to tell which physical card is eth0 and
which is eth1 ?

and, will they always be detected in the same order ? (ie. so that eth0
will always refer to the same physical card)

thanks
marty

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Apt cache file corrupt...

[Steven downing]

>>> Crossfire <[EMAIL PROTECTED]> 28/02/01 15:16:26 >>>
Steven downing was once rumoured to have said:
[Details snipped]
>> 
>> E:The package cache file is corrupted.
>> 
>> Which made me think the .deb was corrupted via Windows
>> stoopidnes (It might still be I guess), but closer reading leads
>> me to think the apt cache is corrupt
>> (/var/cache/apt/packages.bin or whatever it is).

>have you even considered an apt-get update?
>
>C.

Not really, but I guess it's worth a try..
'Apt-get update'  updates the list of available packages yeah?

And I was thinking that the packages cache file
(/var/cache/apt/packages.bin??), was an index of files which had
been downloaded from a network source (and possibly not
yet installed on the system)

Anyway, I'll give it a go tonite

thanks
Steve



--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Security Breach

[Howard Lowndes]

If it got the contents of /etc/shadow then they got root as that file is
normally only readable by root.  Big worry.

-- 
Howard.

LANNet Computing Associates 
"...well, it worked before _you_ touched it!"   --me
"I trust just one person,
 and there are times when I don't even trust myself"
--me

On Wed, 28 Feb 2001, Simon Bowden wrote:

> Hi,
>
> This occurred to me as well last night - I think around 3am. Similarly, it
> was discovered because the mail destination domain could not be found.
> However, I think this is because somewhere in teh process of getting in,
> they broke my local named (i wasnt working in the morning) - that or
> somewhere upstream someone hurt DNS - I was getting a lot of "Lame server
> errors". The email contained the output of ifconfig and the contents of
> /etc/passwd and /etc/shadow.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] Re: Security Breaches

[Rebecca Richards]

Hi Everyone,


> From: Umar Goldeli <[EMAIL PROTECTED]>
> To: Sean Carmody <[EMAIL PROTECTED]>
> Subject: Re: [SLUG] Security Breach
> 
> > Feb 28 01:53:07 emu portmap[12152]: connect from 202.157.133.184 to
> > getport(status): request from unauthorized host
> 
> Why are you rnning the portmapper? Turn it off if youdon't specifically
> need it.

I would agree with you on this one.  RPC services is a favourite for script-
kiddies, and buffer overflows will often give remote root access.

> a "netstat -an | grep LISTEN" will show you "evilthings(tm)" ;)

Not necessarily.  Some rootkits have nobbled the "netstat", "ps" and other 
system binaries, so that they don't show up suspicious processes/listening 
ports/logged in users.  

> Remember - root access is generally the *eventual* goal... just because he
> got in as userx, doesn't mean he has root, or even a shell for that
> matter. 

Yes, it is the eventual goal, but on some occasions, they get it first up.

If anyone has managed to get access illegally, you _MUST_ assume that they have 
root access.  There is no way you can assume that they got in as a normal user, 
and managed to find a way to access privileged information.

> It could be as simple as a buffer oveflow with something like
> "/bin/mailx < /etc/passwd [EMAIL PROTECTED]" etc.. (or somehting like
> that)..

Yes, there are many forms of "compromise" available.  If the attacker is able 
to run a command as root (which it seems they have been able to do in order to 
get access to /etc/shadow), you must assume that they have been able to 
compromise the machine in a way as to provide remote shell access.  There are 
several backdoor proggies available to the script kiddies to assist them to do 
this.

> It could be anything.. either way - you know that something has
> happened. Make an executive decision to decide if it has (I think it
> has) and pull the box from production, rebuild it, secure it, patch it,
> then change all user passwords (if any).

If possible it would be good to pull the box out, and compare the system to the 
distribution RPMS - you can compare the RPMS and see if anything has changed.  
That way, you can send information to AusCERT and CERT. 

Then you rebuild from distribution media.  I wouldn't rely on backups, as you 
don't know exactly when they managed to hack into your machine. 


> From: Simon Bowden <[EMAIL PROTECTED]>
> Subject: Re: [SLUG] Security Breach

> I think this is because somewhere in teh process of getting in,
> they broke my local named (i wasnt working in the morning) - that or
> somewhere upstream someone hurt DNS - I was getting a lot of "Lame
> server

Sounds like they are using BIND exploits.

> The ISP I was on was Telstra bigpond - if its the same, maybe they were
> scanning that range of addresses.

Bigpond what? Cable, ADSL, dial-up?

Suspiciously, this afternoon their ADSL service went on the blink.  I wonder 
whether that outage is connected or not...

> The other change I found was the following entry on the end of
> /etc/inetd.conf:
> 1008 stream tcp nowait root /bin/sh sh
> 
> which you may want to check for and remove/comment.

I would remove it - in fact a rebuild should be the only option at this point, 
as you can't be sure of anything on the system anymore.


> The fact taht they edited /etc/inetd.conf and cat-d shadow indicates root
> priveleges. However, there doesnt seem to be any evidence of things inside
> or other changes, so possibly a buffer of exploit type deal?

And you expect them to give you any clues?  You should assume that they broke 
in, and removed most traces of the hack.  A casual inspection would most likely 
not show anything to be amiss.

However, if you have Tripwire or something similar, you can determine which 
files have been changed.

Another thing to consider is to use IP Chains or IP Tables or something to 
provide some form of defense against portscans and stuff.  It's not going to 
stop them cold, but it can help slow them down.

Rebecca Richards, CCSA CCSE, Unix/Security Consultant, e-Secure Pty Ltd
"Secure in a Networked World" Phone:  (02) 9438 4984 Fax: (02) 9438 4986
Suite 201, 2-4 Pacific HighwayMobile: 0412 823 206
St Leonards NSW Australia Email:  [EMAIL PROTECTED]
ACN 068 798 194   http://www.e-secure.com.au

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Apt cache file corrupt...

[Crossfire]

Steven downing was once rumoured to have said:
[Details snipped]
> This seems (to me!) to imply some kind of lack of memory (MMap??)
> So I made sure nothing much was running and tried again, but every
> subsequent apt-cache add came up with..
> 
> E:The package cache file is corrupted.
> 
> Which made me think the .deb was corrupted via Windows
> stoopidnes (It might still be I guess), but closer reading leads
> me to think the apt cache is corrupt
> (/var/cache/apt/packages.bin or whatever it is).

[more snipped]

> Sooo, anyone got any ideas? Various Googling and
> slug.org/debian.org searches haven't yeilded anything yet.

have you even considered an apt-get update?

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

RE: [SLUG] Apt cache file corrupt...

[Visser, Martin (SNO)]

--8<- 

> E:The package cache file is corrupted.

--8<- 



Did you hear that?

Hear what?

I think it's the sound of all the apt-get fans running for cover!  ;-)


Martin Visser
Technology Consultant - Compaq Global Services

Compaq Computer Australia
410 Concord Road
Rhodes, Sydney NSW 2138
Australia

Phone: +61-2-9022-5630
Mobile: +61-411-254-513
Fax:+61-2-9022-7001
Email:[EMAIL PROTECTED]


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] How to make program to respond program delivery in NetscapeMessaging Server

[Rick Welykochy]

On Tue, 27 Feb 2001, Le Nhu Hai wrote:

> Hi everybody,
> 
> I am using Netscape Messaging Server 4.1 (both on
> Solaris & NT 4.0). Netscape offers "Program Delivery"
> function wich enable a program auto-run when a new
> mail arrived. I had read some guide docs from Netscape
> (Admin Docs, Messaging Access SDK,...) but they don't
> tell me how does the program can get the arrival mail,
> and how to parse it. 
> 
> Who know this can help me ?

Who knows what this has to do with Linux. Or SLUG.
Who posts from web-abased email these days? How gauche.


--
Rick Welykochy || Praxis Services



-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Basic Unix commands

[Andrew Reilly]

On Wed, Feb 28, 2001 at 12:55:51PM +1100, Ken Foskey wrote:
> How do I create a floppy disk from Unix.

There are many ways, but one of the most useful is the "mtools"
utilities.  If you find and install them, you can then use
mformat, mcopy mdir, and so on, and treat it just like a DOS
floppy.

Floppies formatted with Unix file systems, or used as simple tar
archives are also possible, but considerably less useful.

> How do I print from Unix,  how do I change print settings.

That's an excellent question.  Once upon a time, the simple
answer was "lpd", but things have become more complicated.  For
the most part, there _arent_ any print settings.  Do what I do:
don't print.  It's better for the environment that way.

-- 
Andrew

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] CD record

[Crossfire]

Ken Foskey was once rumoured to have said:
> 
> Just reading the cdrecord setup for ATAPI it recommends that I add a
> line like the last one in my lilo.conf
> 
> image = /boot/win4lin
> label = cdr
> read-only
> root = /dev/hda3
> hdc = ide-scsi
> 
> The last line,  but this gives me: 
>   Added cdr
>   Syntax error near line 23 in file /etc/lilo.conf

Thats because it should read:
  append = "hdc=ide-scsi"

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] CD record

[Jeff Waugh]

> hdc = ide-scsi
> 
> The last line,  but this gives me: 
>   Added cdr
>   Syntax error near line 23 in file /etc/lilo.conf

Change it to:

append="hdc=ide-scsi"

> SmartArses >[EMAIL PROTECTED], I cannot afford a real SCSI drive :-}

Bah. Waste of money for a casual use CD burner.

- Jeff


-- [EMAIL PROTECTED] --- http://linux.conf.au/ --

  "GIMP is the primary tool in my graphics work. It is my gcc and   
Emacs." - Tuomas Kuosmanen (tigert) 

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] mice/Debian

[Crossfire]

David was once rumoured to have said:
> 
> simple things that make me weep.
> 
> I'm installing a new Debian and can't get the mouse to work. I doubt it's
> hardware, because: 
> 
> This box is a test bed, and yesterday this mouse worked fine under SuSE;
> The mouse works through a switch and works fine on three other boxes;
> I haven't moved the hardware at all (except the mouse of course ;-)
> 
> On the old RH install, gpm looks like this:
> [david@ns david]$ ps ax | grep gpm
>   521 ttyS0S  0:00 gpm -t ms
> The debian version looks like this:
> david@test:~$ ps ax | grep gpm
>   509 ?S  0:00 /usr/sbin/gpm -m /dev/mouse -t ms


Of course, I'm going to ask the stupid question(s).

Have you made sure that the /dev/mouse symlink points to the right
serial device?

Have you also made sure that the serial module is loaded?

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] CD record

[Ken Foskey]

Just reading the cdrecord setup for ATAPI it recommends that I add a
line like the last one in my lilo.conf

image = /boot/win4lin
label = cdr
read-only
root = /dev/hda3
hdc = ide-scsi

The last line,  but this gives me: 
Added cdr
Syntax error near line 23 in file /etc/lilo.conf

Which of course is the atapi fix I am trying to install.   How do you
make an ATAPI drive a SCSI drive?

RedHat 6.2   sg is apparently already installed.
Using /lib/modules/2.2.16-3/scsi/sg.o
insmod: a module named sg already exists

'cdrecord -scanbus' helpfully suggests I use the scanbus option :-}

KenF
SmartArses >[EMAIL PROTECTED], I cannot afford a real SCSI drive :-}

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] mice/Debian

[David]

simple things that make me weep.

I'm installing a new Debian and can't get the mouse to work. I doubt it's
hardware, because: 

This box is a test bed, and yesterday this mouse worked fine under SuSE;
The mouse works through a switch and works fine on three other boxes;
I haven't moved the hardware at all (except the mouse of course ;-)

On the old RH install, gpm looks like this:
[david@ns david]$ ps ax | grep gpm
  521 ttyS0S  0:00 gpm -t ms
The debian version looks like this:
david@test:~$ ps ax | grep gpm
  509 ?S  0:00 /usr/sbin/gpm -m /dev/mouse -t ms

What dumb thing have I done?

PS, for debianites ... while trying to resolve this problem in the
X-configuration part of the installation, I managed to totally freeze the
box and had to hit reset :(


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] How to make program to respond program delivery in Netscape Messaging Server

[Le Nhu Hai]

Hi everybody,

I am using Netscape Messaging Server 4.1 (both on
Solaris & NT 4.0). Netscape offers "Program Delivery"
function wich enable a program auto-run when a new
mail arrived. I had read some guide docs from Netscape
(Admin Docs, Messaging Access SDK,...) but they don't
tell me how does the program can get the arrival mail,
and how to parse it. 

Who know this can help me ?

Thank you very much

Le Nhu Hai

[EMAIL PROTECTED]



__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Security Breach

[Simon Bowden]

Hi,

This occurred to me as well last night - I think around 3am. Similarly, it
was discovered because the mail destination domain could not be found.
However, I think this is because somewhere in teh process of getting in,
they broke my local named (i wasnt working in the morning) - that or
somewhere upstream someone hurt DNS - I was getting a lot of "Lame server
errors". The email contained the output of ifconfig and the contents of
/etc/passwd and /etc/shadow.

The ISP I was on was Telstra bigpond - if its the same, maybe they were
scanning that range of addresses.

The other change I found was the following entry on the end of
/etc/inetd.conf:
1008 stream tcp nowait root /bin/sh sh

which you may want to check for and remove/comment.
 
I am thinking it could have been the BIND exploit coming active, but not
sure (I havent upgraded yet, and my listen-on clause was broken - now fixed
not to listen outside).

The fact taht they edited /etc/inetd.conf and cat-d shadow indicates root
priveleges. However, there doesnt seem to be any evidence of things inside
or other changes, so possibly a buffer of exploit type deal?

I run RH6.2 btw :)
The only services i had running out of inetd were ftp, telnet and auth
(first 2 are shut down until i get home to tighten things) - not portmap.

Makes you wonder if one should send an edited email with prepared IP and
ready a box to trace what happens :)

 - Simon

>Last night I experienced a security breach. I run a small lan with a
>ppp dial-up connection that is often left connected. It seems that at
>11pm an email containing the output of ifconfig and the contents of
>the passwd files was sent by root to [EMAIL PROTECTED] Luckily the mail
>was bounced by our ISP (thanks to the lan's domain name not being found
>by the ISP's DNS).
>Scouring the log files, the only evidence of this breach I can file
>is the log of the attempted mail send in /var/log/maillog and the following
>suspicious entry in /var/log/messages:
>Feb 28 01:53:07 emu portmap[12152]: connect from 202.157.133.184 to
>getport(status): request from unauthorized host
>This is the only portmap log I've ever had.
>Has anyone come across something similar? I've no idea whether this is
>the result of a trojan, or whether someone managed to gain access to
>my machine (although if they did gain root access, why mail out a passwd
>file?). Any thoughts?Sean.

--
Simon Bowden
Tech Support, School of Economics, UNSW
3rd Year Computer Engineering Student, UNSW
Mobile: 0414 937 375
email: [EMAIL PROTECTED]

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] ResierFS dependancies?

[Alexander Else]

Hadn't tried beyond 2.4.0 (i should've been more specific in my post).

On Tue, 27 Feb 2001, Michael Covi wrote:

> 
> It's in 2.4.1 and later.
> 


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Security Breach

[kevin]

Adrian Chiang wrote:
> 
> Robert Graham's website has some info on port 1024:
> http://www.robertgraham.com/pubs/firewall-seen.html
> 
> quoted below -
> "1024 - Many people ask the question what this port is used for. The
> answer is that this is the first port number in the dynamic range of ports.
> Many applications don't care what port they use for a network connection, so
> they ask the operating system to assign the "next freely available port". In
> point of fact, they as for port 0, but are assigned one starting with port
> 1024. This means the first application on your system that requests a
> dynamic port will be assigned port 1024. You can test this fact by booting
> your computer, then in one window open a Telnet session, and in another
> window run "netstat -a". You will see that the Telnet application has been
> assigned port 1024 for its end of the connection. As more applications
> request more and more dynamic ports, the operating system will assign
> increasingly higher port numbers. Again, you can watch this effect with
> 'netstat' as your browse the Internet with your web browser, as each
> web-page requires a new connection. "
> 
> not sure about 587...
> 
587 is submission and is used by sendmail
I will assume you are using RedHat 7.0 as 
this is on by default, edit /etc/sendmail.cf
to turn it off if you wisyh
-- 
"[EMAIL PROTECTED] kevin"@oceania.net
"Democracy is two wolves and a lamb voting on what to have for lunch. 
Liberty is a well-armed lamb contesting the vote."
~Benjamin Franklin, 1759

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Security Breach

[John Clarke]

To find out which process is listening on a port, use fuser, e.g.:

[root@dropbear ~]# fuser -n tcp 53
53/tcp:  17479
[root@dropbear ~]# ps ax|grep 17479
17479  ?  S0:29 named -u named 


Cheers,

John
-- 
"Every time I have to pipe something into awk I get this mental picture of a 
big fat seagull with stdin connected at the wrong end."
-- Arthur van der Harg

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] Basic Unix commands

[Ken Foskey]

Jason,

A couple of extra's

How do I create a floppy disk from Unix.
How do I print from Unix,  how do I change print settings.

KenF

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

RE: [SLUG] Security Breach

[Adrian Chiang]

Robert Graham's website has some info on port 1024:
http://www.robertgraham.com/pubs/firewall-seen.html

quoted below -
"1024 - Many people ask the question what this port is used for. The
answer is that this is the first port number in the dynamic range of ports.
Many applications don't care what port they use for a network connection, so
they ask the operating system to assign the "next freely available port". In
point of fact, they as for port 0, but are assigned one starting with port
1024. This means the first application on your system that requests a
dynamic port will be assigned port 1024. You can test this fact by booting
your computer, then in one window open a Telnet session, and in another
window run "netstat -a". You will see that the Telnet application has been
assigned port 1024 for its end of the connection. As more applications
request more and more dynamic ports, the operating system will assign
increasingly higher port numbers. Again, you can watch this effect with
'netstat' as your browse the Internet with your web browser, as each
web-page requires a new connection. "

not sure about 587...

Adrian.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Bernhard Lüder
Sent: Wednesday, 28 February 2001 12:29 PM
To:
Subject: RE: [SLUG] Security Breach


Hi,

In this context. What is port 587 and 1024. I couldn't find these in
/etc/services


tcp0  0 0.0.0.0:587 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:10240.0.0.0:*   LISTEN

Bernhard Lüder

This electronic mail is solely for the use of the addressee and may contain
information that is confidential or privileged.  If you receive this
electronic mail in error, please delete it from your system immediately and
notify the sender by electronic mail.




-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

RE: [SLUG] Security Breach

[Umar Goldeli]

"netstat -ean" will tell you which uid is listening on those ports.

//umar.


On Wed, 28 Feb 2001, [iso-8859-1] Bernhard Lüder wrote:

> Hi,
> 
> In this context. What is port 587 and 1024. I couldn't find these in
> /etc/services
> 
> 
> tcp0  0 0.0.0.0:587 0.0.0.0:*   LISTEN
> tcp0  0 0.0.0.0:10240.0.0.0:*   LISTEN


--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

RE: [SLUG] Security Breach

[Bernhard Lüder]

Hi,

In this context. What is port 587 and 1024. I couldn't find these in
/etc/services


tcp0  0 0.0.0.0:587 0.0.0.0:*   LISTEN
tcp0  0 0.0.0.0:10240.0.0.0:*   LISTEN

Bernhard Lüder

This electronic mail is solely for the use of the addressee and may contain
information that is confidential or privileged.  If you receive this
electronic mail in error, please delete it from your system immediately and
notify the sender by electronic mail.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Umar Goldeli
Sent: Wednesday, February 28, 2001 11:37 AM
To: Sean Carmody
Cc: [EMAIL PROTECTED]
Subject: Re: [SLUG] Security Breach


> Feb 28 01:53:07 emu portmap[12152]: connect from 202.157.133.184 to
> getport(status): request from unauthorized host

Why are you rnning the portmapper? Turn it off if youdon't specifically
need it.

a "netstat -an | grep LISTEN" will show you "evilthings(tm)" ;)

If you don't recognize it as something you specifically need - turn it
off. :)

Either way, chances are that this is not how they got in - he probably did
an rpcinfo -p  or similar and your config recognized that he
wasn't allowed.

As above - if you don't need portmap, turn it off.

> Has anyone come across something similar? I've no idea whether this is
> the result of a trojan, or whether someone managed to gain access to
> my machine (although if they did gain root access, why mail out a passwd
> file?). Any thoughts?

Remember - root access is generally the *eventual* goal... just because he
got in as userx, doesn't mean he has root, or even a shell for that
matter. It could be as simple as a buffer oveflow with something like
"/bin/mailx < /etc/passwd [EMAIL PROTECTED]" etc.. (or somehting like
that)..

It could be anything.. either way - you know that something has
happened. Make an executive decision to decide if it has (I think it
has) and pull the box from production, rebuild it, secure it, patch it,
then change all user passwords (if any).

If you can, pull the box out of prod and put in a new box while you
examine the compromised one.

//umar.



--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug


--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Security Breach

[Umar Goldeli]

> Feb 28 01:53:07 emu portmap[12152]: connect from 202.157.133.184 to
> getport(status): request from unauthorized host

Why are you rnning the portmapper? Turn it off if youdon't specifically
need it.

a "netstat -an | grep LISTEN" will show you "evilthings(tm)" ;)

If you don't recognize it as something you specifically need - turn it
off. :)

Either way, chances are that this is not how they got in - he probably did
an rpcinfo -p  or similar and your config recognized that he
wasn't allowed.

As above - if you don't need portmap, turn it off.

> Has anyone come across something similar? I've no idea whether this is
> the result of a trojan, or whether someone managed to gain access to
> my machine (although if they did gain root access, why mail out a passwd
> file?). Any thoughts?

Remember - root access is generally the *eventual* goal... just because he
got in as userx, doesn't mean he has root, or even a shell for that
matter. It could be as simple as a buffer oveflow with something like
"/bin/mailx < /etc/passwd [EMAIL PROTECTED]" etc.. (or somehting like
that)..

It could be anything.. either way - you know that something has
happened. Make an executive decision to decide if it has (I think it
has) and pull the box from production, rebuild it, secure it, patch it,
then change all user passwords (if any).

If you can, pull the box out of prod and put in a new box while you
examine the compromised one.

//umar.



-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report - advice. :)

[Umar Goldeli]

mounting noexec and nosuid?

man mount

also, mount it "nodev" as well for flavour. :)

//umar.

On Wed, 28 Feb 2001, Howard Lowndes wrote:

> OK, next question.  What's the RTFM for this?


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] mp32wav

[Jason Rennie]

> I am sure there is a simple way to do this, just as there is for ripping a
> CD to mp3s.

xmms has an output to wave option. Instead of to the speakers.

Jason


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Umar Goldeli]

*Every*time. :)

And the procedure is pulled form an outdated copy of the ACS "audit
questions guide" or simply the output of:

/bin/satan-like-product 

:)


//umar.

On Wed, 28 Feb 2001, Howard Lowndes wrote:

> How many times is this a service provided by a large accounting firm using
> green behind the ears accounting grads with a minor in IT.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] Security Breach

[Sean Carmody]

Last night I experienced a security breach. I run a small lan with a
ppp dial-up connection that is often left connected. It seems that at
11pm an email containing the output of ifconfig and the contents of
the passwd files was sent by root to [EMAIL PROTECTED] Luckily the mail
was bounced by our ISP (thanks to the lan's domain name not being found
by the ISP's DNS).

Scouring the log files, the only evidence of this breach I can file
is the log of the attempted mail send in /var/log/maillog and the following
suspicious entry in /var/log/messages:

Feb 28 01:53:07 emu portmap[12152]: connect from 202.157.133.184 to
getport(status): request from unauthorized host

This is the only portmap log I've ever had.

Has anyone come across something similar? I've no idea whether this is
the result of a trojan, or whether someone managed to gain access to
my machine (although if they did gain root access, why mail out a passwd
file?). Any thoughts?

Sean.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Howard Lowndes]

How many times is this a service provided by a large accounting firm using
green behind the ears accounting grads with a minor in IT.

-- 
Howard.

LANNet Computing Associates 
"...well, it worked before _you_ touched it!"   --me
"I trust just one person,
 and there are times when I don't even trust myself"
--me

On Wed, 28 Feb 2001, Umar Goldeli wrote:

> > The good old firewall audit...  Yet to find an auditor who returns a
> > worthwhile report...
>
> It is only too true... most "auditors" are not very useful.. *sigh*


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report - advice. :)

[Howard Lowndes]

OK, next question.  What's the RTFM for this?

-- 
Howard.

LANNet Computing Associates 
"...well, it worked before _you_ touched it!"   --me
"I trust just one person,
 and there are times when I don't even trust myself"
--me

On Wed, 28 Feb 2001, Umar Goldeli wrote:

> Again, you're assuming that they *initially* get root access. If you're in
> as user "squid" chrooted to /cache with only access to /cache/cache1 and
> /cache/cache2 which are mounted noexec and nosuid, what next?


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Umar Goldeli]

> 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 

Re: [SLUG] Firewall security audit report

[Howard Lowndes]

I actually burn my private keys, locked with an access phrase, onto one of
those credit card CDs, together with teraterm software so that I can
support my client's from anywhere that I have Windows and Internet access.
For Linux and Internet access then I only need the keys as the clients
have ssh client on them already.  The CD goes in my wallet.

This probably still doesn't overcome the problem of the CD image being
carried in user memory space tho.

Anyone know how to stop the CD image being carried in memory space?

-- 
Howard.

LANNet Computing Associates 
"...well, it worked before _you_ touched it!"   --me
"I trust just one person,
 and there are times when I don't even trust myself"
--me

On Wed, 28 Feb 2001, Conrad Parker wrote:

>
> Remember that ssh uses host keys for encryption, not personal keys. A
> host's private key is stored on disk and is available to anyone with
> root access.
>
> (cf. personal encryption software, such as GPG, which allows you to store
> your private key on a floppy disk in your shirt pocket, and can take steps
> to ensure that key data is only ever kept in memory and never paged to
> disk).


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Umar Goldeli]

> The good old firewall audit...  Yet to find an auditor who returns a 
> worthwhile report...

It is only too true... most "auditors" are not very useful.. *sigh*

> Of course, you could just upload something into a different partition which
> is read-write (/etc maybe?), but given that we're talking about a firewall,
> every little bit helps!  The fact that some script kiddie can't just run

But Scott, then you mount /etc noexec. ;)

> In particular, you should make sure you have as few suid/sgid programs
> installed. Even programs which normally need SUID to run can probably
> have it dropped - it just means you need to run them as root.

There are pros and cons of this - there is very little on a firewall that
needs to run as root when you think about it. The one binary in particular
that shits me is ssh - remove the SUID bit on it..*sigh*

Also, mount anything and everythig you can nosuid.

> Doing all of the above might mean that your firewall is now (say) 2% more
> secure.  If this was any other machine, you probably wouldn't be to worried
> by such a small improvement, but when you're talking about a firewall,
> every last thing helps!

Indeed. A lot of people say security through obscurity is not worth it -
but it is - it buys you time.. whether it's a week or 10 seconds - it's
time.. well worth it. (There are actual formulae whihc can help you with
cost/benefit/risk analysis, but these aren't exactly too useful).

> Some of the above may fit into the security-by-obsecurity category, but
> as far as I'm concerned, security by obsecurity never hurts - as long as
> you're not relying on it as your primary defence.  We live in a world
> where exploits to the latest bugs are in the hands of the "hackers" of
> the world within hours of the bugs being found. If your extra security
> measures mean that the default exploit fails on your machine because
> /usr is mounted read-only, or because /usr/bin/lpr isn't install on
> your machine then they will move onto the next machine - even if yours
> is still vulnerable to the bug using a different exploit! Hopefully
> by the time a "real" "hacker" decides to try your box, you'll have had
> time to fix the hole.

Absolutely!

> Our standard Solaris build for a server which sits on the internet (not
> actually a firewall, but similar) contains about 50 megs total. It listens
> on a single port (ssh, but not on port 22), has two SUID binaries (su, and
> something else which i forget), has /usr mounted readonly and every other
> partition mounted nosuid, and only runs about a dozen processes (plus
> any for whatever the machine is for of course :)

Sounds like a good plan.. I see way too many companies without a standard
tightened build for unix boxen.. it also makes life easier for admins.


//umar.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Umar Goldeli]

> I concurr with Howard - but their suggestion is legitimate - but for a
> different reason.  PasswordAuthentication means you're relying upon
> users to pick sensible passwords.  Its actually best to make sure
> nobody but your administrators have access to your firewall systems

Unfortunately, nothing can fix this, PKI or Password Auth, both require
passphrases/passwords.. nothing can substitute good education. At least
with PKI - the damn key has to be on the box and the attacker has to
posses the private key before (s)he can start brute forcing.

> It adds no real security IMO.  It just makes things a little more
> awkward, both for admins and for people breaking in - but it doesn't
> grant you any great gains.

It does. See previous post. You are assuming initial root access.

> Security through obscurity.  Bleh.  Get lost.  Obscurity doesn't gain
> any security.

It does. Especially whne you consider that most of your attackers are
going to be 7337 script kiddies.

Imagine a script kiddy on a box with no commands to run except for the
shell built ins and no man pages in a chroot environment..

$kiddy->go_home();

> Removing binaries just means the attackers have to get them in via
> some other means.

Indeed. You're buying time. Time is good. If your attacker can't readily
telnet, ftp, ssh, scp, rcp, wget, lynx etc - he's going to have to try
much harder. And what also happens if there's no compiler on the box? And
better yet, your border router acls do not allow connections ORIGINATING
from your firewall outbound?

> Better yet... Shut down *ALL* listening services.  Log to a remote
> system behind your firewall, make sure you can only log into the
> console, etc.  The best way to protect a system is with the minimum
> footprint approach.  You can't compromise a service that just isn't
> running.

Agreed throughly about the turn of all listening services bit. :)

And those services which are listening - bind them to specific IP addreses
(preferably on the "inside") and make sure they're running non-priv.

As for logging - the safest way to keep logs is to have a serial printer
attached to your console and dumpit all on to paper and focus on physical
secrity of the box. Do what the military does... not veyr practical, but
once written, your logs are there forever. ;)


//umar.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report - advice. :)

[Umar Goldeli]

> > We were advised to turn sshd PasswordAuthentication off because it allows
> > clear text passwords.
> > hey? That doesn't sound right.
> 
> pass

PasswordAuthentication allows the use of an account even if you don't have
a key on the box.. i.e. all you have to know is a username and
password.. and you're in.

The best way to do this is using keys - this also makes access control
easier on the box. So in effect, you should have a separate /etc/passwd
user per admin and in ~/.ssh/authorized_keys (ssh1) you should have the
public key of the admin. PasswordAuthentication should be set to no, and
PermitRootLogin should be set to no. This way, if someone ssh's in, not
only must they have the private key component belonging to the account,
but they must also have the passphrase to decrypt it. Once they're in,
they should su to root.

This way, you have a much more robust authentication scheme and it will
also leave an audit trail of which admin su'd to root etc.

> > Mount partitions read only where possible.
> > I guess this is a good idea, but in what situation would this add security?
> > You need to be root to be able to write to the partitions that I could mount read
> > only, and if someone gets root, they can remount partitions read write.

Two assumptions/problems:

1: you're assuming that they eventually get root access. This is not
always true. Most remote exploits allow an attacked to only get a non-priv
user on the box. From there, they must get root. Run all daemons (where
possible) as non-priv users.

2: Forensics: unmounting, remounting, fiddling and generally playing with
filesystems leaves marks. The more you fiddle, the longer you're on the
box and liable to be caught. The more you fiddle, the more a chance that
you'll leave a trail of sorts. If you have to leave in a hurry and you've
left the system in a non-original state (i.e. mounted rw instead of
ro) after you've trojaned the binaries, there will be a much greater
chance of it being noticed.


> > Remove man pages.
> > Again, I can't see the harm in doing this, but I can't see the point.
> 
> If you don't know what to do, why are you fiddling with box. Basically,
> if someone gets in, man pages help them know the particular variety of
> your box. Just makes it harder for script kiddies, dorfs, staff wanting
> to create ICQ holes, etc to fiddle.

Remove anything nd everything that doesn't serve a purpose on the box,
including libraries, and config files not needed by what needs to
run. Everything on your system is info for an attacker.

This is especially true if the box has been "inherited" or if it has been
setup by someone else who used an "easy install methodology" which asks
you a bunch of questions like "your mail server", "nameservers" etc
etc.. if I'm on your box and I don't know your environment, and I don't
want to immediately portscan your subnet and put your eth into promisc
mode, I can always poke around in /etc/*/* and look for config files which
will point me to other boxes on your network perhaps.. or I may be able to
find implicit trust relationships which will aid me in my next step of
taking your network.

> > Remove unnecessary binaries.
> > A good idea no doubt, but the firewall doesn't allow shell access, and the
> > way I see it is if someone gets shell access they can upload their own bin's.
> 
> 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.

Absolutely. As above - remove anything and everything that isn't needed
specifically!

Think of it this way, I'm on your box, I have a shell as user
"named" (sound familiar anyone? :P ) .. what's my next step?

The next step depends on what I want to do.. let's assume I want root.. ok
- I'm named and I need tools. Ok, let's assume I'm a script kiddy.. the
first thing I'm going to do is to perhaps wget the LRK (linux root kit) or
ftp it down.. or perhaps figure out exactly what kernel I'm running etc or
scan through your pacages and libs to find known vulnerable ones.. then
I'm going to most probably download an exploit..

How do I progress if there isn't a /bin/ftp or a /usr/bin/wget?

There are other ways to get your tools down, but remember, most of your
adversaries are clueless script kiddies who will most probably give up
when they realize that they can't get their root kit or exploits down..

Every additional thing you have on the box is an extra tool for an
attacker. Don't give them any more help.

> > It doesn't mention it in the report, but would mounting /home, /tmp and /var with
> > noexec help? It might stop a non root user from running their own programs, but it
> > won't stop root.

Again, you're assuming that they *initially* get root access. If you're in
as user "squid" chrooted to /cache with only access to /cache/cache1 and
/cache/cache2 which are mounted noexec and nosuid, what next?


//umar.


-- 
SLUG - Sydney Linux User Group Mailing List - h

[SLUG] Apt cache file corrupt...

[Steven downing]

I sucked down Sid the other night, and along the way one file
failed to download, I was using 'apt-get -d' so I could monitor
the update later.  So I grabbed this file, and a couple of others
on a 'doze box at work and put them on a floppy, with the intention
of using 'apt-cache add'.  But when I came to do this I got..

E:Dynamic MMap ran out of room
E:Problem with SelectFile

This seems (to me!) to imply some kind of lack of memory (MMap??)
So I made sure nothing much was running and tried again, but every
subsequent apt-cache add came up with..

E:The package cache file is corrupted.

Which made me think the .deb was corrupted via Windows
stoopidnes (It might still be I guess), but closer reading leads
me to think the apt cache is corrupt
(/var/cache/apt/packages.bin or whatever it is).

The actual debs were copied off the floppy onto HD, and
the exact names reconstructed (they'd been mangled
by 'doze as usual)..

Sooo, anyone got any ideas? Various Googling and
slug.org/debian.org searches haven't yeilded anything yet.

thanks all...

Steve

_
Nothing to read here.
Please move along...


--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] porting serially

[Ken Yap]

|If you need to get a small file from one RH6.2 machine to
|another, and can't use networking, floppy, Zip etc
|but have a null modem, how do you pipe data into/out of ttyS1?

Try kermit.

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Conrad Parker]

On Wed, Feb 28, 2001 at 08:00:58AM +1100, Dave Fitch wrote:
> On Tue, Feb 27, 2001 at 11:54:20PM +1100, Ian Tester wrote:
> > 
> > from ssh(1):
> >  If other authentication methods fail, ssh prompts the user for a pass-
> >  word.  The password is sent to the remote host for checking; however,
> >  since all communications are encrypted, the password cannot be seen by
> >  someone listening on the network.
> 
> yeah but from my /etc/ssh/sshd_config:
> 
> # To disable tunneled clear text passwords, change to no here!
> PasswordAuthentication yes
> 
> So I'm confused...

ssh sets up an encrypted tunnel between two hosts. The client uses the
hosts's public RSA key (/etc/ssh/ssh_host_key.pub) to initiate the
tunnel, encrypted with a stream cipher (eg. IDEA).

Once the encrypted tunnel is established, user authentication is
attempted.

This can take one of several forms, eg.:
* it can send your password over the encrypted tunnel for the other
end to authenticate using its system passwords
* it can use your personal ssh RSA keys: the authenticating host
issues a challenge using a public key stored in your ~/.ssh/authorized_keys;
the connecting host meets it using your private key in ~/.ssh/identity.
Your personal keys aren't used for encryption, just authentication.

Remember that ssh uses host keys for encryption, not personal keys. A
host's private key is stored on disk and is available to anyone with
root access.

(cf. personal encryption software, such as GPG, which allows you to store
your private key on a floppy disk in your shirt pocket, and can take steps
to ensure that key data is only ever kept in memory and never paged to
disk).

Conrad.

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Howard Lowndes]

The key word is "tunneled".  The traffic is still encrypted.  The
PasswordAuthentication option avoids or allows using the account password
at all.

-- 
Howard.

LANNet Computing Associates 
"...well, it worked before _you_ touched it!"   --me
"I trust just one person,
 and there are times when I don't even trust myself"
--me

On Wed, 28 Feb 2001, Dave Fitch wrote:

> On Tue, Feb 27, 2001 at 11:54:20PM +1100, Ian Tester wrote:
> > On Tue, 27 Feb 2001, chesty wrote:
> > > We were advised to turn sshd PasswordAuthentication off because it allows
> > > clear text passwords.
> > > hey? That doesn't sound right.
> >
> > from ssh(1):
> >  If other authentication methods fail, ssh prompts the user for a pass-
> >  word.  The password is sent to the remote host for checking; however,
> >  since all communications are encrypted, the password cannot be seen by
> >  someone listening on the network.
>
> yeah but from my /etc/ssh/sshd_config:
>
> # To disable tunneled clear text passwords, change to no here!
> PasswordAuthentication yes
>
> So I'm confused...
> Dave
>
>


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Dave Fitch]

On Tue, Feb 27, 2001 at 11:54:20PM +1100, Ian Tester wrote:
> On Tue, 27 Feb 2001, chesty wrote:
> > We were advised to turn sshd PasswordAuthentication off because it allows
> > clear text passwords. 
> > hey? That doesn't sound right.
> 
> from ssh(1):
>  If other authentication methods fail, ssh prompts the user for a pass-
>  word.  The password is sent to the remote host for checking; however,
>  since all communications are encrypted, the password cannot be seen by
>  someone listening on the network.

yeah but from my /etc/ssh/sshd_config:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes

So I'm confused...
Dave

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Can't sleep for the NFS

[Crossfire]

Jeff Waugh was once rumoured to have said:
> *yawn* No, I'm not up sysadminning or whatever, I'm just unwell. :) I'd love
> to say I was still up hacking, but I can't concentrate *that* much.
> 
> Anyway, I've been pondering how to go about NFS mounting user directories,
> for X terminals and other uses. Is it best just to mount /home at boot and
> be done with it, or is there a more flexible way of doing things?

autofs/amd was designed for this purpose.  Also because people's
homedirs might be distributed between a group of machines.

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Text calendar program

[Terry Collins]

Richard Piper wrote:
> 
> I have been looking for a reasonably sophisticated text-based
> calendar/diary (something like pine for email). Does anyone have any
> suggestions?

emacs has one 

http://www.woa.com.au  
   WOA Computer Services 

 "People without trees are like fish without clean water"

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Text calendar program

[Howard Lowndes]

Not quite what you are asking, but ical has a nice facility to create a
text list for a perios span.

I use this with a cron job to email me my diary (forward 5 days) each
morning.

cron job:

02 02 * * * /usr/bin/ical -calendar /home/lannet/.calendar -list |
mail -s "Your next 5 day schedule" [EMAIL PROTECTED] 1>/dev/null

-- 
Howard.

LANNet Computing Associates 
"...well, it worked before _you_ touched it!"   --me
"I trust just one person,
 and there are times when I don't even trust myself"
--me

On Wed, 28 Feb 2001, Richard Piper wrote:

> I have been looking for a reasonably sophisticated text-based
> calendar/diary (something like pine for email). Does anyone have any
> suggestions?
>
> thanks
>
> Richard
>
> Richard Piper
> Intensive Care Unit
> Royal North Shore Hospital
> Sydney, Australia
> Work (612) 9926-8617 or 8656
> Home (612) 9419-2339
> Pager (612) 99267111 no 41243
> Mobile 0438-120860
>
>
>


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Terry Collins]

chesty wrote:
> 
> On Tue, Feb 27, 2001 at 09:18:25PM +1100, Terry Collins wrote:
> > > Mount partitions read only where possible.
> > > I guess this is a good idea, but in what situation would this add security?
> > > You need to be root to be able to write to the partitions that I could mount read
> > > only, and if someone gets root, they can remount partitions read write.
> >
> > For a firewall, you want to prevent anyone being able to fiddle with it
> > and one way is to prevent people writing to it is to make it read only.
> 
> 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.

Correct. Obviously your not thinking security. There is no such thing as
absolute security, you just increase the chances of finding signs of
access/changes/fiddling/attempts.. Even root users can fiddle the
firewall and make unauthorised changes to the firewall. If they make
changes, it should show on a log.
> 
> > Tricks like Remote logging,
> 
> Are you talking about syslog out a serial port?
> Is that a trick?

That is one option. Jargon lapse here-  you pipe syslog to another
machine and log it there.

..snip...

--
   Terry Collins {:-)}}} Ph(02) 4627 2186 Fax(02) 4628 7861  
   email: [EMAIL PROTECTED]  www: http://www.woa.com.au  
   WOA Computer Services 

 "People without trees are like fish without clean water"

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Howard Lowndes]

-- 
Howard.

LANNet Computing Associates 
"...well, it worked before _you_ touched it!"   --me
"I trust just one person,
 and there are times when I don't even trust myself"
--me

On Tue, 27 Feb 2001, Crossfire wrote:

> Howard Lowndes was once rumoured to have said:
> > On Tue, 27 Feb 2001, chesty wrote:
> >
> >> We had our linux firewalls audited and I wanted to get some opinions on some
> >> of the issues raised.
> >>
> >> We were advised to turn sshd PasswordAuthentication off because it allows
> >> clear text passwords.
> >> hey? That doesn't sound right.
> >
> > Sounds like good cause to not pay the auditors as they seem not to know
> > what they talk about.
>
> I concurr with Howard - but their suggestion is legitimate - but for a
> different reason.  PasswordAuthentication means you're relying upon
> users to pick sensible passwords.  Its actually best to make sure
> nobody but your administrators have access to your firewall systems

Good point, but this is a firewall we are talking about so the root
account is likely to be under similar control as the ssh user, and
hopefully, we are talking a clueful sysadmin here.  Hope springs eternal.

> >> What do people use for analysing firewall log files?
> >> Theres 84 projects under that category on freshmeat.
>
> grep and less.

or grep and mail, ably aided and abetted by cron.


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] Text calendar program

[Richard Piper]

I have been looking for a reasonably sophisticated text-based
calendar/diary (something like pine for email). Does anyone have any
suggestions?

thanks

Richard

Richard Piper
Intensive Care Unit
Royal North Shore Hospital 
Sydney, Australia
Work (612) 9926-8617 or 8656
Home (612) 9419-2339
Pager (612) 99267111 no 41243
Mobile 0438-120860


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] Can't sleep for the NFS

[Jeff Waugh]

*yawn* No, I'm not up sysadminning or whatever, I'm just unwell. :) I'd love
to say I was still up hacking, but I can't concentrate *that* much.

Anyway, I've been pondering how to go about NFS mounting user directories,
for X terminals and other uses. Is it best just to mount /home at boot and
be done with it, or is there a more flexible way of doing things?

Seems a bit silly to keep the mount when nothing's going on. Perhaps I'm
jsut confused from all the Samba I've had to do in the past.

- Jeff


-- [EMAIL PROTECTED] --- http://linux.conf.au/ --

   No clue is good clue.

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[chesty]

On Tue, Feb 27, 2001 at 09:18:25PM +1100, Terry Collins wrote:
> > Mount partitions read only where possible.
> > I guess this is a good idea, but in what situation would this add security?
> > You need to be root to be able to write to the partitions that I could mount read
> > only, and if someone gets root, they can remount partitions read write.
> 
> For a firewall, you want to prevent anyone being able to fiddle with it
> and one way is to prevent people writing to it is to make it read only.

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.

> Tricks like Remote logging, 

Are you talking about syslog out a serial port?
Is that a trick? 

> temporary files in ram, 

I guess I should check the archives for this one.

> 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.

> > Remove man pages.
> > Again, I can't see the harm in doing this, but I can't see the point.
> 
> If you don't know what to do, why are you fiddling with box. 

I may not know as much as someone like yourself, but that is the reason we got
the security audit.

> Basically,
> 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?

There are bigger give aways than man pages though.
less /var/lib/dpkg/status, and I assume a similar way for redhat.

> > Remove unnecessary binaries.
> > A good idea no doubt, but the firewall doesn't allow shell access, and the
> > way I see it is if someone gets shell access they can upload their own bin's.
> 
> 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 doesn't mention it in the report, but would mounting /home, /tmp and /var with
> > noexec help? It might stop a non root user from running their own programs, but it
> > won't stop root.
> 
> Are we talking about a firewall or what.
> There shouldn't be any users on the firewall.

We have had to make some compromises, time, money, usability are all facters
that needed to be considered. At the moment its part firewall, part bastion
host. The only daemon running at the moment is sshd, and thats to allow X. X
isn't secure, but its needed, we have made a compromise. Using sshd for X
forwarding may not be the best way, but it was the quickest and cheapest way,
another compromise.

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.


-- 
chesty


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] mp32wav

[Ian Tester]

On Tue, 27 Feb 2001, Rodos wrote:

> On Tue, 27 Feb 2001, Jeff Waugh wrote:
> 
> >   mpg123 -w  .mp3
> >   cdrecord dev=0,0,0 speed=8 -pad -audio *.wav
> 
> Thanks Jeff, thats exactly what I was looking for. One CD created and
> working just fine. No coasters here.

If you're looking for a nice GUI, gtoaster is nice. It stumped me the 
first time I looked at it, until I figured out that everything is 
dragon-drop ;)

Just drag an .mp3 or .wav file into the tracks list, and it will be
converted on the fly. Other filetypes can be added in the config, it just
needs to know the commands to determine track length and to convert to raw
PCM. Although I found out the other day that the "--stereo" option should
be added to the mpg123 command line to properly handle mono MP3's. I made
a coaster with double-speed Geeks in Space (slashdot crew) episodes :P

-- 
8<8<8<8<8<8<8<
Ian Tester   *8)#  \7\LINUX: because geeks will find a way
[EMAIL PROTECTED]   \7\  http://www.zipworld.com.au/~imroy



-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Ian Tester]

On Tue, 27 Feb 2001, chesty wrote:

> We were advised to turn sshd PasswordAuthentication off because it allows
> clear text passwords. 
> hey? That doesn't sound right.

from ssh(1):

 If other authentication methods fail, ssh prompts the user for a pass-
 word.  The password is sent to the remote host for checking; however,
 since all communications are encrypted, the password cannot be seen by
 someone listening on the network.

As someone else suggested, withold their payment for not even being able 
to read man pages :)

-- 
8<8<8<8<8<8<8<
Ian Tester   *8)#  \7\LINUX: because geeks will find a way
[EMAIL PROTECTED]   \7\  http://www.zipworld.com.au/~imroy



-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Scott Howard]

On Tue, Feb 27, 2001 at 09:49:33PM +1100, chesty wrote:
> We had our linux firewalls audited and I wanted to get some opinions on some
> of the issues raised.

The good old firewall audit...  Yet to find an auditor who returns a 
worthwhile report...

> We were advised to turn sshd PasswordAuthentication off because it allows
> clear text passwords. 
> hey? That doesn't sound right.

Nope, it's not right. The session will still be encrypted.
There are arguments for not allowing passwords, but they aren't particularly
good ones.

> Mount partitions read only where possible. 
> I guess this is a good idea, but in what situation would this add security?
> You need to be root to be able to write to the partitions that I could mount read 
> only, and if someone gets root, they can remount partitions read write.

I presume this is refering to /usr in particular?  Is every single file
on /usr owned by root?  If not, then what you've said above isn't correct.
If you've got any binaries owned by non-root (eg, "bin") then if someone
can get access to the bin account then they can modify binaries. Ditto for
group write permissions on those files.

Even if all files are root, there's still advantages to making things RO.
eg, consider if you've got a security hole (ie, bug) which allows a user
to upload a binary, but not to actually run it.  If things are mounted
RW it's very easy to upload a new /usr/bin/ls and you're up the creek.

Of course, you could just upload something into a different partition which
is read-write (/etc maybe?), but given that we're talking about a firewall,
every little bit helps!  The fact that some script kiddie can't just run
the script they downloaded to replace /bin/ls is probably enough to make
them move onto the next machine.

> Remove man pages. 
> Again, I can't see the harm in doing this, but I can't see the point. 

A firewall sould be an absolutely minimalist build.  You shouldn't have
anythere there which isn't needed, regardless of what it is.

> Remove unnecessary binaries.
> A good idea no doubt, but the firewall doesn't allow shell access, and the 
> way I see it is if someone gets shell access they can upload their own bin's. 
> 
> It doesn't mention it in the report, but would mounting /home, /tmp and /var with 
> noexec help? It might stop a non root user from running their own programs, but it 
> won't stop root.

Same argument as above.  Users may not have shell access, but that's not the
point - what happens if a hacker gets access!!  Either full shell access, or
even just the ability to run a single command via a bug in a program you're
running (without the ability to upload one first).

In particular, you should make sure you have as few suid/sgid programs
installed. Even programs which normally need SUID to run can probably
have it dropped - it just means you need to run them as root.


Doing all of the above might mean that your firewall is now (say) 2% more
secure.  If this was any other machine, you probably wouldn't be to worried
by such a small improvement, but when you're talking about a firewall,
every last thing helps!

Some of the above may fit into the security-by-obsecurity category, but
as far as I'm concerned, security by obsecurity never hurts - as long as
you're not relying on it as your primary defence.  We live in a world
where exploits to the latest bugs are in the hands of the "hackers" of
the world within hours of the bugs being found. If your extra security
measures mean that the default exploit fails on your machine because
/usr is mounted read-only, or because /usr/bin/lpr isn't install on
your machine then they will move onto the next machine - even if yours
is still vulnerable to the bug using a different exploit! Hopefully
by the time a "real" "hacker" decides to try your box, you'll have had
time to fix the hole.


Our standard Solaris build for a server which sits on the internet (not
actually a firewall, but similar) contains about 50 megs total. It listens
on a single port (ssh, but not on port 22), has two SUID binaries (su, and
something else which i forget), has /usr mounted readonly and every other
partition mounted nosuid, and only runs about a dozen processes (plus
any for whatever the machine is for of course :)

  Scott.

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] mp32wav

[Rodos]

On Tue, 27 Feb 2001, Jeff Waugh wrote:

>   mpg123 -w  .mp3
>   cdrecord dev=0,0,0 speed=8 -pad -audio *.wav

Thanks Jeff, thats exactly what I was looking for. One CD created and
working just fine. No coasters here.

Rodos

-- 
[EMAIL PROTECTED] | C makes it easy to shoot yourself in the foot. C++
Camion Technology | makes it harder, but when you do, it blows away your
+61 2 9873 5105   | whole leg.   [Bjarne Stroustrup]


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Draft - Install Fest Announcement

[Dave Fitch]

On Tue, Feb 27, 2001 at 04:59:03PM +1100, Craige McWhirter wrote:
> On 27 Feb 2001 15:58:07 +1100, Dave Fitch wrote:
> > > - Mirror machines - there's no 'net - *scary*.
> > 
> > you mean no phone line available?
> 
> As you may have gathered from Jeff's reply, "No". As it is during patrol

fair enough, just wanted to make sure it wasn't the
modem/ISP side of things that was lacking.

Dave.

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] mp32wav

[Dave Fitch]

On Tue, Feb 27, 2001 at 10:09:40PM +1100, Jeff Waugh wrote:
> 
> > How do I convert them into wav files to then get cdrecord to create me an
> > audio cd?
> 
> For conversion:
>   mpg123 -w  .mp3

I think sox does it too.

Dave.

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Crossfire]

Howard Lowndes was once rumoured to have said:
> On Tue, 27 Feb 2001, chesty wrote:
> 
>> We had our linux firewalls audited and I wanted to get some opinions on some
>> of the issues raised.
>>
>> We were advised to turn sshd PasswordAuthentication off because it allows
>> clear text passwords.
>> hey? That doesn't sound right.
> 
> Sounds like good cause to not pay the auditors as they seem not to know
> what they talk about.

I concurr with Howard - but their suggestion is legitimate - but for a
different reason.  PasswordAuthentication means you're relying upon
users to pick sensible passwords.  Its actually best to make sure
nobody but your administrators have access to your firewall systems

>> Mount partitions read only where possible.
>> I guess this is a good idea, but in what situation would this add
>> security?  You need to be root to be able to write to the
>> partitions that I could mount read only, and if someone gets root,
>> they can remount partitions read write.

It adds no real security IMO.  It just makes things a little more
awkward, both for admins and for people breaking in - but it doesn't
grant you any great gains.

>> Remove man pages.
>> Again, I can't see the harm in doing this, but I can't see the point.

Security through obscurity.  Bleh.  Get lost.  Obscurity doesn't gain
any security.

>> Remove unnecessary binaries.
>> A good idea no doubt, but the firewall doesn't allow shell access,
>> and the way I see it is if someone gets shell access they can
>> upload their own bin's.
>
> You could say the same about some libraries after you have done an
> assessment of those required by the remaining binaries, but then the
> auditors wouldn't even know what these are, judging by their earlier
> remarks.

Removing binaries just means the attackers have to get them in via
some other means.

>> It doesn't mention it in the report, but would mounting /home, /tmp
>> and /var with noexec help? It might stop a non root user from
>> running their own programs, but it won't stop root.
> 
> What about cgi-bins in /home/httpd (old RH) or /var/www (FSSTD, I think)?
> OK, so it's your firewall and you would not run cgi-bins on that, would
> you?

Yet again, this is the same argument as the readonly mount.  Not worth
the hassle.

>> Capabilities wasn't mentioned in the report, and I haven't removed
>> any (yet).  Time to do some reading on removing linux kernel
>> capabilities I think.

This is always a great one.  for a start, axe a.out support.  You
don't need it, and you immediate stop all root-kits predating the elf
changeover from working.  Surprisingly, there was an attack against a
place I eneded up working at 2 and a half years ago using an a.out
rootkit.  They still might be about.  You won't need a.out support
anyway.

Better yet... Shut down *ALL* listening services.  Log to a remote
system behind your firewall, make sure you can only log into the
console, etc.  The best way to protect a system is with the minimum
footprint approach.  You can't compromise a service that just isn't
running.

>> What do people use for analysing firewall log files?
>> Theres 84 projects under that category on freshmeat.

grep and less.

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] porting serially

[Crossfire]

[EMAIL PROTECTED] was once rumoured to have said:
> Hi,
> If you need to get a small file from one RH6.2 machine to
> another, and can't use networking, floppy, Zip etc
> but have a null modem, how do you pipe data into/out of ttyS1?
> I tried it with cat; the results were recognisable but damaged
> owing to lack of stop/start control.

Use either PPP to build a IP layer between the two machines, or use
sz/rz to send the files. 

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] porting serially

[chesty]

On Tue, Feb 27, 2001 at 10:10:55PM +1100, [EMAIL PROTECTED] wrote:
> Hi,
> If you need to get a small file from one RH6.2 machine to
> another, and can't use networking, floppy, Zip etc
> but have a null modem, how do you pipe data into/out of ttyS1?
> I tried it with cat; the results were recognisable but damaged
> owing to lack of stop/start control.
> Cheers,
> Jim Donovan

One way out of many, if its ascii, or if you want to uuencode it if its not.

ascii-xfr -s -l 200 -c 50 file > /dev/ttyS1

ascii-xfr comes with the minicom package on my system.

And I haven't tested to see if it works.

-- 
chesty


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Terry Collins]

chesty wrote:
> 
> We had our linux firewalls audited and I wanted to get some opinions on some
> of the issues raised.
> 
> We were advised to turn sshd PasswordAuthentication off because it allows
> clear text passwords.
> hey? That doesn't sound right.

pass

> 
> Mount partitions read only where possible.
> I guess this is a good idea, but in what situation would this add security?
> You need to be root to be able to write to the partitions that I could mount read
> only, and if someone gets root, they can remount partitions read write.

For a firewall, you want to prevent anyone being able to fiddle with it
and one way is to prevent people writing to it is to make it read only.
Tricks like Remote logging, temporary files in ram, boot off CD, etc
have all been covered in Slug archives.
> 
> Remove man pages.
> Again, I can't see the harm in doing this, but I can't see the point.

If you don't know what to do, why are you fiddling with box. Basically,
if someone gets in, man pages help them know the particular variety of
your box. Just makes it harder for script kiddies, dorfs, staff wanting
to create ICQ holes, etc to fiddle.
> 
> Remove unnecessary binaries.
> A good idea no doubt, but the firewall doesn't allow shell access, and the
> way I see it is if someone gets shell access they can upload their own bin's.

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.
> 
> It doesn't mention it in the report, but would mounting /home, /tmp and /var with
> noexec help? It might stop a non root user from running their own programs, but it
> won't stop root.

Are we talking about a firewall or what.
There shouldn't be any users on the firewall.
You want a firewall that has the absolute minimum on it. Just enough to
run the firewall stuff.

--
   Terry Collins {:-)}}} Ph(02) 4627 2186 Fax(02) 4628 7861  
   email: [EMAIL PROTECTED]  www: http://www.woa.com.au  
   WOA Computer Services 

 "People without trees are like fish without clean water"

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] porting serially

[Terry Collins]

[EMAIL PROTECTED] wrote:
> 
> Hi,
> If you need to get a small file from one RH6.2 machine to
> another, and can't use networking, floppy, Zip etc
> but have a null modem, how do you pipe data into/out of ttyS1?
> I tried it with cat; the results were recognisable but damaged
> owing to lack of stop/start control.

Use hardware control on your ports.

--
   Terry Collins {:-)}}} Ph(02) 4627 2186 Fax(02) 4628 7861  
   email: [EMAIL PROTECTED]  www: http://www.woa.com.au  
   WOA Computer Services 

 "People without trees are like fish without clean water"

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Hmmm ... I asked the wrong Question ...

[Steve Kowalik]

On Tue, Feb 27, 2001 at 02:04:13PM +1100, Jason Rennie uttered:
> Hi again,
> 
> Have i missed anything ?
>
Yes!
man xbill

:-)

> Jason
> 
> 
> -- 
> SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
> More Info: http://slug.org.au/lists/listinfo/slug
> 

-- 
Steve
  "I'm a sysadmin because I couldn't beat a blind monkey in a coding contest."
--Me

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] porting serially

[Jeff Waugh]

> If you need to get a small file from one RH6.2 machine to
> another, and can't use networking, floppy, Zip etc
> but have a null modem, how do you pipe data into/out of ttyS1?

You can set up a SLIP connection between the two, or use minicom to do a
zmodem/kermit/whatever transfer.

- Jeff


-- [EMAIL PROTECTED] --- http://linux.conf.au/ --

 "Everyone says they like Free Software - not everyone is ready to  
make the tough choices to make it happen." - Maciej Stachowiak, GNOME Hacker

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] Firewall security audit report

[Howard Lowndes]

-- 
Howard.

LANNet Computing Associates 
"...well, it worked before _you_ touched it!"   --me
"I trust just one person,
 and there are times when I don't even trust myself"
--me

On Tue, 27 Feb 2001, chesty wrote:

>
> We had our linux firewalls audited and I wanted to get some opinions on some
> of the issues raised.
>
> We were advised to turn sshd PasswordAuthentication off because it allows
> clear text passwords.
> hey? That doesn't sound right.

Sounds like good cause to not pay the auditors as they seem not to know
what they talk about.

>
> Mount partitions read only where possible.
> I guess this is a good idea, but in what situation would this add security?
> You need to be root to be able to write to the partitions that I could mount read
> only, and if someone gets root, they can remount partitions read write.
>
> Remove man pages.
> Again, I can't see the harm in doing this, but I can't see the point.
>
> Remove unnecessary binaries.
> A good idea no doubt, but the firewall doesn't allow shell access, and the
> way I see it is if someone gets shell access they can upload their own bin's.

You could say the same about some libraries after you have done an
assessment of those required by the remaining binaries, but then the
auditors wouldn't even know what these are, judging by their earlier
remarks.

>
> It doesn't mention it in the report, but would mounting /home, /tmp and /var with
> noexec help? It might stop a non root user from running their own programs, but it
> won't stop root.

What about cgi-bins in /home/httpd (old RH) or /var/www (FSSTD, I think)?
OK, so it's your firewall and you would not run cgi-bins on that, would
you?

>
> Capabilities wasn't mentioned in the report, and I haven't removed any (yet).
> Time to do some reading on removing linux kernel capabilities I think.
>
> What do people use for analysing firewall log files?
> Theres 84 projects under that category on freshmeat.
>
>


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [SLUG] mp32wav

[Jeff Waugh]

> How do I convert them into wav files to then get cdrecord to create me an
> audio cd?

For conversion:

  mpg123 -w  .mp3

  (Do this with a for loop for a whole stack of files.)

For burnage:

  cdrecord dev=0,0,0 speed=8 -pad -audio *.wav

- Jeff


-- [EMAIL PROTECTED] --- http://linux.conf.au/ --

 "Free software never simply picks up its marbles and goes home." - 
Jonathan Corbet, LWN

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] porting serially

[jimd]

Hi,
If you need to get a small file from one RH6.2 machine to
another, and can't use networking, floppy, Zip etc
but have a null modem, how do you pipe data into/out of ttyS1?
I tried it with cat; the results were recognisable but damaged
owing to lack of stop/start control.
Cheers,
Jim Donovan

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] mp32wav

[Rodos]

I have some parody songs I downloaded of the net as .mp3 files.

How do I convert them into wav files to then get cdrecord to create me an
audio cd?

I saw some references to mp32wav but could not find any real code or
examples.

I am sure there is a simple way to do this, just as there is for ripping a
CD to mp3s.

Thanks for the help.

Rodos

-- 
[EMAIL PROTECTED] | A complex system that works is invariably found to
Camion Technology | have evolved from a simple system that worked. [John
+61 2 9873 5105   | Gall]


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

[SLUG] Firewall security audit report

[chesty]

We had our linux firewalls audited and I wanted to get some opinions on some
of the issues raised.

We were advised to turn sshd PasswordAuthentication off because it allows
clear text passwords. 
hey? That doesn't sound right.

Mount partitions read only where possible. 
I guess this is a good idea, but in what situation would this add security?
You need to be root to be able to write to the partitions that I could mount read 
only, and if someone gets root, they can remount partitions read write.

Remove man pages. 
Again, I can't see the harm in doing this, but I can't see the point. 

Remove unnecessary binaries.
A good idea no doubt, but the firewall doesn't allow shell access, and the 
way I see it is if someone gets shell access they can upload their own bin's. 

It doesn't mention it in the report, but would mounting /home, /tmp and /var with 
noexec help? It might stop a non root user from running their own programs, but it 
won't stop root.

Capabilities wasn't mentioned in the report, and I haven't removed any (yet).
Time to do some reading on removing linux kernel capabilities I think.

What do people use for analysing firewall log files?
Theres 84 projects under that category on freshmeat.

-- 
chesty


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug