Re: Firewall and IPv6
On Mon, Jan 29, 2001 at 10:10:34PM +0100, NDSoftware wrote: > I have ipchains under Debian 2.2. > This firewall is compatible IPv6 ? no, you must use netfilter bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6 PGP signature
Re: Ext2 - ?????????? ??????????
Of all the days, it was on Mon, Jan 29, 2001 at 08:35:57PM + that Tom Breza quoth: > Can u write in English pls? or don't write at all Oh, the irony. > > thanks > > > e2fsck ÿþüþóðõàÃÂþûÃÂúþ ýð ýõÃÂúþûÃÂúþ üøýÃÂÃÂ. > > ÃÂþýõÃÂýþ àÃÂðúøüø ÃÂúÃÂôýÃÂüø ôðýýÃÂüø ÃÂÃÂÃÂôýþ > > ÿþûÃÂÃÂøÃÂàþÃÂòõà... ýþ òÃÂõÃÂðúø > > ýðôõÃÂÃÂààúþóþ ÃÂþ ñÃÂûþ ýõÃÂÃÂþ ÿþôþñýþõ. > > Although something in a Roman alphabet would at least have a chance with the fish.
Firewall and IPv6
Hi, I have ipchains under Debian 2.2. This firewall is compatible IPv6 ? Thanks Nicolas DEFFAYET, NDSoftware http://www.ndsoftware.net - [EMAIL PROTECTED] France: Tel +33 671887502 - Fax N/A UK: Tel +44 8453348750 - Fax +44 8453348751 USA: Tel N/A - Fax N/A
Re: Ext2 - поÑÑоÑнное ÑазÑÑÑение
Can u write in English pls? or don't write at all thanks > e2fsck ?? ??. > ?? ?? ?? > ?? ... ?? > ?? ?? ?? . >
Re: portsentry dangerous? hardly
On Mon, 29 Jan 2001, Peter Cordes wrote: > On Mon, Jan 29, 2001 at 07:06:56PM +, thomas lakofski wrote: > > My bad. But the point seems moot, since if you're already able to squash > > traffic between the hosts you might as well do that instead of trying to > > induce > > a blocking response from portsentry. It's decidedly less trivial than > > sending > > a spoofed SYN. > > True, it is easier just to DoS, but if you get portsentry to do something, > then you can stop your DoS attack, and things stay broken. That would make > the attack a lot harder to trace. > > That's why I don't think anyone should ever run software that sets up > blocks in response to possible attacks it has detected, unless the software > is sophisticated enough to make sure it doesn't block anything it shouldn't, > at least not permanently. (I remember reading about some US Gov guys doing > security research who had a whole bunch of programs all over their network > that collected info and responded automatically, and another team trying to > break in. In that case, I guess blocking in response to attacks works, but > that's a lot smarter than e.g. blocking everyone who fingers you. What > about people who honestly forgot your email address?) I think there should be a difference between real crackers and script kids. Portsentry is just wonderfull for blocking people running subnet scans for certain ports that you're machine isn't providing any services for (services like rpc and lpd are mostly not usefull for other people on a webserver). In those cases portsentry will block those hosts completely without the risk of trying exploits on service ports that do have a specific function (imap, smtp etc). Real crackers are more host specific. They don't do subnetscans. Ciao, Eelco van Beek
Re: portsentry dangerous? hardly
On Mon, Jan 29, 2001 at 07:06:56PM +, thomas lakofski wrote: > My bad. But the point seems moot, since if you're already able to squash > traffic between the hosts you might as well do that instead of trying to > induce > a blocking response from portsentry. It's decidedly less trivial than sending > a spoofed SYN. True, it is easier just to DoS, but if you get portsentry to do something, then you can stop your DoS attack, and things stay broken. That would make the attack a lot harder to trace. That's why I don't think anyone should ever run software that sets up blocks in response to possible attacks it has detected, unless the software is sophisticated enough to make sure it doesn't block anything it shouldn't, at least not permanently. (I remember reading about some US Gov guys doing security research who had a whole bunch of programs all over their network that collected info and responded automatically, and another team trying to break in. In that case, I guess blocking in response to attacks works, but that's a lot smarter than e.g. blocking everyone who fingers you. What about people who honestly forgot your email address?) The best practice is to notify a human of the situation, so they can do something intelligent :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: Clear screan question
[ Sune Kirkeby ] > I don't know how or why, but it does _not_ clear the scroll-back > buffer on my console, "chvt 63 ; reset -Q ; chvt 1" does though. [ Ethan Benson ] > you don't need the reset -Q there. the simple act of changing VCs > clears the scrollback history. [ Sune Kirkeby ] > Sorry, my bad for being unclear. I meant that the above command would > clear both the scroll-back buffer and the "actual" terminal itself. [ Ethan Benson ] > except your reset -Q happens on tty63, which alsmost certainly has > nothing there you care about. Just checked, and it most certainly resets the originating terminal (i.e. the one you run the command-sequence from). Try it with vt1 and vt2 while logged in on vt1. This also is what is to be expected, since the commands are run on the terminal they are attached to, _not_ on the vt currently displayed (think what a mess it would be if all programs run on all vts would meddle around on the current vt.) [ Ethan Benson ] > you want to clear tty1 (or wherever you were logged in). `clear` is a > sufficient way to do that rather then reset (which resets all kinds of > things and is slower then clear) True. -- Sune Kirkeby| Please forgive me if, in the heat of battle, http://mel.interspace.dk/~sune/ | I sometimes forget which side I'm on. pgpWUeqym4nQX.pgp Description: PGP signature
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On 29 Jan 2001, Rainer Weikusat wrote: > thomas lakofski <[EMAIL PROTECTED]> writes: > > Tim Haynes wrote: > > Script kiddies generally don't know what's happened to them when > > portsentry triggers, and go looking for easier fodder > > Random garbage traveling across the 'net is exactly this: Random > garbage. ok, and? [snip] > A nice remote DoS: > > while true; > do > isdnctrl dial ippp0 > nc -v -z > isdnctrl hangup ippp0 > done > > > If I suffer from dynamic IP allocations, you would be blocking > hundreds of IPs within a comparatively short amount of time (~ 3-5 > seconds per IP). This will keep your machine quite busy and will block > entirely legitimate accesses to the services you talk of below from > people who happen get said IPs next. I think the machine can manage to handle executing a command every three seconds. I'd get an idea this was occurring within an hour as logcheck mails me if portsentry goes off. So, maybe a thousand random dialup IPs can't reach my machine. Since a potential attacker doesn't know where I do business, the chances of this affecting me are slim to slimmer than that. > > If they're actually out to exploit the hole > > Why do you worry about holes in programs you don't even run? I'm not worried about holes in programs I don't even run. I'm interested in detecting, and taking action against, actions which appear to be suspicious. > No one can attack you with a portmapper-exploit if there's no portmapper > to talk to. I realise this. > > When using software like this it's assumed that you have a good idea > > of what is happening on the box. > > If I know what's happening on the box, I don't need a tool like this, > as I don't run any services except those I intend to, with the latter > ones being reasonably configured. I still want to detect behaviour indicative of an attack and take action. > > I don't have it trigger as a result of anything other than a full > > TCP connect. > > see above > > > I have a default-deny firewall with portsentry. > > Consider a default-REJECT firewall. This is a lot nicer to others. Until someone uses it as a mirror for a denial of service attack. Legitimate traffic will never have any problems. > > There are only around 5 valid services on the box, > > So these are to ones to worry about. > > > and about 30 fake ports wired up to portsentry. > > So you deliberately open up thirty ports without any real need to do > so to get *what*? To detect certain kinds of behaviours and take appropriate actions, that's all. > Why not simply close them and be done with it? see above > > People who have valid business on the box never run into trouble, > > They will, as demonstrated above. Unlikely; at least, it hasn't happened in the last 3 or so years. cheers, -thomas -- who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43
Re: Ext2 - ?????????? ??????????
Of all the days, it was on Mon, Jan 29, 2001 at 08:35:57PM + that Tom Breza quoth: > Can u write in English pls? or don't write at all Oh, the irony. > > thanks > > > e2fsck Ð¿Ð¾Ð¼Ð¾Ð³Ð°ÐµÑ ÑолÑко на неÑколÑко минÑÑ. > > ÐонеÑно Ñ Ñакими ÑкÑднÑми даннÑми ÑÑÑдно >полÑÑиÑÑ Ð¾ÑÐ²ÐµÑ ... но вÑеÑаки > > надеÑÑÑ Ñ ÐºÐ¾Ð³Ð¾ Ñо бÑло неÑÑо подобное. > > Although something in a Roman alphabet would at least have a chance with the fish. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Firewall and IPv6
Hi, I have ipchains under Debian 2.2. This firewall is compatible IPv6 ? Thanks Nicolas DEFFAYET, NDSoftware http://www.ndsoftware.net - [EMAIL PROTECTED] France: Tel +33 671887502 - Fax N/A UK: Tel +44 8453348750 - Fax +44 8453348751 USA: Tel N/A - Fax N/A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Mon, 29 Jan 2001, Peter Cordes wrote: > > bah. all this talk about portsentry being dangerous forgets that you can > > also > > run it so it only triggers after a full TCP connect. while not > > un-spoofable, > > it's very hard for an attacker to spoof as they have to be in-line between > > your > > host and the host they're trying to spoof. plus, they'll have a task > > guessing > > sequence numbers. > > Not true. To spoof a TCP connection, you need to guess the initial > sequence number, and you need to stop RST packets from the spoofed host from > reaching the host under attack, or else the host under attack will reset the > TCP connection. If you are in-line with the host under attack, you can see > the return traffic, and then you don't need to guess at the sequence number > even. You will be able to block the return traffic from ever reaching the > spoofed host. However, another way to accomplish the blocking is to DoS the > spoofed host. My bad. But the point seems moot, since if you're already able to squash traffic between the hosts you might as well do that instead of trying to induce a blocking response from portsentry. It's decidedly less trivial than sending a spoofed SYN. cheers, -thomas > > I don't remember where I read this, either in an RFC, or in the book > "Practical Unix and Internet Security". > > -- who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
thomas lakofski <[EMAIL PROTECTED]> writes: > Tim Haynes wrote: > Script kiddies generally don't know what's happened to them when > portsentry triggers, and go looking for easier fodder Random garbage traveling across the 'net is exactly this: Random garbage. > > Who says someone's going to go through a full SYN connect, anyway? Sounds > > like > > you need a stateful firewall to be somewhat safer. > > If they're not doing a full connect, portsentry won't trip. aka 'Won't notice anything except TCP-connect scans'. So somebody tries to connect to what he thinks is a service you offer and then you block his IP (which could have been allocated dynamically out of an ISP's pool and change within seconds without any necessity for a different machine at the other end)? A nice remote DoS: while true; do isdnctrl dial ippp0 nc -v -z isdnctrl hangup ippp0 done If I suffer from dynamic IP allocations, you would be blocking hundreds of IPs within a comparatively short amount of time (~ 3-5 seconds per IP). This will keep your machine quite busy and will block entirely legitimate accesses to the services you talk of below from people who happen get said IPs next. > If they're actually out to exploit the hole Why do you worry about holes in programs you don't even run? No one can attack you with a portmapper-exploit if there's no portmapper to talk to. > When using software like this it's assumed that you have a good idea > of what is happening on the box. If I know what's happening on the box, I don't need a tool like this, as I don't run any services except those I intend to, with the latter ones being reasonably configured. > I don't have it trigger as a result of anything other than a full > TCP connect. see above > I have a default-deny firewall with portsentry. Consider a default-REJECT firewall. This is a lot nicer to others. > There are only around 5 valid services on the box, So these are to ones to worry about. > and about 30 fake ports wired up to portsentry. So you deliberately open up thirty ports without any real need to do so to get *what*? Why not simply close them and be done with it? > People who have valid business on the box never run into trouble, They will, as demonstrated above. -- SIGSTOP
Re: Ext2 - постоянное разрушение
Can u write in English pls? or don't write at all thanks > e2fsck помогает только на несколько минут. > Конешно с такими скудными данными трудно >получить ответ ... но всетаки > надеюсь у кого то было нечто подобное. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly
On Mon, 29 Jan 2001, Peter Cordes wrote: > On Mon, Jan 29, 2001 at 07:06:56PM +, thomas lakofski wrote: > > My bad. But the point seems moot, since if you're already able to squash > > traffic between the hosts you might as well do that instead of trying to induce > > a blocking response from portsentry. It's decidedly less trivial than sending > > a spoofed SYN. > > True, it is easier just to DoS, but if you get portsentry to do something, > then you can stop your DoS attack, and things stay broken. That would make > the attack a lot harder to trace. > > That's why I don't think anyone should ever run software that sets up > blocks in response to possible attacks it has detected, unless the software > is sophisticated enough to make sure it doesn't block anything it shouldn't, > at least not permanently. (I remember reading about some US Gov guys doing > security research who had a whole bunch of programs all over their network > that collected info and responded automatically, and another team trying to > break in. In that case, I guess blocking in response to attacks works, but > that's a lot smarter than e.g. blocking everyone who fingers you. What > about people who honestly forgot your email address?) I think there should be a difference between real crackers and script kids. Portsentry is just wonderfull for blocking people running subnet scans for certain ports that you're machine isn't providing any services for (services like rpc and lpd are mostly not usefull for other people on a webserver). In those cases portsentry will block those hosts completely without the risk of trying exploits on service ports that do have a specific function (imap, smtp etc). Real crackers are more host specific. They don't do subnetscans. Ciao, Eelco van Beek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Mon, Jan 29, 2001 at 12:33:03PM +, thomas lakofski wrote: > On Wed, 24 Jan 2001, Mark Suter wrote: > > > The only way under IPv4 be safe from spoofing is for everyone to > > implement proper Network Ingress Filtering [RFC2827, BCP0038] on > > their networks. Please, read this RFC. > > > > http://www.faqs.org/rfc/rfc2827.txt > > bah. all this talk about portsentry being dangerous forgets that you can also > run it so it only triggers after a full TCP connect. while not un-spoofable, > it's very hard for an attacker to spoof as they have to be in-line between > your > host and the host they're trying to spoof. plus, they'll have a task guessing > sequence numbers. Not true. To spoof a TCP connection, you need to guess the initial sequence number, and you need to stop RST packets from the spoofed host from reaching the host under attack, or else the host under attack will reset the TCP connection. If you are in-line with the host under attack, you can see the return traffic, and then you don't need to guess at the sequence number even. You will be able to block the return traffic from ever reaching the spoofed host. However, another way to accomplish the blocking is to DoS the spoofed host. I don't remember where I read this, either in an RFC, or in the book "Practical Unix and Internet Security". -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: portsentry dangerous? hardly
On Mon, Jan 29, 2001 at 07:06:56PM +, thomas lakofski wrote: > My bad. But the point seems moot, since if you're already able to squash > traffic between the hosts you might as well do that instead of trying to induce > a blocking response from portsentry. It's decidedly less trivial than sending > a spoofed SYN. True, it is easier just to DoS, but if you get portsentry to do something, then you can stop your DoS attack, and things stay broken. That would make the attack a lot harder to trace. That's why I don't think anyone should ever run software that sets up blocks in response to possible attacks it has detected, unless the software is sophisticated enough to make sure it doesn't block anything it shouldn't, at least not permanently. (I remember reading about some US Gov guys doing security research who had a whole bunch of programs all over their network that collected info and responded automatically, and another team trying to break in. In that case, I guess blocking in response to attacks works, but that's a lot smarter than e.g. blocking everyone who fingers you. What about people who honestly forgot your email address?) The best practice is to notify a human of the situation, so they can do something intelligent :) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clear screan question
[ Sune Kirkeby ] > I don't know how or why, but it does _not_ clear the scroll-back > buffer on my console, "chvt 63 ; reset -Q ; chvt 1" does though. [ Ethan Benson ] > you don't need the reset -Q there. the simple act of changing VCs > clears the scrollback history. [ Sune Kirkeby ] > Sorry, my bad for being unclear. I meant that the above command would > clear both the scroll-back buffer and the "actual" terminal itself. [ Ethan Benson ] > except your reset -Q happens on tty63, which alsmost certainly has > nothing there you care about. Just checked, and it most certainly resets the originating terminal (i.e. the one you run the command-sequence from). Try it with vt1 and vt2 while logged in on vt1. This also is what is to be expected, since the commands are run on the terminal they are attached to, _not_ on the vt currently displayed (think what a mess it would be if all programs run on all vts would meddle around on the current vt.) [ Ethan Benson ] > you want to clear tty1 (or wherever you were logged in). `clear` is a > sufficient way to do that rather then reset (which resets all kinds of > things and is slower then clear) True. -- Sune Kirkeby| Please forgive me if, in the heat of battle, http://mel.interspace.dk/~sune/ | I sometimes forget which side I'm on. PGP signature
Re: portsentry dangerous? hardly; RTFM. (was Re: checking securitylogs)
On 29 Jan 2001, Rainer Weikusat wrote: > thomas lakofski <[EMAIL PROTECTED]> writes: > > Tim Haynes wrote: > > Script kiddies generally don't know what's happened to them when > > portsentry triggers, and go looking for easier fodder > > Random garbage traveling across the 'net is exactly this: Random > garbage. ok, and? [snip] > A nice remote DoS: > > while true; > do > isdnctrl dial ippp0 > nc -v -z > isdnctrl hangup ippp0 > done > > > If I suffer from dynamic IP allocations, you would be blocking > hundreds of IPs within a comparatively short amount of time (~ 3-5 > seconds per IP). This will keep your machine quite busy and will block > entirely legitimate accesses to the services you talk of below from > people who happen get said IPs next. I think the machine can manage to handle executing a command every three seconds. I'd get an idea this was occurring within an hour as logcheck mails me if portsentry goes off. So, maybe a thousand random dialup IPs can't reach my machine. Since a potential attacker doesn't know where I do business, the chances of this affecting me are slim to slimmer than that. > > If they're actually out to exploit the hole > > Why do you worry about holes in programs you don't even run? I'm not worried about holes in programs I don't even run. I'm interested in detecting, and taking action against, actions which appear to be suspicious. > No one can attack you with a portmapper-exploit if there's no portmapper > to talk to. I realise this. > > When using software like this it's assumed that you have a good idea > > of what is happening on the box. > > If I know what's happening on the box, I don't need a tool like this, > as I don't run any services except those I intend to, with the latter > ones being reasonably configured. I still want to detect behaviour indicative of an attack and take action. > > I don't have it trigger as a result of anything other than a full > > TCP connect. > > see above > > > I have a default-deny firewall with portsentry. > > Consider a default-REJECT firewall. This is a lot nicer to others. Until someone uses it as a mirror for a denial of service attack. Legitimate traffic will never have any problems. > > There are only around 5 valid services on the box, > > So these are to ones to worry about. > > > and about 30 fake ports wired up to portsentry. > > So you deliberately open up thirty ports without any real need to do > so to get *what*? To detect certain kinds of behaviours and take appropriate actions, that's all. > Why not simply close them and be done with it? see above > > People who have valid business on the box never run into trouble, > > They will, as demonstrated above. Unlikely; at least, it hasn't happened in the last 3 or so years. cheers, -thomas -- who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking securitylogs)
On Mon, 29 Jan 2001, Peter Cordes wrote: > > bah. all this talk about portsentry being dangerous forgets that you can also > > run it so it only triggers after a full TCP connect. while not un-spoofable, > > it's very hard for an attacker to spoof as they have to be in-line between your > > host and the host they're trying to spoof. plus, they'll have a task guessing > > sequence numbers. > > Not true. To spoof a TCP connection, you need to guess the initial > sequence number, and you need to stop RST packets from the spoofed host from > reaching the host under attack, or else the host under attack will reset the > TCP connection. If you are in-line with the host under attack, you can see > the return traffic, and then you don't need to guess at the sequence number > even. You will be able to block the return traffic from ever reaching the > spoofed host. However, another way to accomplish the blocking is to DoS the > spoofed host. My bad. But the point seems moot, since if you're already able to squash traffic between the hosts you might as well do that instead of trying to induce a blocking response from portsentry. It's decidedly less trivial than sending a spoofed SYN. cheers, -thomas > > I don't remember where I read this, either in an RFC, or in the book > "Practical Unix and Internet Security". > > -- who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
thomas lakofski <[EMAIL PROTECTED]> writes: > Tim Haynes wrote: > Script kiddies generally don't know what's happened to them when > portsentry triggers, and go looking for easier fodder Random garbage traveling across the 'net is exactly this: Random garbage. > > Who says someone's going to go through a full SYN connect, anyway? Sounds like > > you need a stateful firewall to be somewhat safer. > > If they're not doing a full connect, portsentry won't trip. aka 'Won't notice anything except TCP-connect scans'. So somebody tries to connect to what he thinks is a service you offer and then you block his IP (which could have been allocated dynamically out of an ISP's pool and change within seconds without any necessity for a different machine at the other end)? A nice remote DoS: while true; do isdnctrl dial ippp0 nc -v -z isdnctrl hangup ippp0 done If I suffer from dynamic IP allocations, you would be blocking hundreds of IPs within a comparatively short amount of time (~ 3-5 seconds per IP). This will keep your machine quite busy and will block entirely legitimate accesses to the services you talk of below from people who happen get said IPs next. > If they're actually out to exploit the hole Why do you worry about holes in programs you don't even run? No one can attack you with a portmapper-exploit if there's no portmapper to talk to. > When using software like this it's assumed that you have a good idea > of what is happening on the box. If I know what's happening on the box, I don't need a tool like this, as I don't run any services except those I intend to, with the latter ones being reasonably configured. > I don't have it trigger as a result of anything other than a full > TCP connect. see above > I have a default-deny firewall with portsentry. Consider a default-REJECT firewall. This is a lot nicer to others. > There are only around 5 valid services on the box, So these are to ones to worry about. > and about 30 fake ports wired up to portsentry. So you deliberately open up thirty ports without any real need to do so to get *what*? Why not simply close them and be done with it? > People who have valid business on the box never run into trouble, They will, as demonstrated above. -- SIGSTOP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suspending services
On Mon, 29 Jan 2001 15:59:39 +, David Wright said: > Quoting Jürgen Dollinger ([EMAIL PROTECTED]): > > Piotr Tarnowski wrote: > > > What I did looks very tricky - I would prefer something similar to > > > putting '#' in front of line in /etc/inittab. > > > > Install file-rc. This will replace all those links with one configfile > > (/etc/runlevel.conf). Put a '#' in front of lines in /etc/runlevel.conf. > > Why not just mangle the name of /etc/init.d/whatever, > e.g. /etc/init.d/whatever-hidden. I would just put exit 0 in the /etc/init.d/ near the top of the file, after the '#!/bin/sh' -- Andrew
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Mon, Jan 29, 2001 at 12:33:03PM +, thomas lakofski wrote: > On Wed, 24 Jan 2001, Mark Suter wrote: > > > The only way under IPv4 be safe from spoofing is for everyone to > > implement proper Network Ingress Filtering [RFC2827, BCP0038] on > > their networks. Please, read this RFC. > > > > http://www.faqs.org/rfc/rfc2827.txt > > bah. all this talk about portsentry being dangerous forgets that you can also > run it so it only triggers after a full TCP connect. while not un-spoofable, > it's very hard for an attacker to spoof as they have to be in-line between your > host and the host they're trying to spoof. plus, they'll have a task guessing > sequence numbers. Not true. To spoof a TCP connection, you need to guess the initial sequence number, and you need to stop RST packets from the spoofed host from reaching the host under attack, or else the host under attack will reset the TCP connection. If you are in-line with the host under attack, you can see the return traffic, and then you don't need to guess at the sequence number even. You will be able to block the return traffic from ever reaching the spoofed host. However, another way to accomplish the blocking is to DoS the spoofed host. I don't remember where I read this, either in an RFC, or in the book "Practical Unix and Internet Security". -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suspending services
Quoting Jürgen Dollinger ([EMAIL PROTECTED]): > Piotr Tarnowski wrote: > > What I did looks very tricky - I would prefer something similar to > > putting '#' in front of line in /etc/inittab. > > Install file-rc. This will replace all those links with one configfile > (/etc/runlevel.conf). Put a '#' in front of lines in /etc/runlevel.conf. Why not just mangle the name of /etc/init.d/whatever, e.g. /etc/init.d/whatever-hidden. Cheers, -- Email: [EMAIL PROTECTED] Tel: +44 1908 653 739 Fax: +44 1908 655 151 Snail: David Wright, Earth Science Dept., Milton Keynes, England, MK7 6AA Disclaimer: These addresses are only for reaching me, and do not signify official stationery. Views expressed here are either my own or plagiarised.
Re: Suspending services
Piotr Tarnowski wrote: > What I did looks very tricky - I would prefer something similar to > putting '#' in front of line in /etc/inittab. Install file-rc. This will replace all those links with one configfile (/etc/runlevel.conf). Put a '#' in front of lines in /etc/runlevel.conf. -- /"\ Jürgen Dollinger \ / ASCII Ribbon Campaign Uni Ulm X Against HTML Mail http://www.home.pages.de/~zeitnot/ / \ #include
Re: Suspending services
On Mon, 29 Jan 2001 15:59:39 +, David Wright said: > Quoting Jürgen Dollinger ([EMAIL PROTECTED]): > > Piotr Tarnowski wrote: > > > What I did looks very tricky - I would prefer something similar to > > > putting '#' in front of line in /etc/inittab. > > > > Install file-rc. This will replace all those links with one configfile > > (/etc/runlevel.conf). Put a '#' in front of lines in /etc/runlevel.conf. > > Why not just mangle the name of /etc/init.d/whatever, > e.g. /etc/init.d/whatever-hidden. I would just put exit 0 in the /etc/init.d/ near the top of the file, after the '#!/bin/sh' -- Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Mon, 29 Jan 2001, Tim Haynes wrote: > On Mon, Jan 29, 2001 at 12:33:03PM +, thomas lakofski wrote: > > > bah. all this talk about portsentry being dangerous forgets that you can > > also run it so it only triggers after a full TCP connect. while not > > un-spoofable, it's very hard for an attacker to spoof as they have to be > > in-line between your host and the host they're trying to spoof. plus, > > they'll have a task guessing sequence numbers. > > Hard? Heard of determination, as well as skr1pt k1dd1es? Please tell me what you mean here. A cracker determined enough to break in between a host and mine in order to deny me access to it might as well take more effective direct action given the effort involved. Script kiddies generally don't know what's happened to them when portsentry triggers, and go looking for easier fodder -- if they even notice; most scans of that sort are automated, and the majority of noise these days is the activity of worms; cf. your logs. > > portsentry has been protecting my host without a firewall in front of it for > > three years now; it has always worked exactly as it said it would. > > Who says someone's going to go through a full SYN connect, anyway? Sounds like > you need a stateful firewall to be somewhat safer. If they're not doing a full connect, portsentry won't trip. I'll see the SYN in the logs. If they're actually out to exploit the hole and not scan you, they have to do a full connect, so I only worry about these. > I, for one, am decidedly not fond of anything that works by dangling bells on > a wire and hoping someone will trip them, not protecting valid listeners > against either bad content or non-SYN packets, not taking into account that > ports on which there are already listeners are possibly the results of a > default install that hasn't been reconfigured, and then goes ahead and messes > with my firewall rules as well. When using software like this it's assumed that you have a good idea of what is happening on the box. If you're dealing with an out-of-the-box install you have much more to worry about possibly than your portsentry configuration. Portsentry is just a single part of a complete security policy with many more elements to it than a portscan detector. Portsentry doesn't mess with firewall rules. > And what about UDP packets? It won't take as much effort to spoof one of > those, and you're susceptible to more IP#s than just your own being spoofed: > what if someone impersonates your upstream nameserver, webcache or router and > your portsentry or equivalent trips & blocks it? That's not just damned > annoying, it'd cost me valid business. I don't configure portsentry to listen for UDP connections, for the same reason I don't have it trigger as a result of anything other than a full TCP connect. What's more likely to cost you valid business is not understanding the technology fully. > I suppose it's horses for courses, anyway. If you like portsentry, go ahead, > see what happens, it might well suit you for a mostly-open scenario. (We do > this question on comp.os.linux.security every so often, btw.) I have a default-deny firewall with portsentry. There are only around 5 valid services on the box, and about 30 fake ports wired up to portsentry. People who have valid business on the box never run into trouble, people poking around to see what there is usually step on a fake service. > > all this stuff is in the documentation anyway. does anyone read > > documentation anymore? it's more productive than guessing in public. > > Docs, what're they? ;8^) ...suggest you read them before commenting further. -thomas > ~Tim > -- who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43
Re: Suspending services
Quoting Jürgen Dollinger ([EMAIL PROTECTED]): > Piotr Tarnowski wrote: > > What I did looks very tricky - I would prefer something similar to > > putting '#' in front of line in /etc/inittab. > > Install file-rc. This will replace all those links with one configfile > (/etc/runlevel.conf). Put a '#' in front of lines in /etc/runlevel.conf. Why not just mangle the name of /etc/init.d/whatever, e.g. /etc/init.d/whatever-hidden. Cheers, -- Email: [EMAIL PROTECTED] Tel: +44 1908 653 739 Fax: +44 1908 655 151 Snail: David Wright, Earth Science Dept., Milton Keynes, England, MK7 6AA Disclaimer: These addresses are only for reaching me, and do not signify official stationery. Views expressed here are either my own or plagiarised. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Mon, Jan 29, 2001 at 12:33:03PM +, thomas lakofski wrote: [] > bah. all this talk about portsentry being dangerous forgets that you can > also run it so it only triggers after a full TCP connect. while not > un-spoofable, it's very hard for an attacker to spoof as they have to be > in-line between your host and the host they're trying to spoof. plus, > they'll have a task guessing sequence numbers. Hard? Heard of determination, as well as skr1pt k1dd1es? > portsentry has been protecting my host without a firewall in front of it for > three years now; it has always worked exactly as it said it would. Who says someone's going to go through a full SYN connect, anyway? Sounds like you need a stateful firewall to be somewhat safer. I, for one, am decidedly not fond of anything that works by dangling bells on a wire and hoping someone will trip them, not protecting valid listeners against either bad content or non-SYN packets, not taking into account that ports on which there are already listeners are possibly the results of a default install that hasn't been reconfigured, and then goes ahead and messes with my firewall rules as well. And what about UDP packets? It won't take as much effort to spoof one of those, and you're susceptible to more IP#s than just your own being spoofed: what if someone impersonates your upstream nameserver, webcache or router and your portsentry or equivalent trips & blocks it? That's not just damned annoying, it'd cost me valid business. I suppose it's horses for courses, anyway. If you like portsentry, go ahead, see what happens, it might well suit you for a mostly-open scenario. (We do this question on comp.os.linux.security every so often, btw.) > all this stuff is in the documentation anyway. does anyone read > documentation anymore? it's more productive than guessing in public. Docs, what're they? ;8^) ~Tim -- | Geek Code: GCS dpu s-:+ a-- C UBLUAVHSC P+++ L++ E--- W+++(--) N++ | w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y- | The sun is melting over the hills, | http://piglet.is.dreaming.org/ | All our roads are waiting / To be revealed | [EMAIL PROTECTED]
Re: Suspending services
Piotr Tarnowski wrote: > What I did looks very tricky - I would prefer something similar to > putting '#' in front of line in /etc/inittab. Install file-rc. This will replace all those links with one configfile (/etc/runlevel.conf). Put a '#' in front of lines in /etc/runlevel.conf. -- /"\ Jürgen Dollinger \ / ASCII Ribbon Campaign Uni Ulm X Against HTML Mail http://www.home.pages.de/~zeitnot/ / \ #include -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Wed, 24 Jan 2001, Mark Suter wrote: > The only way under IPv4 be safe from spoofing is for everyone to > implement proper Network Ingress Filtering [RFC2827, BCP0038] on > their networks. Please, read this RFC. > > http://www.faqs.org/rfc/rfc2827.txt bah. all this talk about portsentry being dangerous forgets that you can also run it so it only triggers after a full TCP connect. while not un-spoofable, it's very hard for an attacker to spoof as they have to be in-line between your host and the host they're trying to spoof. plus, they'll have a task guessing sequence numbers. all this stuff is in the documentation anyway. does anyone read documentation anymore? it's more productive than guessing in public. portsentry has been protecting my host without a firewall in front of it for three years now; it has always worked exactly as it said it would. cheers, -thomas -- who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43
Re: portsentry dangerous? hardly; RTFM. (was Re: checking securitylogs)
On Mon, 29 Jan 2001, Tim Haynes wrote: > On Mon, Jan 29, 2001 at 12:33:03PM +, thomas lakofski wrote: > > > bah. all this talk about portsentry being dangerous forgets that you can > > also run it so it only triggers after a full TCP connect. while not > > un-spoofable, it's very hard for an attacker to spoof as they have to be > > in-line between your host and the host they're trying to spoof. plus, > > they'll have a task guessing sequence numbers. > > Hard? Heard of determination, as well as skr1pt k1dd1es? Please tell me what you mean here. A cracker determined enough to break in between a host and mine in order to deny me access to it might as well take more effective direct action given the effort involved. Script kiddies generally don't know what's happened to them when portsentry triggers, and go looking for easier fodder -- if they even notice; most scans of that sort are automated, and the majority of noise these days is the activity of worms; cf. your logs. > > portsentry has been protecting my host without a firewall in front of it for > > three years now; it has always worked exactly as it said it would. > > Who says someone's going to go through a full SYN connect, anyway? Sounds like > you need a stateful firewall to be somewhat safer. If they're not doing a full connect, portsentry won't trip. I'll see the SYN in the logs. If they're actually out to exploit the hole and not scan you, they have to do a full connect, so I only worry about these. > I, for one, am decidedly not fond of anything that works by dangling bells on > a wire and hoping someone will trip them, not protecting valid listeners > against either bad content or non-SYN packets, not taking into account that > ports on which there are already listeners are possibly the results of a > default install that hasn't been reconfigured, and then goes ahead and messes > with my firewall rules as well. When using software like this it's assumed that you have a good idea of what is happening on the box. If you're dealing with an out-of-the-box install you have much more to worry about possibly than your portsentry configuration. Portsentry is just a single part of a complete security policy with many more elements to it than a portscan detector. Portsentry doesn't mess with firewall rules. > And what about UDP packets? It won't take as much effort to spoof one of > those, and you're susceptible to more IP#s than just your own being spoofed: > what if someone impersonates your upstream nameserver, webcache or router and > your portsentry or equivalent trips & blocks it? That's not just damned > annoying, it'd cost me valid business. I don't configure portsentry to listen for UDP connections, for the same reason I don't have it trigger as a result of anything other than a full TCP connect. What's more likely to cost you valid business is not understanding the technology fully. > I suppose it's horses for courses, anyway. If you like portsentry, go ahead, > see what happens, it might well suit you for a mostly-open scenario. (We do > this question on comp.os.linux.security every so often, btw.) I have a default-deny firewall with portsentry. There are only around 5 valid services on the box, and about 30 fake ports wired up to portsentry. People who have valid business on the box never run into trouble, people poking around to see what there is usually step on a fake service. > > all this stuff is in the documentation anyway. does anyone read > > documentation anymore? it's more productive than guessing in public. > > Docs, what're they? ;8^) ...suggest you read them before commenting further. -thomas > ~Tim > -- who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Mon, Jan 29, 2001 at 12:33:03PM +, thomas lakofski wrote: [] > bah. all this talk about portsentry being dangerous forgets that you can > also run it so it only triggers after a full TCP connect. while not > un-spoofable, it's very hard for an attacker to spoof as they have to be > in-line between your host and the host they're trying to spoof. plus, > they'll have a task guessing sequence numbers. Hard? Heard of determination, as well as skr1pt k1dd1es? > portsentry has been protecting my host without a firewall in front of it for > three years now; it has always worked exactly as it said it would. Who says someone's going to go through a full SYN connect, anyway? Sounds like you need a stateful firewall to be somewhat safer. I, for one, am decidedly not fond of anything that works by dangling bells on a wire and hoping someone will trip them, not protecting valid listeners against either bad content or non-SYN packets, not taking into account that ports on which there are already listeners are possibly the results of a default install that hasn't been reconfigured, and then goes ahead and messes with my firewall rules as well. And what about UDP packets? It won't take as much effort to spoof one of those, and you're susceptible to more IP#s than just your own being spoofed: what if someone impersonates your upstream nameserver, webcache or router and your portsentry or equivalent trips & blocks it? That's not just damned annoying, it'd cost me valid business. I suppose it's horses for courses, anyway. If you like portsentry, go ahead, see what happens, it might well suit you for a mostly-open scenario. (We do this question on comp.os.linux.security every so often, btw.) > all this stuff is in the documentation anyway. does anyone read > documentation anymore? it's more productive than guessing in public. Docs, what're they? ;8^) ~Tim -- | Geek Code: GCS dpu s-:+ a-- C UBLUAVHSC P+++ L++ E--- W+++(--) N++ | w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y- | The sun is melting over the hills, | http://piglet.is.dreaming.org/ | All our roads are waiting / To be revealed | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suspending services
On Mon, Jan 29, 2001 at 11:16:13AM +0100, IC&S - Eelco van Beek wrote: > Hi Piotr, > Just use one of the free runlevels (4,5 even 2). Go to > /etc/rc and remove the links that you don't need and add the > ones you do. After that you can switch to that runlevel bij doing telinit > . All your services will be started and stopped for that > runlevel. ..or simply, add to the root's crontab a entry like @reboot /etc/init.d/ stop Biko -- -- Ho appreso che quando un neonato afferra con il suo piccolo pugno, per la prima volta, il dito di suo padre, lo tiene intrappolato per sempre. --
portsentry dangerous? hardly; RTFM. (was Re: checking securitylogs)
On Wed, 24 Jan 2001, Mark Suter wrote: > The only way under IPv4 be safe from spoofing is for everyone to > implement proper Network Ingress Filtering [RFC2827, BCP0038] on > their networks. Please, read this RFC. > > http://www.faqs.org/rfc/rfc2827.txt bah. all this talk about portsentry being dangerous forgets that you can also run it so it only triggers after a full TCP connect. while not un-spoofable, it's very hard for an attacker to spoof as they have to be in-line between your host and the host they're trying to spoof. plus, they'll have a task guessing sequence numbers. all this stuff is in the documentation anyway. does anyone read documentation anymore? it's more productive than guessing in public. portsentry has been protecting my host without a firewall in front of it for three years now; it has always worked exactly as it said it would. cheers, -thomas -- who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suspending services
Hi Piotr, Just use one of the free runlevels (4,5 even 2). Go to /etc/rc and remove the links that you don't need and add the ones you do. After that you can switch to that runlevel bij doing telinit . All your services will be started and stopped for that runlevel. Good luck, Eelco van Beek On Mon, 29 Jan 2001, Piotr Tarnowski wrote: > Hi, > > I have a Potato workstation with several services installed on it. > Thanks to links in /etc/rc?.d they start and stop automatically at > system startup/shutdown :-) > > The problem is that I do not need all of them all the time - when I work > on certain subject I would like to switch other services off (e.g. > working on PostgreSQL I do not need MySQL). > > 1. I can do this manually running '/etc/init.d/ stop' but I do > not want to do this every time I reboot the machine. > > 2. I can run 'update-rc.d -f remove' but then I have to > remember all the run levels where the service was linked (with order > numbers) and additionally it removes also 'K*' links so the service > (e.g. started by hand) will not have a chance to shutdown correctly. > > 3. Finally I made my own script which renames all > /etc/rc?.d/S## into skip-S## what works fine > (/etc/init.d/rc does not start such a service on system startup but > stops it during shutdown). The problem is that this is not standard > solution (e.g. not supported by dpkg and update-rc.d). > > Is there a better way for suspending services? > What I did looks very tricky - I would prefer something similar to > putting '#' in front of line in /etc/inittab. > > Regards, > Piotr Tarnowski > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
Suspending services
Hi, I have a Potato workstation with several services installed on it. Thanks to links in /etc/rc?.d they start and stop automatically at system startup/shutdown :-) The problem is that I do not need all of them all the time - when I work on certain subject I would like to switch other services off (e.g. working on PostgreSQL I do not need MySQL). 1. I can do this manually running '/etc/init.d/ stop' but I do not want to do this every time I reboot the machine. 2. I can run 'update-rc.d -f remove' but then I have to remember all the run levels where the service was linked (with order numbers) and additionally it removes also 'K*' links so the service (e.g. started by hand) will not have a chance to shutdown correctly. 3. Finally I made my own script which renames all /etc/rc?.d/S## into skip-S## what works fine (/etc/init.d/rc does not start such a service on system startup but stops it during shutdown). The problem is that this is not standard solution (e.g. not supported by dpkg and update-rc.d). Is there a better way for suspending services? What I did looks very tricky - I would prefer something similar to putting '#' in front of line in /etc/inittab. Regards, Piotr Tarnowski
Re: Suspending services
On Mon, Jan 29, 2001 at 11:16:13AM +0100, IC&S - Eelco van Beek wrote: > Hi Piotr, > Just use one of the free runlevels (4,5 even 2). Go to > /etc/rc and remove the links that you don't need and add the > ones you do. After that you can switch to that runlevel bij doing telinit > . All your services will be started and stopped for that > runlevel. ..or simply, add to the root's crontab a entry like @reboot /etc/init.d/ stop Biko -- -- Ho appreso che quando un neonato afferra con il suo piccolo pugno, per la prima volta, il dito di suo padre, lo tiene intrappolato per sempre. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suspending services
Hi Piotr, Just use one of the free runlevels (4,5 even 2). Go to /etc/rc and remove the links that you don't need and add the ones you do. After that you can switch to that runlevel bij doing telinit . All your services will be started and stopped for that runlevel. Good luck, Eelco van Beek On Mon, 29 Jan 2001, Piotr Tarnowski wrote: > Hi, > > I have a Potato workstation with several services installed on it. > Thanks to links in /etc/rc?.d they start and stop automatically at > system startup/shutdown :-) > > The problem is that I do not need all of them all the time - when I work > on certain subject I would like to switch other services off (e.g. > working on PostgreSQL I do not need MySQL). > > 1. I can do this manually running '/etc/init.d/ stop' but I do > not want to do this every time I reboot the machine. > > 2. I can run 'update-rc.d -f remove' but then I have to > remember all the run levels where the service was linked (with order > numbers) and additionally it removes also 'K*' links so the service > (e.g. started by hand) will not have a chance to shutdown correctly. > > 3. Finally I made my own script which renames all > /etc/rc?.d/S## into skip-S## what works fine > (/etc/init.d/rc does not start such a service on system startup but > stops it during shutdown). The problem is that this is not standard > solution (e.g. not supported by dpkg and update-rc.d). > > Is there a better way for suspending services? > What I did looks very tricky - I would prefer something similar to > putting '#' in front of line in /etc/inittab. > > Regards, > Piotr Tarnowski > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Suspending services
Hi, I have a Potato workstation with several services installed on it. Thanks to links in /etc/rc?.d they start and stop automatically at system startup/shutdown :-) The problem is that I do not need all of them all the time - when I work on certain subject I would like to switch other services off (e.g. working on PostgreSQL I do not need MySQL). 1. I can do this manually running '/etc/init.d/ stop' but I do not want to do this every time I reboot the machine. 2. I can run 'update-rc.d -f remove' but then I have to remember all the run levels where the service was linked (with order numbers) and additionally it removes also 'K*' links so the service (e.g. started by hand) will not have a chance to shutdown correctly. 3. Finally I made my own script which renames all /etc/rc?.d/S## into skip-S## what works fine (/etc/init.d/rc does not start such a service on system startup but stops it during shutdown). The problem is that this is not standard solution (e.g. not supported by dpkg and update-rc.d). Is there a better way for suspending services? What I did looks very tricky - I would prefer something similar to putting '#' in front of line in /etc/inittab. Regards, Piotr Tarnowski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
