UEA, Norwich on the 1st September?
Hi all, I fancy a meeting on the 1st September. Not least so I can get my rustlefustlegrastlefstin GPG key signed. Noodles, slef, adam, ricardo, anyone else: mail boo@ikitten.co.uk if you're interested, and I'll book a room. Probably be Nelson Common Room B again. Adam - I have a CD burner (if slightly erratic), so maybe if you picked me up in your lovely car we could LAN our machines and distribute Debian to the masses? If you'd rather not, no problem. Alexis -- "Ruby is the language Buddha would have programmed in" - Sean Russell "I respect faith, but doubt is what gives you an education" - Wilson Mizner "You got what everyone gets. A lifetime." - Death (Sandman by Neil Gaiman)
Alexis Lee wrote:
Hi all,
I fancy a meeting on the 1st September. Not least so I can get my rustlefustlegrastlefstin GPG key signed.
Woo! i will be in Norfolk that weekend (90% likely) and will almost be 100% sure if there will be a meeting that weekend. Also means i should sort out my gpg key, somebody can explain the keysigning thing to me in a way that doesn't make my brain hurt thinking about it....
Adam - I have a CD burner (if slightly erratic), so maybe if you picked me up in your lovely car we could LAN our machines and distribute Debian to the masses? If you'd rather not, no problem.
Ummm, yeah will discuss off list, hopefully my dead box will be working again by then though so i could bring CDs for all.... Adam
I haven't done anything about booking the training room here at Stalham for this month as I've assumed that we'll be meeting at UEA on the 1st Sept. How about October or November? Shall I book a Sunday for one of these months? if so are any particular dates good/bad? Keith ____________ ABSURDITY, n. A statement or belief manifestly inconsistent with one's own opinion. Ambrose Bierce - The Devil's Dictionary
Keith Watson <keith.watson@kewill.com> wrote:
How about October or November? Shall I book a Sunday for one of these months? if so are any particular dates good/bad?
Yes. Go for it. Everyone arrange meetings. Pick your favourite dates. Tell people where and when to turn up. Normally a non-empty subset of ALUG will appear at the appointed time and place. Sometimes they'll have kit and sometimes there will be something really interesting happen with it (beyond failing to get networking right first time, thanks to dud cables etc). Maybe other times they'll just eat and drink. Just name the times, places and what you want to do there. Others will do the physical appearance and gratitude for organising a meeting bits. John, how about that bbq? MJR
Hi, You know those annoying Nimda scans you keep finding in your apache logs???? Anybody know if it's possable to create a custom error document for apache which, when the first address in a normal nimda scan is requested, the originators IP is automatically added to the IPTables DROP table, so subsquent requests from that IP time out. I was thinking about writing a custom page that is returned for that address, containing some perl code to modify the firewall. Any one got any ideas? I'm running Apache 2.0.39 with mod_perl 1.99 kernel 2.4.18 Chris -- Chris *************************************************************************** E Mail Chris@glovercc.clara.co.uk WWW http://www.glovercc.clara.co.uk Someday, we'll look back on this, laugh nervously and change the subject. -Anon
Chris Glover <chris@glovercc.clara.co.uk> wrote:
I was thinking about writing a custom page that is returned for that address, containing some perl code to modify the firewall.
Any one got any ideas?
That sort of thing certainly used to be possible, by using something like <Location ~ /some/regexp/to/trap> ErrorDocument 403 http://server/path/to/cgi allow from none deny from all </Location> Not that I ever trapped things in that way. Oh no. Be careful writing your regexp, or it can be very costly. Testing from the box you're ssh'd in from is another no-no. ;-) -- MJR| Apache is versatile, but you need to be careful when configuring ---' it or it may shut down on you. Always run "apachectl configtest" or equivalent over the httpd.conf before trying to load it in. |-----[ Luminas internet applications http://www.luminas.co.uk/ ]-----|
On 17-Aug-2002 Chris Glover wrote:
Hi,
You know those annoying Nimda scans you keep finding in your apache logs????
Anybody know if it's possable to create a custom error document for apache which, when the first address in a normal nimda scan is requested, the originators IP is automatically added to the IPTables DROP table, so subsquent requests from that IP time out.
As has been mentioned, ErrorDocument does part of what you want. The problem is that in order to run ipchains/iptables you have to be root - Apache does not run as root. You therefore need a suid script to do the job, and suid scripts always make me a bit twitchy. In my own setup I compromise by sending myself a mail so that I can the update the tables by hand. I also add the IP to a 'hackers' file that is fed to ipchains on every reboot. The only time I got, slightly, bitten was when a subscriber to a mailing list I run was infected wiht CodeRed. His IP was blocked and it took me quite a while to work out why he could not send any postings . -- Nothing propinx like propinquity. Mark Twain Raphael Mankin E-Mail: raph@panache.demon.co.uk ----------------------------------
Raphael Mankin wrote:
As has been mentioned, ErrorDocument does part of what you want. The problem is that in order to run ipchains/iptables you have to be root - Apache does not run as root. You therefore need a suid script to do the job, and suid scripts always make me a bit twitchy.
How about sudo? Is that more secure? If someone does manage to hack in to be the apache user, all they'll be able to do is add addresses to the firewall block list. I'd expect that at some point they'd make a mistake and block out their own IP ;-) Neil (writing this on ps2linux acting as X display for mozilla running on linux server. Cool :-)
On 18-Aug-02 Neil Sedger wrote:
Raphael Mankin wrote:
As has been mentioned, ErrorDocument does part of what you want. The problem is that in order to run ipchains/iptables you have to be root - Apache does not run as root. You therefore need a suid script to do the job, and suid scripts always make me a bit twitchy.
How about sudo? Is that more secure?
SUDO is oonly for CGIs. (AFAIK)
If someone does manage to hack in to be the apache user, all they'll be able to do is add addresses to the firewall block list. I'd expect that at some point they'd make a mistake and block out their own IP ;-)
Suid scripts and hackers are not a combination that appeals under any conditions.
---------------------------------- E-Mail: Raphael Mankin <raph@panache.demon.co.uk> Date: 22-Aug-02 Time: 13:31:01 ----------------------------------
Raphael Mankin <raph@panache.demon.co.uk> wrote:
SUDO is oonly for CGIs. (AFAIK)
It's a regular command: sudo - execute a command as another user I think Apache can use suexec for CGIs. Using it for this would still not be very safe, though. MJR
Yea verily, I am an idiot. I was confusing sudo and suexec. Sudo is purely for interactive use: it requires you to type a password. Suexec is for CGIs; it *might* work for ErrorDocument. However as I said before, suid scripts and the prospect of hackers are not a combination that apppeals to me under any circumstances. If you are determined to do this sort of thing fully automatically write the naughty IPs to a file that is owned by the Apache process, and have a daemon that periodically inspects the file and adds its contents to the iptables/ipchains blocking list. On 22-Aug-02 Raphael Mankin wrote:
On 18-Aug-02 Neil Sedger wrote:
Raphael Mankin wrote:
As has been mentioned, ErrorDocument does part of what you want. The problem is that in order to run ipchains/iptables you have to be root - Apache does not run as root. You therefore need a suid script to do the job, and suid scripts always make me a bit twitchy.
How about sudo? Is that more secure?
SUDO is oonly for CGIs. (AFAIK)
If someone does manage to hack in to be the apache user, all they'll be able to do is add addresses to the firewall block list. I'd expect that at some point they'd make a mistake and block out their own IP ;-)
Suid scripts and hackers are not a combination that appeals under any conditions.
---------------------------------- E-Mail: Raphael Mankin <raph@panache.demon.co.uk> Date: 26-Aug-02 Time: 18:49:10 ----------------------------------
On Mon, Aug 26, 2002 at 06:54:30PM +0100, Raphael Mankin wrote:
Sudo is purely for interactive use: it requires you to type a password. Suexec
Not necessarily. Usually the very first thing I do after I install a new system is add 'lxs : NOPASSWD all' with visudo (I believe that's rite, but it might not kwite be). Sudo is a very flexible program which allows you to add the privileges of any user for any command to any set of users. I would suggest: 1: Set up sudo so 'nobody' can run 'myscript' 2: Validate the IP address. Do not let anything which doesn't match completely through. Watch out for special IP addresses like 127.0.0.1 and 255.255.0.0 (&c). Beware of buffer overflows. 3: Run 'myscript', passing the IP as a parameter. 'myscript' runs iptables to ban the IP and adds an appropriate line to the firewall script. If you follow RM's instructions, beware of 'disk full' DoS attacks and similar. Isn't the random quote appropriate? Alexis -- "In the last 15 years alone, software defects have wrecked a satellite launch, delayed an airport opening for a year, destroyed a Mars mission, killed four Marines in a helicopter crash, induced a U.S. Navy ship to destroy a civilian airliner, and shut down ambulance systems in London, leading to as many as 30 deaths." - http://msnbc.com/news/768401.asp?cp1=1
On 26-Aug-02 Alexis Lee wrote:
On Mon, Aug 26, 2002 at 06:54:30PM +0100, Raphael Mankin wrote:
Sudo is purely for interactive use: it requires you to type a password. Suexec
Not necessarily. Usually the very first thing I do after I install a new system is add 'lxs : NOPASSWD all' with visudo (I believe that's rite, but it might not kwite be).
True it can be done, but you are just opening up your system to hackers. Not a good idea. ;-(
Sudo is a very flexible program which allows you to add the privileges of any user for any command to any set of users.
I would suggest: 1: Set up sudo so 'nobody' can run 'myscript'
Aaargh! This destroys much of the point of user 'nobody'. 'Nobody' should have no privileges whatsoever. The point of this exercise is to improve security, not to weaken it. [snip]
If you follow RM's instructions, beware of 'disk full' DoS attacks and similar.
How? 'sort -u' or 'grep -v' to detect duplicates will prevent the IP list growing too big. Bear in mind, though, that no security measure can be fully automatic. You always have to have a human eye keeping an occasional watch on it. I currently have a list of about 400 IPs that I block from my servers, but then after
30years in the business I do suffer from terminal paranoia.
---------------------------------- E-Mail: Raphael Mankin <raph@panache.demon.co.uk> Date: 27-Aug-02 Time: 18:50:13 ----------------------------------
Raphael Mankin <raph@panache.demon.co.uk> wrote:
have a list of about 400 IPs that I block from my servers, but then after
30years in the business I do suffer from terminal paranoia.
How do you know that all the IPs belong to terminals? ;-) MJR, running for the hills.
On Tue, Aug 27, 2002 at 06:58:57PM +0100, Raphael Mankin wrote:
True it can be done, but you are just opening up your system to hackers. Not a good idea. ;-(
Mine is a ppp-networked, totally-firewalled system that sits in my bedroom. Open is not the word.
Aaargh! This destroys much of the point of user 'nobody'. 'Nobody' should have no privileges whatsoever.
No, it should have no blanket privileges. Allowing it to run a specified set of programs carries no hidden security risk at all.
The point of this exercise is to improve security, not to weaken it.
This comment is rather senseless until you show that I'm weakening security. Even then, it serves no useful purpose in a discussion.
How? 'sort -u' or 'grep -v' to detect duplicates will prevent the IP list growing too big.
You neglected to suggest the IPs be validated. If you allow random text to be written to your disk, you're gagging for a DoS. Alexis -- I am available for work! http://www.tenfingers.co.uk "The human brain is a wonderful thing. It starts working the moment you are born, and never stops until you stand up to speak in public" - Sir G Jessel
Alexis Lee wrote:
On Tue, Aug 27, 2002 at 06:58:57PM +0100, Raphael Mankin wrote:
How? 'sort -u' or 'grep -v' to detect duplicates will prevent the IP list growing too big.
You neglected to suggest the IPs be validated. If you allow random text to be written to your disk, you're gagging for a DoS.
I would also put in some kind of aging mechanism to remove them from the blocked list if not you could have some fun in the future... Personally I wouldn't specifically block any hosts, ever. You never know when you are going to give yourself false positives or somebody is going to stick a load of spoofed IP addresses into your firewall causing you much misery and grief. If you are well protected in the first place then you should never have a problem, I don't see how you are improving security at all by doing this, basically you should trust nothing in the first place and make sure you are keeping your firewall tight in its default state and making sure you have all patches updates etc. You will always find that the people scanning you will have many hosts at their disposal and it will always be that one attack that succeeds that is not in your explicitaly banned list. Adam
On 28-Aug-02 Alexis Lee wrote:
On Tue, Aug 27, 2002 at 06:58:57PM +0100, Raphael Mankin wrote: [snip]
How? 'sort -u' or 'grep -v' to detect duplicates will prevent the IP list growing too big.
You neglected to suggest the IPs be validated. If you allow random text to be written to your disk, you're gagging for a DoS.
This data is not random, or even arbitrary. We know that it is a validated IP as determined by apache and passed to the ErrorDocument handler. IN general though, your point is valid. ---------------------------------- E-Mail: Raphael Mankin <raph@panache.demon.co.uk> Date: 28-Aug-02 Time: 18:32:54 ----------------------------------
on Wed, Aug 28, 2002 at 11:42:46AM +0100, Alexis Lee wrote:
Mine is a ppp-networked, totally-firewalled system that sits in my bedroom. Open is not the word.
client-side vulnerabilities. see recent problems in libpng. firewalls are not perfect. some data has to be permitted after all.
Aaargh! This destroys much of the point of user 'nobody'. 'Nobody' should have no privileges whatsoever.
No, it should have no blanket privileges. Allowing it to run a specified set of programs carries no hidden security risk at all.
programs have to be designed to run at privilege levels above that of the user invoking them, whether it is by a set-id bit or sudo. it is hard to do since the environment is often trusted far too much. there have been overflows in grep. but who cares? well, with sudo just permitting grep to be used, directly or via a script, this overflow becomes a root vulnerability.
Raphael Mankin wrote:
Sudo is purely for interactive use: it requires you to type a password. Suexec is for CGIs; it *might* work for ErrorDocument. However as I said before, suid scripts and the prospect of hackers are not a combination that apppeals to me under any circumstances.
If you are determined to do this sort of thing fully automatically write the naughty IPs to a file that is owned by the Apache process, and have a daemon that periodically inspects the file and adds its contents to the iptables/ipchains blocking list.
...a hacker who managed to become the 'apache' user would have the same power in both cases... except that in the latter it might take a little while before they took any effect... the downside of course being that it would take longer for a 'real worm' to be blocked. Whats the problem here with sudo? ...an entry would be added to /etc/sudoers that specifies the apache user and one script it can run... /etc/sudoers and the script would both be unchangeable by the apache user, so I don't see how adding this 'sudoer' entry would make things any worse (assuming that said hacker has gotten in as the apache user by some other means). Neil
On Saturday 17 Aug 2002 12:19 am, MJ Ray wrote:
John, how about that bbq?
Trying to find a slot. When I do I'll get back to you. Family stuff keeps getting in the way at the moment, sorry. -- Cheers, BJ
participants (10)
-
Adam Bower -
Alexis Lee -
Chris Glover -
John Woodard -
Keith Watson -
MJ Ray -
Neil Sedger -
Neil Sedger -
Raphael Mankin -
xs＠kittenz.org