Re: Where to install the firewall scripts
Nicolas Boullis [EMAIL PROTECTED] writes: [snip] # Drop spoofed packets iptables -A INPUT -i eth0 -j DROP -s 192.168.1.3 -d 0.0.0.0/0 What about outgoing spoofed packets? They didn't get dropped in this script at all. It's only a selfish half-hearted firewall if all it does is to protect yourself against incoming nasties; there's always a responsibility not to inflict dodgy packets on others, as much as possible. # let ICMP in and out iptables -A OUTPUT -o eth0 -j ACCEPT -p ICMP iptables -A INPUT -i eth0 -j ACCEPT -p ICMP This is folly. At the very least, rate-limit the outgoing chain, e.g.: | iptables -A OUTPUT -p icmp -m limit \ | --limit 5/s --limit-burst 10 \ | -j ACCEPT | iptables -A OUTPUT -p icmp -j outlog | | iptables -A OUTPUT -p udp -m limit \ | --limit 10/s --limit-burst 20 \ | -j ACCEPT | iptables -A OUTPUT -p udp -j outlog otherwise there's potential for being used as an amplifier in a (D)DoS attack. iptables -A INPUT -i eth0 -j ACCEPT -p TCP -s 0.0.0.0/0 --source-port domain #53 iptables -A INPUT -i eth0 -j ACCEPT -p UDP -s 0.0.0.0/0 --source-port domain #53 Hey! I'm a nice port, let me in!. Oops. Well, this ruleset looks realy dangerous to me since (unless I'm missing something obvious) you allow any machine to connect to any of your ports as soon as the connection is coming from ports 22 or 53. You should much better use connection tracking. Agreed, most definitely. Connection-tracking adds more dimensions to the question did I really ask for this?. And not only were the source-ports used as criteria for passing input packets, but the source-port is the *sole* criterion. What happens to packets with zany flags (SYN+FIN, or various christmas-tree combinations) set, from sport 22 to dport 22? They waltz right on in, and can be used for remote OS fingerprinting as well! Yow. You should add the rule: $IPTABLES -A INPUT -j ACCEPT -i eth0 -m state --state ESTABLISHED,RELATED and then remove the explicit rules for answers... Definitely. But more to the point, I'm not fussed on the layout of the above script anyway. It might not be suited to all, but I suggest a look at the comments in http://stirfried.vegetable.org.uk/packages/secure/iptables.sh might be in order. Note the order in which what things are done. ~Tim -- http://spodzone.org.uk/
Re: Intrusion Attempts
Ariel Graneros [EMAIL PROTECTED] writes: On Tue, 3 Dec 2002 21:19:28 EST [EMAIL PROTECTED] wrote: Hi. Can you help me. Who do I report the above to. I have 2 firewalls running and tonight I was attacked from the same address 172 times in less than an hour. These people want banning off the net. It is certainly a violation of my privacy. A dozen times is an excuse but 172, I ask you. Please come back. A good solution is portsentry: http://www.psionic.com/products/portsentry.html No, a good solution is whois(1). If the OP's complaint is valid (do we have logs / a description of what was going off? Has he taken a cold shower since posting?) then a complaint to abuse@ the ISP providing the incoming IP#s *may* be appropriate. Otherwise there are perfectly rational explanations for quite a lot of perceived attacks; maybe this avenue should be persued further. PortSentry is part of the TriSentry suite of security tools. It is a program designed to detect and respond to port scans against a target host in real-time. Stealth detection modes are available under all Unix platforms and detects SYN, FIN, NULL, XMAS, and Oddball packet scans. All modes support real-time blocking and reporting of violations. I've just explained over on comp.os.linux.security why portsentry is a lousy idea, but to summarize: a) dynamic means nothing when the packets shouldn't have permeated to user-space at all; b) risk of auto-DoS if someone spoofs a given set of valuable IP#s; c) having to have no firewall, or extra holes in a firewall, in order to detect a finite set of events seems daft when you could just be blocking them already by default. IOW, write a proper firewall with DROP-by-default and only as few services open as you need, and if you want a different view on what attacks are going off, get something with a *much* larger rule-base like _snort_ instead. And when you get a real incident of either massive abuse or targetted attacks, *then* you whine to the people responsible. 172 packets dropped in a firewall does not a DoS - or even an attack - make. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intrusion Attempts
Ariel Graneros [EMAIL PROTECTED] writes: On Tue, 3 Dec 2002 21:19:28 EST [EMAIL PROTECTED] wrote: Hi. Can you help me. Who do I report the above to. I have 2 firewalls running and tonight I was attacked from the same address 172 times in less than an hour. These people want banning off the net. It is certainly a violation of my privacy. A dozen times is an excuse but 172, I ask you. Please come back. A good solution is portsentry: http://www.psionic.com/products/portsentry.html No, a good solution is whois(1). If the OP's complaint is valid (do we have logs / a description of what was going off? Has he taken a cold shower since posting?) then a complaint to abuse@ the ISP providing the incoming IP#s *may* be appropriate. Otherwise there are perfectly rational explanations for quite a lot of perceived attacks; maybe this avenue should be persued further. PortSentry is part of the TriSentry suite of security tools. It is a program designed to detect and respond to port scans against a target host in real-time. Stealth detection modes are available under all Unix platforms and detects SYN, FIN, NULL, XMAS, and Oddball packet scans. All modes support real-time blocking and reporting of violations. I've just explained over on comp.os.linux.security why portsentry is a lousy idea, but to summarize: a) dynamic means nothing when the packets shouldn't have permeated to user-space at all; b) risk of auto-DoS if someone spoofs a given set of valuable IP#s; c) having to have no firewall, or extra holes in a firewall, in order to detect a finite set of events seems daft when you could just be blocking them already by default. IOW, write a proper firewall with DROP-by-default and only as few services open as you need, and if you want a different view on what attacks are going off, get something with a *much* larger rule-base like _snort_ instead. And when you get a real incident of either massive abuse or targetted attacks, *then* you whine to the people responsible. 172 packets dropped in a firewall does not a DoS - or even an attack - make. ~Tim -- http://spodzone.org.uk/
Re: Intrusion Attempts
Matthias Hentges [EMAIL PROTECTED] writes: [snip] I've just explained over on comp.os.linux.security why portsentry is a lousy idea, but to summarize: a) dynamic means nothing when the packets shouldn't have permeated to user-space at all; b) risk of auto-DoS if someone spoofs a given set of valuable IP#s; c) having to have no firewall, or extra holes in a firewall, in order to detect a finite set of events seems daft when you could just be blocking them already by default. ACK But portsentry may still be a good thing to have if for some reason the firewall gets flushed. I know, this should never happen, but it can. cron(8) is also your friend for this and other reasons. It's also a better use of memory-space than to have a daemon lurking never used in case of firewall failure. Then again... Swings and roundabouts, I guess. [snip] ~Tim -- http://spodzone.org.uk/
Re: test of non-subscribed user
Kjetil Kjernsmo [EMAIL PROTECTED] writes: (Aside: I do that by having a line link rel=NeverEMail href=mailto:[EMAIL PROTECTED] in many web pages, and that works excellently, this address is harvested and spammed, and when that happens, the intention is that subsequent mail is stopped. This markup may not work in the future, though, as more User Agents start to support the link element). I've got a few traps like that on my web-pages; a user browsing the rendered page will never see anything untoward, but a very stupid or a malicious bot will add itself to a list of IP#s blocked in .htaccess dead quickly. I've seen this linked to within a /30 of an email-spammer's IP# as well. Boy was I chuffed :) This is why I think it may be spammers who actually do this, it is easy to see that spammers can drastically reduce the value of Razor by sending it large amounts of legitimate e-mail from the lists that Razor-users would normally use. It's been a known phenomenon for a considerable number of months, in the right circles. This is why advertising your trap addresses with the words `razor' or `pit' or `dump' in them is a really *bad* idea. I hear that the new Razor has some trust-model, that may be able to address this. It's not particularly new, either. Razor2, been out for a large number of months, has had a trust-model for submitting in the name of a given UID, so that the ID can be scored. I'm not sure of the dynamics of this, but `Listed in Razor' sounds to me like it's lacking refinement - listed in razor by 10 mostly reliable people would be far more like it. Actually, I think we're in a arms-race with the spammers that requires the spam-tools to updated more frequently than the normal release-cycle would accomodate for, but that's another story. Let's not lose sight of the small fact that the original problem is the use of a mailing-list to propagate spam, and that when a spammer starts hitting a list repeatedly, the responsible thing to do is block that cretin as accurately as possible. In such an instance, I would say that sending an accurately identified subset of mailing-list traffic to Razor2 was very well justified. ~Tim -- http://spodzone.org.uk/
Re: Latest libpcap tcpdump sources from tcpdump.org contain atrojan
Steve Suehring [EMAIL PROTECTED] writes: You are correct insofar as it triggers at compile time for libpcap, the configure script to be exact. I grabbed a copy of the trojan'ed libpcap and compiled it in a sandbox machine. You can do a strings of the compiled libpcap.a and grep for 1963. Doing so yields these results: debian:~/libpcap-0.7.1# strings libpcap.a | grep 1963 1963 not port 1963 I _didn't_ have the same result when running the command against woody's libpcap library files on my boxen. Obviously, I'm not saying that you will have the same result or that this is the only method to find the problem, etc. It worked for me though. [snip] OK, this is another helpful check, thanks. I checked my boxes for one or two strings (`mash', `mars' and a switch statement in one of the reports linked off slashdot) yesterday in both the libraries and the debian/Unstable sources, also not finding any positive matches. HTreassures, ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Latest libpcap tcpdump sources from tcpdump.org contain a trojan
Steve Suehring [EMAIL PROTECTED] writes: You are correct insofar as it triggers at compile time for libpcap, the configure script to be exact. I grabbed a copy of the trojan'ed libpcap and compiled it in a sandbox machine. You can do a strings of the compiled libpcap.a and grep for 1963. Doing so yields these results: debian:~/libpcap-0.7.1# strings libpcap.a | grep 1963 1963 not port 1963 I _didn't_ have the same result when running the command against woody's libpcap library files on my boxen. Obviously, I'm not saying that you will have the same result or that this is the only method to find the problem, etc. It worked for me though. [snip] OK, this is another helpful check, thanks. I checked my boxes for one or two strings (`mash', `mars' and a switch statement in one of the reports linked off slashdot) yesterday in both the libraries and the debian/Unstable sources, also not finding any positive matches. HTreassures, ~Tim -- http://spodzone.org.uk/
Re: spam
Vasarhelyi asd Daniel [EMAIL PROTECTED] writes: I'm not sure what you want to do, but if you want to filter spam, you shouldn't multiply it. Notifying target user and sending a copy to other ppl is quite unnecessary and waste of bandwidth. Trying to notify the sender may be unnecessary too: spammers use non-existing mailbox names and if you generate an automaticed reply, your mailbox get's filled with Mail Deliverity Errors. In the other side, in this case sender gets a report message, lowering the risk you miss something important. Just a thought here, from a relatively long-term spamassassin ifile bogofilter user: if you accept the mail, you're joining the vast masses of folks who already just press delete - whether you filter it off locally afterwards or not is neither here nor there, as to the spammer, the address has not been rejected and is therefore valid for more next week. What I'd really like is to read through the body of the text and then have the MTA (exim in particular) run the mail by bogofilter, and then reject at the very end: `200 Message accepted for delivery', yeah *right*. That way I'd be giving a clear signal to whoever attempts to inject the mail - not to a faked envelope Sender, or From: header; nor would I be passively accepting the thing. Anyone got any HOWTOs for this with exim? :) ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: spam
Kjetil Kjernsmo [EMAIL PROTECTED] writes: Anyone got any HOWTOs for this with exim? :) Isn't this just about what Marc does with Exim and Spamassassin...? http://marc.merlins.org/linux/exim/sa.html He's even got Exim-4 debs with this stuff there. Or was it something else you had in mind? Bingo. Exactly what the doctor ordered - I sympathize with his reasons and everything. At last :) Thanks a lot :) ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: spam
Vasarhelyi asd Daniel [EMAIL PROTECTED] writes: I'm not sure what you want to do, but if you want to filter spam, you shouldn't multiply it. Notifying target user and sending a copy to other ppl is quite unnecessary and waste of bandwidth. Trying to notify the sender may be unnecessary too: spammers use non-existing mailbox names and if you generate an automaticed reply, your mailbox get's filled with Mail Deliverity Errors. In the other side, in this case sender gets a report message, lowering the risk you miss something important. Just a thought here, from a relatively long-term spamassassin ifile bogofilter user: if you accept the mail, you're joining the vast masses of folks who already just press delete - whether you filter it off locally afterwards or not is neither here nor there, as to the spammer, the address has not been rejected and is therefore valid for more next week. What I'd really like is to read through the body of the text and then have the MTA (exim in particular) run the mail by bogofilter, and then reject at the very end: `200 Message accepted for delivery', yeah *right*. That way I'd be giving a clear signal to whoever attempts to inject the mail - not to a faked envelope Sender, or From: header; nor would I be passively accepting the thing. Anyone got any HOWTOs for this with exim? :) ~Tim -- http://spodzone.org.uk/
Re: spam
Kjetil Kjernsmo [EMAIL PROTECTED] writes: Anyone got any HOWTOs for this with exim? :) Isn't this just about what Marc does with Exim and Spamassassin...? http://marc.merlins.org/linux/exim/sa.html He's even got Exim-4 debs with this stuff there. Or was it something else you had in mind? Bingo. Exactly what the doctor ordered - I sympathize with his reasons and everything. At last :) Thanks a lot :) ~Tim -- http://spodzone.org.uk/
Re: AIDE Information Overload
Arthur de Jong [EMAIL PROTECTED] writes: On Tue, 22 Oct 2002, Kjetil Kjernsmo wrote: I'd like to ask what people do with their AIDE output at times when a lot of things change on their system? I've gone through the AIDE configuration, and I feel like having configured it well, to catch the things that might be trojaned while leaving out things that I would certainly change often. I use aide on several machines but it is not really usefull on for example a Debian/unstable machine or a machine that has a lot of changing files where aide is used to inspect development files. I use it here on a basically Testing box - I've just automated the daily upgrade process so that it re-runs aide immediately after the dist-upgrade. That way I get all changes to important bits of the filesystem since the last package upgrade every day in the mail. (It's partly a matter of policy to use this script rather than wedging things by hand.) #!/bin/sh PATH=/sbin:/usr/sbin:/bin:/usr/bin ; export PATH apt-get update chmod -R og=rX /var/lib/apt/lists /var/cache/apt/archives nice apt-get -u dist-upgrade echo echo All done. Now running AIDE echo cd /var/lib/aide nice nice aide -i mv aide.db.new aide.db echo Cool echo ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AIDE Information Overload
[EMAIL PROTECTED] (Dion Mendel) writes: I'm not providing an answer, but rather asking another question on this topic. Which files do people exclude when using integrity checkers (e.g. aide/tripwire etc)? Under normal system use, certain files do change (e.g. /etc/mtab, That does? Maybe on your box if you're [u]mounting things a lot, I suppose, but that's not always the case. If it causes you hassle, ignore it by all means :8) /dev/tty*). Including these files in the integrity checker's database will certainly produce spurious warning about file modification each time the checker is run. So what files are safe to exclude? Is it really necessary to check for modifications to /usr/share/doc/* ? I would say that it's possible a file could be created in any of those directories (c.f. where various trojans and worms and kits put their files by default - /dev/.lib/, /usr/lib/ and so on), therefore it should be checked. Run aide frequently and keep the number of files changed down by refreshing the database every thing you dist-upgrade; also, get used to what it tells you - e.g. /dev/console and a few others changing is indicative of a reboot, you soon get used to identifying that. I've compromised on avoiding checking all of: | zsh/scr, potato 5:06PM # grep '^!' /etc/aide/aide.conf | !/var/log/snort | !/dev/pts | !/var/run | !/home but anything else is most definitely being checked, with various combinations of options as per the default config file. I've used tripwire but haven't used aide, so if aide automatically handles changeable system files this is a moot question. It handles them if you set it up properly ;8) ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AIDE Information Overload
Arthur de Jong [EMAIL PROTECTED] writes: On Tue, 22 Oct 2002, Kjetil Kjernsmo wrote: I'd like to ask what people do with their AIDE output at times when a lot of things change on their system? I've gone through the AIDE configuration, and I feel like having configured it well, to catch the things that might be trojaned while leaving out things that I would certainly change often. I use aide on several machines but it is not really usefull on for example a Debian/unstable machine or a machine that has a lot of changing files where aide is used to inspect development files. I use it here on a basically Testing box - I've just automated the daily upgrade process so that it re-runs aide immediately after the dist-upgrade. That way I get all changes to important bits of the filesystem since the last package upgrade every day in the mail. (It's partly a matter of policy to use this script rather than wedging things by hand.) #!/bin/sh PATH=/sbin:/usr/sbin:/bin:/usr/bin ; export PATH apt-get update chmod -R og=rX /var/lib/apt/lists /var/cache/apt/archives nice apt-get -u dist-upgrade echo echo All done. Now running AIDE echo cd /var/lib/aide nice nice aide -i mv aide.db.new aide.db echo Cool echo ~Tim -- http://spodzone.org.uk/
Re: AIDE Information Overload
[EMAIL PROTECTED] (Dion Mendel) writes: I'm not providing an answer, but rather asking another question on this topic. Which files do people exclude when using integrity checkers (e.g. aide/tripwire etc)? Under normal system use, certain files do change (e.g. /etc/mtab, That does? Maybe on your box if you're [u]mounting things a lot, I suppose, but that's not always the case. If it causes you hassle, ignore it by all means :8) /dev/tty*). Including these files in the integrity checker's database will certainly produce spurious warning about file modification each time the checker is run. So what files are safe to exclude? Is it really necessary to check for modifications to /usr/share/doc/* ? I would say that it's possible a file could be created in any of those directories (c.f. where various trojans and worms and kits put their files by default - /dev/.lib/, /usr/lib/ and so on), therefore it should be checked. Run aide frequently and keep the number of files changed down by refreshing the database every thing you dist-upgrade; also, get used to what it tells you - e.g. /dev/console and a few others changing is indicative of a reboot, you soon get used to identifying that. I've compromised on avoiding checking all of: | zsh/scr, potato 5:06PM # grep '^!' /etc/aide/aide.conf | !/var/log/snort | !/dev/pts | !/var/run | !/home but anything else is most definitely being checked, with various combinations of options as per the default config file. I've used tripwire but haven't used aide, so if aide automatically handles changeable system files this is a moot question. It handles them if you set it up properly ;8) ~Tim -- http://spodzone.org.uk/
Re: Having been open relay for a moment
Anton Zinoviev [EMAIL PROTECTED] writes:
1. The spammers continue attempts to use lml.bas.bg as a relay. As a
result exim generates about 50Mb log files per hour. How I can stop
exim from logging messages like refused relay to ...?
Any patterns in the attackers? One of the options is that it's a small
select group of IP#s or netblocks repeatedly hitting you; if so, you can
form a few reports to relevant ISPs, and/or dump them all in a firewall
chain. (If not, you're screwed :8)
2. It is possible that in the queues of exim there are still some
spams. How can I remove them?
How big are your queues? You might find the -Mvb (view bodies), -Mvh (view
headers), -Mrm (guess) options useful - again, find a way to identify these
things, involving find, grep and then
| awk 'NF=3 {print $3}' | xargs exim -Mrm
to remove them by exim-message-id.
3. In the log-files of exim I have a huge list of e-mail addresses of
spammers (such as [EMAIL PROTECTED]). Can I do something useful
with them?
Very little, I would've thought. Chances are those are either
a) victims' addresses;
b) generated semi-random crap (look for adam297100*8*, et seq).
In the (rather smaller) logs I get, I see semi-random looking email
addresses bearing no resemblance to the real world; the only thing I do
*occasionally* see is a slight overlap of a few letters with usernames that
have originated on this box.
Attempted relaying to `[EMAIL PROTECTED]' isn't likely to do anyone any
good.
I'd say you should analyse them and look what's most likely to be valid -
and if any, report them (preferably in patterns) to relevant sysadmins. If
it means the account was going to be used as e.g. a spam return mailbox,
they can take pre-emptive action to block it, assuming you do your sums
right.
4. It seams to me that spammers ought to pay ordb.org for their
service. A few years ago when I had similar problem ordb gave me
enough time to fix the problem. Why don't they do the same now? As
humans we can make mistakes.
Dunno. Take it up with ordb.org is all I could suggest there.
~Tim
--
http://spodzone.org.uk/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Having been open relay for a moment
Anton Zinoviev [EMAIL PROTECTED] writes:
1. The spammers continue attempts to use lml.bas.bg as a relay. As a
result exim generates about 50Mb log files per hour. How I can stop
exim from logging messages like refused relay to ...?
Any patterns in the attackers? One of the options is that it's a small
select group of IP#s or netblocks repeatedly hitting you; if so, you can
form a few reports to relevant ISPs, and/or dump them all in a firewall
chain. (If not, you're screwed :8)
2. It is possible that in the queues of exim there are still some
spams. How can I remove them?
How big are your queues? You might find the -Mvb (view bodies), -Mvh (view
headers), -Mrm (guess) options useful - again, find a way to identify these
things, involving find, grep and then
| awk 'NF=3 {print $3}' | xargs exim -Mrm
to remove them by exim-message-id.
3. In the log-files of exim I have a huge list of e-mail addresses of
spammers (such as [EMAIL PROTECTED]). Can I do something useful
with them?
Very little, I would've thought. Chances are those are either
a) victims' addresses;
b) generated semi-random crap (look for adam297100*8*, et seq).
In the (rather smaller) logs I get, I see semi-random looking email
addresses bearing no resemblance to the real world; the only thing I do
*occasionally* see is a slight overlap of a few letters with usernames that
have originated on this box.
Attempted relaying to [EMAIL PROTECTED]' isn't likely to do anyone any
good.
I'd say you should analyse them and look what's most likely to be valid -
and if any, report them (preferably in patterns) to relevant sysadmins. If
it means the account was going to be used as e.g. a spam return mailbox,
they can take pre-emptive action to block it, assuming you do your sums
right.
4. It seams to me that spammers ought to pay ordb.org for their
service. A few years ago when I had similar problem ordb gave me
enough time to fix the problem. Why don't they do the same now? As
humans we can make mistakes.
Dunno. Take it up with ordb.org is all I could suggest there.
~Tim
--
http://spodzone.org.uk/
Re: Report on last cmd
Oi You two. Sort it out offline once and for all, will you? I've getting thoroughly pissed off with the debian-* mailing lists; a month or two ago d-secure was actively pro-spam, now there's nothing but off- topic crap. Makes me wonder why I bother reading it, looking for things to respond to, maybe even see if I've got something helpful to contribute - becuase when all I see is flames spam, I'm not interested. threadplonk ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Report on last cmd
Oi You two. Sort it out offline once and for all, will you? I've getting thoroughly pissed off with the debian-* mailing lists; a month or two ago d-secure was actively pro-spam, now there's nothing but off- topic crap. Makes me wonder why I bother reading it, looking for things to respond to, maybe even see if I've got something helpful to contribute - becuase when all I see is flames spam, I'm not interested. threadplonk ~Tim -- http://spodzone.org.uk/
Re: ssh upgrade problems (potato)
Simon Young [EMAIL PROTECTED] writes: On Fri, Sep 27, 2002 at 10:10:16AM -0400, don wrote: if its a local machine you could dpkg --purg the old ssh then just do your install Yes indeed. I could do that, and it would probably work. In fact, this is most likely what I'll end up doing - but first I'd really like to know what the problem is, and if there's a 'nice' way of getting around it. I'd agree with your assessment that it's picking up the wrong ssh-keygen, as I was thinking that by the time you suggested it :) Let's assume, for the moment, that it's remote machine :-) chmod 000 `which ssh-keygen` sshd -p somehighnumber22 apt-get install ssh At least that way you still have either the old or possibly even the new sshd listening on 22, and a backup entry-point if you need it. I'd recommend the middle step every time you're about to play with the ssh package as a precaution on a remote machine anyway (unless you're lucky enough to have a serial console toy). ~Tim -- http://spodzone.org.uk/
Re: icmp: type-#69 (catched that bastard)
Cristian Ionescu-Idbohrn [EMAIL PROTECTED] writes: On Sun, 15 Sep 2002, Tim Haynes wrote: Could you include a complete `tcpdump -X' on one or two of the packets, maybe make a series of them available for download in libpcap form so I can oogle them in ethereal? Catched and oogled in ethereal: [snip] | Flags: 0x00 | .0.. = Don't fragment: Not set | ..0. = More fragments: Not set | Fragment offset: 0 | Time to live: 111 | Protocol: ICMP (0x01) | Header checksum: 0x6ffb (correct) | Source: 62.211.198.163 (62.211.198.163) How many hops away is the supposed source if you traceroute to it and how does that compare to the 17 the above would imply? ~Tim -- http://spodzone.org.uk/
Re: icmp: type-#69 (catched that bastard)
Cristian Ionescu-Idbohrn [EMAIL PROTECTED] writes: [snip] How many hops away is the supposed source if you traceroute to it and how does that compare to the 17 the above would imply? How did you work the 17 out? I assume that the box's OS is setting to the nearest power of two by default and that it's being decremented by one per router en-route as normal. In this case, (- 128 111) is 17 :) Here's the traceroute: 1 x.y.z.1 ([EMAIL PROTECTED] ISP) 25.604 ms 23.43 ms24.26 ms [snip] 16 151.99.29.222 (151.99.29.222) 284.126 ms 280.547 ms 287.283 ms 17 80.17.211.142 (80.17.211.142) 405.897 ms 287.745 ms 284.2 ms 18 151.99.29.100 (151.99.29.100) 284.638 ms 282.311 ms 299.727 ms 19 62.211.198.163 (62.211.198.163) 603.76 ms 649.345 ms 653.241 ms OK. Either we have asymmetric routing or that packet is spoofed from something that's really 17 hops away in order to get your network (hence the broadcast) to attack a box that's really 19 hops away. Or the box is emitting dodgy packets itself (less likely). ~Tim -- http://spodzone.org.uk/
Re: icmp: type-#69 (catched that bastard)
Cristian Ionescu-Idbohrn [EMAIL PROTECTED] writes: [snip] OK. Either we have asymmetric routing or that packet is spoofed from something that's really 17 hops away in order to get your network (hence the broadcast) to attack a box that's really 19 hops away. Or the box is emitting dodgy packets itself (less likely). The thing I wonder about is: who knows how to answer to a icmp type-#69? Worms? Root kits? I can't name one, but that doesn't say an awful lot. Googling for `ICMP type 69' doesn't lead to any obvious results, either. :( ~Tim -- http://spodzone.org.uk/
Re: icmp: type-#69 (catched that bastard)
martin f krafft [EMAIL PROTECTED] writes: also sprach Tim Haynes [EMAIL PROTECTED] [2002.09.15.1812 +0200]: I can't name one, but that doesn't say an awful lot. Googling for `ICMP type 69' doesn't lead to any obvious results, either. :( sorry to spurt into the thread randomly. Not a problem.. using any packet generation tool, i don't think it's quite hard to create an ICMP type 69 packet. i wouldn't be concerned if i were you. i don't know *anyone* using type 69... The problem that Cristian reported originally (on uk.comp.os.linux, IIRC) was reporting lots of these packets - note that they're unknown ICMP type (so quite likely to provoke a `param-problem' response) destined for a network broadcast address (so likely to bombard the source IP# with yet more ICMP). That's a potential smurf-a-like DoS lurking. The fact that the TTLs are out by 2 needs explaining to me, and crafted packets is one of the possible options. ~Tim -- http://spodzone.org.uk/
Re: Fwd: bugtraq.c httpd apache ssl attack
Wichert Akkerman [EMAIL PROTECTED] writes: Previously Phillip Hofmeister wrote: I am using RedHat 7.3 with Apache 1.3.23. Someone used the program bugtraq.c to explore an modSSL buffer overflow to get access to a shell. The attack creates a file named /tmp/.bugtraq.c and compiles it using gcc. One wonders why you would have gcc installed on a webserver.. Quite so. Never used to happen in my day ;) Another idea that might help lessen the impact of this silly mess: iptables -A OUTPUT -p udp --dport 53.. ACCEPT iptables -A OUTPUT -p udp --dport 123 . ACCEPT iptables -A OUTPUT -p udp -j outlog #The output logging rule iptables -A outlog -j LOG -m limit \ --limit 3 --limit-burst 5 \ --log-prefix catch-all:(out) iptables -A outlog -j DROP i.e., allow useful UDP like 53 and 123 with whatever your normal accept rules are, and then limit everything else and drop stuff that goes over- limits, with a useful log message to say what's happened. $0.02, ~Tim -- http://spodzone.org.uk/
Re: Mail delivery errors...
Jussi Ekholm [EMAIL PROTECTED] writes: I was just wondering if anyone else is getting this kind of mail delivery errors from debian-security, although the mails still go through. I've been getting at least three of these already: | Date: Sat, 3 Aug 2002 14:10:00 +0300 | From: [EMAIL PROTECTED] | Subject: Mail Delivery Error | To: Jussi Ekholm [EMAIL PROTECTED] | | No such user: [EMAIL PROTECTED] And I'm very much sure, that all of my mails I've sent to debian-security@lists.debian.org - so, something's broken in lists.debian.org end? Or am I alone with this problem? I don't think I've ever managed to post a mail on debian-security without getting at least 3-4 bounces or misconfigured `vacation's. The above could equally well be someone using a tracking or filtering email address for traffic from the group, not necessarily a misconfiguration of the list server - see above, I collapse all my related to debian traffic into a specific userid @ domain. HTH, ~Tim -- http://spodzone.org.uk/
Spam handling (Re: Your Confirmation Required)
Three things: 1. Rad0s-?aw is an idiot for pasting the whole spam email again; 2. these things should be blocked at source within debian, as someone suggested *yesterday*; 3. I've added a procmail rule here locally so that all mails From: .*italy.*minute get automatically reported to Razor2. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam handling (Re: Your Confirmation Required)
Rad0s-³aw Gajewski [EMAIL PROTECTED] writes: 1. Tim Haynes is an idiot that doesn't know that normal action for confirmation required is (if not SHOULD BE) replying an e-mail, and how is it that i got this confirmation message from your list?? How you (un)subscribe to this list is your own problem. You're the total fuckwit who's replying to spam forwarding it onto the whole list. Consider yourself plonked. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam handling (Re: Your Confirmation Required)
martin f krafft [EMAIL PROTECTED] writes: also sprach Tim Haynes [EMAIL PROTECTED] [2002.07.18.1241 +0200]: 3. I've added a procmail rule here locally so that all mails From: .*italy.*minute get automatically reported to Razor2. Could you please stop that, this is ridiculous. No. The rule in question matches exactly every single mail from the spammer that *debian* is *still* pushing at me on what's supposed to be 2 or 3 content-full mailing lists. I'll stop automatically filtering when the rule is no longer being actively proven. No way is 15 spams in 24hrs acceptable. Deal with it. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Didn't we have that whole spam discussion last week?
[EMAIL PROTECTED] writes: Alexander Thoma: italyminutes.it - *plonk* Who the f**k is readding the list to this sh*t ?!?!?!? I doubt anyone has readded the list :) It's just a spamming monkey that is spamming several debian lists, how about having some more active blacklist policies for the lists? Well, some people seem to have problems enough with the mere idea of reporting spam from/on a mailing list to an appropriate agent, if that's some indication of how spam-friendly Debian has become of late. I think it's abount time for a [EMAIL PROTECTED] At the moment the topic is discussed on several lists at the same time. A very good idea. Not to mention, I get at least 3 bounces for every mail sent on debian-secure at the moment as well, which seems to be about par for the course for the past few weeks. When it's so hard filtering out real security-related content from noise (some level of off-topicness is always acceptable) and spam (totally unacceptable), I really wonder why I bother saying anything at all. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Your Confirmation Required
Paolo Pedaletti [EMAIL PROTECTED] writes: I have phoned to ALESSANDRO MARTINELLI (+39 06 93953072) from: whois Italyminutes.it [snip] his secretary has said that the server will shut down as soon as possible and he is non resposible of this spam. If it will continue to spam I'll phone them this afternoon again. Thank you, good idea, I appreciate the effort taken :) Cheers, ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam handling (Re: Your Confirmation Required)
martin f krafft [EMAIL PROTECTED] writes: I'll stop automatically filtering when the rule is no longer being actively proven. No way is 15 spams in 24hrs acceptable. Deal with it. There's no point in bouncing to Razor2. go ahead and filter to /dev/null. that's acceptable. I suggest you refrain from telling me what is acceptable at my site by way of covering for your own inactivity. Clue: spam isn't acceptable, nor is saying just press delete (or filtering to /dev/null). ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good Day
Noah L. Meyerhans [EMAIL PROTECTED] writes: I don't agree with the policy of rejecting mail due to a lack of a reverse DNS entry. However, rfc-ignorant.org runs several nice blacklists, including ip-whois, which I subscribe to. This blacklist contains netblocks for which no valid whois information exists. So, for example, if your netblock whois (at whois.arin.net or whois.apnic.net or whatever) contains information that is not useful for contacting the netblock administrator, you'll be listed and I'll reject your mail. I believe this to be a much better policy than simply rejecting all mail received from a host with no PTR. Given that rfc-ignorant lists *.uk for not having contact info, would you like to refine that to `shite idea'? Some of the other blacklists at rfc-ignorant.org are nice as well. The postmaster blacklist contains domains that don't have a working postmaster alias. That's more like it, although why penalise the sender because of the domain? Not everyone always uses a personal domain for their mail... More to the point, spamassassin already contains a test for MX records for the From: field; I like that one. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good Day -- RR and rbl
Phillip Hofmeister [EMAIL PROTECTED] writes: On Tue, Jul 02, 2002 at 02:29:22PM -0500, John Goerzen wrote: No, it's a perfectly valid reason. Just because other admins do not perfectly mirror your opinions does not mean that they are stupid. Not only that, but there are a number of Debian users and developers that, for various reasons, find themselves listed in things like DUL or rfc-ignorant, despite the fact that they are using services for legitimate purposes. I happen to agree, what if their is a BIND worm going around that takes down 10% of the net's NS servers...now no one would have reverse resolution...just a thought...silly and unlikely though it may be. I suggest that fantastic reasons are unnecessary. That someone might have a valid point to contribute is enough reason to permit them; that their domain administrator doesn't know what they're doing (eg no reverse DNS or no postmaster@) really doesn't strike me as a valid reason to prevent everyone else on this list from making up our own silly minds. Of course, there's always this handy X-RBL-Warning: header that could be inserted in the mail as it comes from the list server... Nah, just block or don't block, no compromises allowed ;^] ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
John Galt [EMAIL PROTECTED] writes: that's what happened--the EPIC hole gave user. monkey.org (Dug Song) was using standard security practice at that point, it's just for convenience's sake, the user had a few things screened, including a rootshell, probably because of the traditional Conventional Wisdom of not permitting any remote logins of root. I find this kind of ironic in another sense, as Dug Song is the author of a Man in the Middle tool that works against older SSHes Depends.. if you manage to intercept the user's password, you can type it into sudo just like they do and get the same level of root privelege. In that case, not leaving screen running would have still been as bad. No doubt this is why tightening sudo down is a good idea. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-security] Re: DSA-134-1
Wichert Akkerman [EMAIL PROTECTED] writes: Previously Christian Hammers wrote: Don't be too hard to him, if he'd pointed out that only default BSD is vulnerable it would not have been too hard to find the exploit before everybody had updated. He could have mentioned ssh protocol 1 wasn't vulnerable.. At the very least. I'm trying not to think how many Debian policies have been bent because of oh no! it's ssh!-factor - porting a protocol-2-enabled *new feature* down to Stable with the resultant paragraphs on `create a proto-2 keypair' and `these are untested' in the DSA causes inconvenience to folks running Stable+Secure boxes, in addition to those of us using Testing but keeping an eye on DSAs. And we're all going to have to upgrade again when 3.4 comes out properly as it is... Could I suggest that `until we're told what it is, there is no problem' be considered as an approach? ;/ ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PermitRootLogin enabled by default
Sebastian Rittau [EMAIL PROTECTED] writes: On Wed, Jun 26, 2002 at 02:11:00PM +0200, InfoEmergencias - Luis Gómez wrote: IMHO, we'd better set it to no. I always thought it was much better. Is there any landscape in which you may want to allow direct root login to your host? Yes, there is. For example I have some servers that retrieve their user information from a database. If the database is not reachable, an ordinary user can't login, but root can, since it's the only local account with login privileges. Yes, this is an idea, along with simple backups (over scp/rsync, without sudo server-side). Doesn't sashroot also constitute uid-0 login and fall subject to the above? But then this is a special case that doesn't require root logins enabled by default. On the other hand I don't see why allowing direct root logins is a problem. Having `PermitRootLogin yes' gives someone a known username to brute-force. Fortunately, sshd_config(5) to the rescue, here: | PermitRootLogin | Specifies whether root can login using ssh(1). The argument | must be ``yes'', ``without-password'', | ``forced-commands-only'' or ``no''. The default is ``yes''. For potentially-interactive purposes (rescuing a remote server), I'd go with without-password; if you know that root coming in via this access means is only going to want to run one command (eg for backup purposes when you have console access a matter of metres away) then you can afford the extra security of a forced-commands-only approach[0]. [0] Note FWIW that this is not you asked for the wrong command, so I'll do nothing; it's no matter what you asked, I'm going to do Foo as specified in the cmd= restriction... ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Things to watch on my server
vdongen [EMAIL PROTECTED] writes: You could run logcheck, which instead of reading the logs mails you entries that are unusual or attempted break ins OK, my thoughts: a) use syslog-ng to filter firewall events into a separate firewall.log; b) use fwlogwatch to generate HTML tables of what's going off and mail you summaries every day; c) push all log entries out to a separate loghost if possible, too; d) install AIDE and get that to mail nightly; e) keep an eye on http://www.linuxsecurity.com/ and other sundry security-related sites. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changing umask
Julián Muñoz [EMAIL PROTECTED] writes: I would like to know if changing default umask to 077 in /etc/profile will cause me problem to install and update new packages. Or then, must I go back to 022 ? I see no reference to umask in the packaging how-to. So in general, the permissions of the installed files will be dependent of our shell umask ? It works fine for me here. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: secure file transfer (again)
Alf B Lervåg [EMAIL PROTECTED] writes: ssh is already up and running on the servers, so I'm figuring that the sftp server shouldn't be too hard to get running. Problem is making things easy to use for our students. (Guess this falls in under the sftp client question.) | zsh/scr 11:36AM / # grep ftp /etc/ssh/sshd_config | Subsystem sftp/usr/lib/sftp-server (I think this is all that's required server-side, isn't it?) You might also find http://www.freessh.org/windows.html a useful starting point - see unix, java and `other' OSs in the top menu too. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Uh-oh. Cracked allready. I think...
Kjetil Kjernsmo [EMAIL PROTECTED] writes: The fact they don't show up when you do a local scan confirms this. These services aren't running on your machine. So, what you're saying is that all this alarm is for no good reason...? There has been no l337 h4X0rz trying to get into my box? Well, that would be really be good news! Of course, it will not make me stop reading about how to secure the box. There is still an outside chance you have either a) a tcp listener on only the external interface that's only started in response to an ICMP ping of specific content/length and/or b) some very dodgy (probably LKM-based) trojan that's either deflecting nmap and/or netstat calls and/or however, the chances of this are slimmer than I am paranoid. I'd say you should be grateful to have got away lightly - kill listeners you're not using, firewall it with iptables[0] and sort out your nIDS - the chances are you'll soon find out if you're haemoraghing evil scans or anything. [0] I have a simple enough starter script floating around at http://spodzone.org.uk/packages/secure/iptables.sh if it helps at all - no doubt others have their own approaches, but at least mine has no gui requirements other than $EDITOR ;) ATB, ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Uh-oh. Cracked allready. I think...
Kjetil Kjernsmo [EMAIL PROTECTED] writes: Thanks for all the responses. I realize it's pretty bold trying put a box on the net without having extensive admin experience beforehand. But I think I'm learning fast, and I hope I'll be able to do it without placing any burden on the rest of the net. That is, except for you guys... :-) Your help is greatly appreciated! We do our best :) Well if something's got on there that you don't remember installing, can I have some of what you're taking? ;) Hehe... I was so sure it would be at least one copy of Star Wars II, but no... ;-) There's nothing here... I've walked through the whole disk, and I can't find anything of any size that I don't know what is. Whatever it is, it has to be rather small... Unfortunately, the only way to examine all the files on the disk/s is to reboot the box off clean r/o media (read: rescue CD), mount them r/o, and examine them by hand. You're highly unlikely to find something with trojanned binaries and/or a kernel module sitting there intercepting syscalls saying we're not listening on port and oh look, an exec() call to ps, use ps.fake instead - all 3 of which are possible these days. It's at this point that you should start debugging what's really listening on your box from what a scanner says you are. I suggest you nmap yourself to see what ports you really have open, and compare against netstat -plant | grep LIST (here's your first potential clue: if netstat complains about `-p', it's been trojanned.) It complained about -p when I wasn't root... Nah, when you're root if the option completely isn't understood then you've got problems. (I mention this only because it was the first thing that gave a cracked box away to me.) OK. This is what nmap says, launched from my workstation: Port State Service 22/tcp openssh 25/tcp opensmtp These are generally safe - especially in Testing. 53/tcp opendomain OK, what version of what are you running for this? 80/tcp openhttp 110/tcpopenpop-3 111/tcpopensunrpc Portmapper (111) is an absolute liability - I flatly refuse to run it on any public-facing box, and it must *never* be externally visible. 137/tcpfilterednetbios-ns 138/tcpfilterednetbios-dgm 139/tcpfilterednetbios-ssn You're running samba then? 6346/tcp filteredgnutella Hang around, it's filtered? That means it never replied to nmap but there were other ports that did - the mixture of responses means nmap knows this port is dropping responses. I think you have an anomaly, myself. So, the suspicious gnutella port isn't in the latter. I don't know what kdm is doing there, BTW. I unselected X and desktop in the initial tasksel. There seems to have been installed some X stuff nevertheless, but neither KDE nor kdm has ever been installed on this box. Ah, good you said that. It's not kdm necessarily, it's because it's the first port to which a non-privileged app may bind, =1024. (See why the next one is 1025...) So for netstat: pooh:~# netstat -plant | grep LIST tcp 0 0.0.0.0:10240.0.0.0:* LISTEN 209/rpc.statd tcp 0 0.0.0.0:10250.0.0.0:* LISTEN 236/rpc.mountd tcp 0 0.0.0.0:139 0.0.0.0:* LISTEN 218/inetd tcp 0 0.0.0.0:110 0.0.0.0:* LISTEN 218/inetd tcp 0 0.0.0.0:111 0.0.0.0:* LISTEN 123/portmap tcp 0 0.0.0.0:80 0.0.0.0:* LISTEN 6586/apache tcp 0 217.77.32.186:530.0.0.0:* LISTEN 194/named tcp 0 127.0.0.1:530.0.0.0:* LISTEN 194/named tcp 0 0.0.0.0:22 0.0.0.0:* LISTEN 285/sshd tcp 0 127.0.0.1:953 0.0.0.0:* LISTEN 201/lwresd tcp 0 0.0.0.0:25 0.0.0.0:* LISTEN 218/inetd (slightly reformatted to fit better) (reformatted better still ;) I'd not worry about that lot myself. Unless I've missed something, it's not obviously different from the nmap results, is it? Next, if you've got a socket listener or 6346 (IIRC, the most frequently used gnutella port), try telnetting into it and see what banner, if any, it presents. Nope, nothing... pooh:~# telnet 217.77.32.186 6346 Trying 217.77.32.186... telnet: Unable to connect to remote host: Connection refused to be sure. That's promising. And it didn't turn up in netstat, just when you used a particular box to do the nmap? Does the port come and go over time at all? At some stage you should probably run _chkrootkit_ on the blighter, too. Yeah, I've done that several times. chkrootkit was described in Securing Debian, so I installed it before moving it, but only ran it just after I saw the gnutella port. Nothing detected. OK. It's not a complete guarantee as it uses potentially-tainted tools, but it pushes the odds more in your favour. Do you have an original AIDE database from immediately
Re: Uh-oh. Cracked allready. I think...
Kjetil Kjernsmo [EMAIL PROTECTED] writes: Thanks for all the responses. I realize it's pretty bold trying put a box on the net without having extensive admin experience beforehand. But I think I'm learning fast, and I hope I'll be able to do it without placing any burden on the rest of the net. That is, except for you guys... :-) Your help is greatly appreciated! We do our best :) Well if something's got on there that you don't remember installing, can I have some of what you're taking? ;) Hehe... I was so sure it would be at least one copy of Star Wars II, but no... ;-) There's nothing here... I've walked through the whole disk, and I can't find anything of any size that I don't know what is. Whatever it is, it has to be rather small... Unfortunately, the only way to examine all the files on the disk/s is to reboot the box off clean r/o media (read: rescue CD), mount them r/o, and examine them by hand. You're highly unlikely to find something with trojanned binaries and/or a kernel module sitting there intercepting syscalls saying we're not listening on port and oh look, an exec() call to ps, use ps.fake instead - all 3 of which are possible these days. It's at this point that you should start debugging what's really listening on your box from what a scanner says you are. I suggest you nmap yourself to see what ports you really have open, and compare against netstat -plant | grep LIST (here's your first potential clue: if netstat complains about `-p', it's been trojanned.) It complained about -p when I wasn't root... Nah, when you're root if the option completely isn't understood then you've got problems. (I mention this only because it was the first thing that gave a cracked box away to me.) OK. This is what nmap says, launched from my workstation: Port State Service 22/tcp openssh 25/tcp opensmtp These are generally safe - especially in Testing. 53/tcp opendomain OK, what version of what are you running for this? 80/tcp openhttp 110/tcpopenpop-3 111/tcpopensunrpc Portmapper (111) is an absolute liability - I flatly refuse to run it on any public-facing box, and it must *never* be externally visible. 137/tcpfilterednetbios-ns 138/tcpfilterednetbios-dgm 139/tcpfilterednetbios-ssn You're running samba then? 6346/tcp filteredgnutella Hang around, it's filtered? That means it never replied to nmap but there were other ports that did - the mixture of responses means nmap knows this port is dropping responses. I think you have an anomaly, myself. So, the suspicious gnutella port isn't in the latter. I don't know what kdm is doing there, BTW. I unselected X and desktop in the initial tasksel. There seems to have been installed some X stuff nevertheless, but neither KDE nor kdm has ever been installed on this box. Ah, good you said that. It's not kdm necessarily, it's because it's the first port to which a non-privileged app may bind, =1024. (See why the next one is 1025...) So for netstat: pooh:~# netstat -plant | grep LIST tcp 0 0.0.0.0:10240.0.0.0:* LISTEN 209/rpc.statd tcp 0 0.0.0.0:10250.0.0.0:* LISTEN 236/rpc.mountd tcp 0 0.0.0.0:139 0.0.0.0:* LISTEN 218/inetd tcp 0 0.0.0.0:110 0.0.0.0:* LISTEN 218/inetd tcp 0 0.0.0.0:111 0.0.0.0:* LISTEN 123/portmap tcp 0 0.0.0.0:80 0.0.0.0:* LISTEN 6586/apache tcp 0 217.77.32.186:530.0.0.0:* LISTEN 194/named tcp 0 127.0.0.1:530.0.0.0:* LISTEN 194/named tcp 0 0.0.0.0:22 0.0.0.0:* LISTEN 285/sshd tcp 0 127.0.0.1:953 0.0.0.0:* LISTEN 201/lwresd tcp 0 0.0.0.0:25 0.0.0.0:* LISTEN 218/inetd (slightly reformatted to fit better) (reformatted better still ;) I'd not worry about that lot myself. Unless I've missed something, it's not obviously different from the nmap results, is it? Next, if you've got a socket listener or 6346 (IIRC, the most frequently used gnutella port), try telnetting into it and see what banner, if any, it presents. Nope, nothing... pooh:~# telnet 217.77.32.186 6346 Trying 217.77.32.186... telnet: Unable to connect to remote host: Connection refused to be sure. That's promising. And it didn't turn up in netstat, just when you used a particular box to do the nmap? Does the port come and go over time at all? At some stage you should probably run _chkrootkit_ on the blighter, too. Yeah, I've done that several times. chkrootkit was described in Securing Debian, so I installed it before moving it, but only ran it just after I saw the gnutella port. Nothing detected. OK. It's not a complete guarantee as it uses potentially-tainted tools, but it pushes the odds more in your favour. Do you have an original AIDE database from immediately
Re: Uh-oh. Cracked allready. I think...
Kjetil Kjernsmo [EMAIL PROTECTED] writes: On 24 May 2002, Tim Haynes wrote: Unfortunately, the only way to examine all the files on the disk/s is to reboot the box off clean r/o media (read: rescue CD), mount them r/o, and examine them by hand. Yeah, I guess so. In the absence of this, keeping an eye on what the box is doing is a close second. 53/tcp opendomain OK, what version of what are you running for this? According to Nessus: The remote bind version is : 9.2.0 But I guess this need not be accessible from the outside. I'm not running a name server myself (though I plan to some time...) Well if you do, I'll recommend bind 9.2.x for the job unless there's a better version out there by that time ;) Last count of remote exploits: bind-8.x, lots. bind-9.x, none. 80/tcp openhttp 110/tcpopenpop-3 111/tcpopensunrpc Portmapper (111) is an absolute liability - I flatly refuse to run it on any public-facing box, and it must *never* be externally visible. *tears rolling* I would like to mount the three partitions where I keep my web pages over NFS, but my server and I will be on different networks. But OK I installed harden-servers. You might be better off with `rsync -e ssh' and passphraseless keys, depending on exactly how immediate you want change notifications to propogate. You should definitely consider the relationship between your servers in the firewall design - at the very least I'd say portmap+nfs is permitted *IFF* you firewall down to the two machines. But preferably, don't do it at all. 137/tcpfilterednetbios-ns 138/tcpfilterednetbios-dgm 139/tcpfilterednetbios-ssn You're running samba then? No, it was installed in tasksel IIRC, I thought I removed it, but apparently not. I removed samba, but they didn't disappear, something more I have to do? If you were running samba out of xinetd, you'll probably want to disable the relevant services in /etc/xinetd.conf (and reload xinetd). 6346/tcp filteredgnutella Hang around, it's filtered? That means it never replied to nmap but there were other ports that did - the mixture of responses means nmap knows this port is dropping responses. It does? Yes. I think you have an anomaly, myself. OK. You might want to check for a firewall between your workstation and the server in question dropping port 6346 specifically - in fact, if you really want to be sure, run tcpdump on the server while you nmap it for -p6345-6347 (a range crossing the port in question) and see if port 6346 is scanned at all - if not, it's an outgoing firewall getting in your way :) Uh, don't think so. I installed snort, but didn't take the time to play with it. I thought that would do the job too... Can I get the required information from the snort install...? Nope, snort is for dynamic logs of dodgy packets going by. I see. ... you can log the results into mysql and run _Acid_ against it, too. That generates pretty-picture html overviews and stuff. What could be wrong about e.g.: ForwardX11 yes Erm, that's a little bit weird. | StrictModes yes | X11Forwarding yes | X11DisplayOffset 10 | AllowTcpForwarding yes I think you're somehow using an old sshd_config with a proto2-enabled sshd. Or a non-free ssh against openssh. Possibly. Eh, Berend pointed out to me that I was making sshd read ssh_config... That could be it, but I have been messing a bit with it, so there could be more. That would also explain it :8) You should keep an eye the incoming/outgoing traffic, though; I thought I saw a utility for analysing how many hosts/ports a box contacts over time recently, which will help. OK, I'll search. Well if nothing else, you can use _iptraf_ in per-port summary mode :) Set up snort and AIDE as a matter of urgency too They're up. AIDE looked easy to configure, apt seemed to do that. Choose what hashes you maintain for which directory very carefully. I have separate settings for: =/boot$ Binlib # Binaries /bin Binlib /sbin Binlib /usr/bin Binlib /usr/sbin Binlib /usr/local/bin Binlib /usr/local/sbin Binlib /usr/games Binlib # Libraries /lib Binlib /usr/lib Binlib /usr/local/lib Binlib # Log files /var/log$ StaticDir /var/log/aide/aide.log(.[0-9])?(.gz)? Databases /var/log/aide/error.log(.[0-9])?(.gz)? Databases /var/log/setuid.changes(.[0-9])?(.gz)? Databases /var/log Logs !/var/log/snort # Devices !/dev/pts /dev Devices # Other miscellaneous files /var/run$ StaticDir !/var/run if it helps :) and dns dangling around all over the place, nor will you be aware what's going off if you don't start firewalling things properly and keep a close eye on your IDS. I'll read up on IPtables. Definitely. http://netfilter.samba.org/ is one possible starting point; I'd also
Re: Uh-oh. Cracked allready. I think...
Kjetil Kjernsmo [EMAIL PROTECTED] writes: To address this first: It is the gnutella server that causes alarm, so is there anything I could have done that would install gnutella but escape my attention? I certainly never did apt-get install gnutella (I tried apt-get remove gnutella yesterday, with no effect). Is it likely that if I don't know how it got there, has been installed by a cracker? I've tried to telnet 217.77.32.186 6346 but get no connection. Well if something's got on there that you don't remember installing, can I have some of what you're taking? ;) It's at this point that you should start debugging what's really listening on your box from what a scanner says you are. I suggest you nmap yourself to see what ports you really have open, and compare against netstat -plant | grep LIST (here's your first potential clue: if netstat complains about `-p', it's been trojanned.) Next, if you've got a socket listener or 6346 (IIRC, the most frequently used gnutella port), try telnetting into it and see what banner, if any, it presents. At some stage you should probably run _chkrootkit_ on the blighter, too. Do you have an original AIDE database from immediately after it was installed? I tried to set the suggested PermitRootLogin for ssh to no, but ssh gave me some messsage that I thought meant it did't recognize it. That's weird. Try running an sshd from a terminal, to read /etc/ssh/*, and see if you get any syntax errors there. Here's another idea: | zsh/scr, potato 5:03PM piglet % md5sum /var/cache/apt/archives/*ssh* | /usr/sbin/sshd | 0c1ef2fb11aa02a3b6af95157038e71b ssh_1%3a3.0.2p1-9_i386.deb | a68ece0b46d2f42b655d0bf6434c317a /usr/sbin/sshd I complied in IPtables in the kernel, but I haven't read up on how to use it. I have also installed some of the harden packages. Last night, I thought my system was running quite well, though I had noticed gnutella running. I figured it was time to run nessus, so I did. It seems to report many holes, some holes that I guess would be exploitable. I put the report on URL: http://www.astro.uio.no/~kjetikj/tmp/pooh-nessus-2002-22-05.html Bear in mind two things: a) Debian apply patches in stable as/when required, we don't follow upstream version#s regardlessly b) testing is a strange halfway-house between stable and unstable; you can expect a security fix to make it into Unstable pretty soon (as it tracks upstream versions) but it'll be at least a fortnight after that it hits Testing. That said, you probably want to check the Changelog(.Debian.gz) for ssh - I'd be surprised if the patches required hadn't made it down into Testing. If it has been cracked, what should I do? I could run up to my hosts and have them turn it off, I guess. But then what? I have really no clue what happened, and while I could turn off some more services, it seems like the biggest security problems are with ssh and smtp, that is, OpenSSH and Exim, so would a clean reinstall help a lot? http://www.cert.org/tech_tips/win-UNIX-system_compromise.html. First assess whether you really have been breached; if you have, you *must* reformat, reinstall, update all packages, firewall, install an IDS (aide) and nIDS (snort) - but take a forensic last-minute backup before you do. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Uh-oh. Cracked allready. I think...
Kjetil Kjernsmo [EMAIL PROTECTED] writes: To address this first: It is the gnutella server that causes alarm, so is there anything I could have done that would install gnutella but escape my attention? I certainly never did apt-get install gnutella (I tried apt-get remove gnutella yesterday, with no effect). Is it likely that if I don't know how it got there, has been installed by a cracker? I've tried to telnet 217.77.32.186 6346 but get no connection. Well if something's got on there that you don't remember installing, can I have some of what you're taking? ;) It's at this point that you should start debugging what's really listening on your box from what a scanner says you are. I suggest you nmap yourself to see what ports you really have open, and compare against netstat -plant | grep LIST (here's your first potential clue: if netstat complains about `-p', it's been trojanned.) Next, if you've got a socket listener or 6346 (IIRC, the most frequently used gnutella port), try telnetting into it and see what banner, if any, it presents. At some stage you should probably run _chkrootkit_ on the blighter, too. Do you have an original AIDE database from immediately after it was installed? I tried to set the suggested PermitRootLogin for ssh to no, but ssh gave me some messsage that I thought meant it did't recognize it. That's weird. Try running an sshd from a terminal, to read /etc/ssh/*, and see if you get any syntax errors there. Here's another idea: | zsh/scr, potato 5:03PM piglet % md5sum /var/cache/apt/archives/*ssh* | /usr/sbin/sshd | 0c1ef2fb11aa02a3b6af95157038e71b ssh_1%3a3.0.2p1-9_i386.deb | a68ece0b46d2f42b655d0bf6434c317a /usr/sbin/sshd I complied in IPtables in the kernel, but I haven't read up on how to use it. I have also installed some of the harden packages. Last night, I thought my system was running quite well, though I had noticed gnutella running. I figured it was time to run nessus, so I did. It seems to report many holes, some holes that I guess would be exploitable. I put the report on URL: http://www.astro.uio.no/~kjetikj/tmp/pooh-nessus-2002-22-05.html Bear in mind two things: a) Debian apply patches in stable as/when required, we don't follow upstream version#s regardlessly b) testing is a strange halfway-house between stable and unstable; you can expect a security fix to make it into Unstable pretty soon (as it tracks upstream versions) but it'll be at least a fortnight after that it hits Testing. That said, you probably want to check the Changelog(.Debian.gz) for ssh - I'd be surprised if the patches required hadn't made it down into Testing. If it has been cracked, what should I do? I could run up to my hosts and have them turn it off, I guess. But then what? I have really no clue what happened, and while I could turn off some more services, it seems like the biggest security problems are with ssh and smtp, that is, OpenSSH and Exim, so would a clean reinstall help a lot? http://www.cert.org/tech_tips/win-UNIX-system_compromise.html. First assess whether you really have been breached; if you have, you *must* reformat, reinstall, update all packages, firewall, install an IDS (aide) and nIDS (snort) - but take a forensic last-minute backup before you do. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What this named log means?
César Augusto Seronni Filho [EMAIL PROTECTED] writes: this messages happened on my messages file: named[487]: lame server on '146.73.163.200.in-addr.arpa' (in '73.163.200.in-add.arpa'?): 200.199.252.68#53 what this lame server means? http://www.nominum.com/resources/faqs/bind-faqs.html#lameserver ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What this named log means?
César Augusto Seronni Filho [EMAIL PROTECTED] writes: this messages happened on my messages file: named[487]: lame server on '146.73.163.200.in-addr.arpa' (in '73.163.200.in-add.arpa'?): 200.199.252.68#53 what this lame server means? http://www.nominum.com/resources/faqs/bind-faqs.html#lameserver ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Iptables config
Laurent Luyckx [EMAIL PROTECTED] writes: [snip] i get cant conect to smtp service when trying to mail try by rejecting port 113 requests with : iptables -I INPUT -p tcp -s 0/0 --dport 113 -i eth0 -j REJECT If you're going to use -j REJECT for a TCP packet, you really ought to use `--reject-with tcp-reset' as well. See http://logi.cc/linux/reject_or_deny.php3 for more. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Big ICMP with don't Fragment bit
Thorsten Kruschel [EMAIL PROTECTED] writes: has anybody an Idea how to create an ICMP Packet with size of 1500 and don't Fragment bit set? Or how to filter such Packets generally with IPChains? I've the Problem, that a Maschine cancels the external connection some times. No entrys in Syslog or anywhere else. In my Intrusion Detection I see some maschines sending such Packets before the Maschine cancels the Connection to the external Net. If it's causing you problems, such as breaking the PMTU discovery (the typical one - what machines are giving you problems?), you shouldn't be filtering ICMP echo-requests. In ipchains, that's the best you can do - open yourself up to pings. In iptables, you can use the length module to filter by length within the ICMP protocol: | zsh, potato 2:52PM piglet % iptables -m length -h | tail [snip] | | length v1.2.5 options: | [!] --length length[:length]Match packet length against value or range ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about some network services
Anne Carasik [EMAIL PROTECTED] writes: The question of what to do with these ports comes up every once in a while on this list. Some people prefer to leave them on, others turn them off. I don't think there's ever been an exploit that involves these ports, as the code is quite simple (i.e. easy to implement securely). Occasionally, there may be a DOS attack, but nothing invasive. Depends. I thought it was an old trick to persuade echo ports to talk to each other and run away giggling... Yes, this is good advice, and something that never occurs to most people. Most common services these days run quite happily in standalone mode, so there's often no reason to use inetd at all. Given most everything can run through SSH or SSL (at least TCP-based) :) The short reasons in favour of inetd are that a) you save memory space by not having the daemon running all the time (at the slight cost of latency on start-up - choose according to your situation!); b) (if using xinetd instead of boring old inetd) you can apply the same syntax for per-host rate- and resource-limiting to many services that would otherwise either require much research to implement (try exim and apache for size), or not even implement it at all; c) if you're writing a network listener of your own you can implement it in (x)inetd without having to worry about writing the regular listen-accept- process loop *again*. Not that it's *always* a good idea to use inetd, but it still has its plus- points by a long way, especially xinetd instead. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about some network services
Anne Carasik [EMAIL PROTECTED] writes: The question of what to do with these ports comes up every once in a while on this list. Some people prefer to leave them on, others turn them off. I don't think there's ever been an exploit that involves these ports, as the code is quite simple (i.e. easy to implement securely). Occasionally, there may be a DOS attack, but nothing invasive. Depends. I thought it was an old trick to persuade echo ports to talk to each other and run away giggling... Yes, this is good advice, and something that never occurs to most people. Most common services these days run quite happily in standalone mode, so there's often no reason to use inetd at all. Given most everything can run through SSH or SSL (at least TCP-based) :) The short reasons in favour of inetd are that a) you save memory space by not having the daemon running all the time (at the slight cost of latency on start-up - choose according to your situation!); b) (if using xinetd instead of boring old inetd) you can apply the same syntax for per-host rate- and resource-limiting to many services that would otherwise either require much research to implement (try exim and apache for size), or not even implement it at all; c) if you're writing a network listener of your own you can implement it in (x)inetd without having to worry about writing the regular listen-accept- process loop *again*. Not that it's *always* a good idea to use inetd, but it still has its plus- points by a long way, especially xinetd instead. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual logging
[EMAIL PROTECTED] writes: Packet log: input DENY eth0 PROTO=1 yyy.y.yy.yy:3 xxx.xx.xxx.xxx:13 L=56 S=0x00 I=29688 F=0x T=244 (#30) It's the :13 part that I found unusual, A little research has revealed that it may be an attempt to fingerprint our system to see what is available. I was lead to believe that this is the Timeday port. Is this correct ? xxx is our public IP address. And yyy is the remote IP address that is making the contact. You should've started with the PROTO=1 bit... | zsh, spodzone 12:00AM piglet % ipchains -h icmp | ipchains 1.3.10, 1-Sep-2000 | | Valid ICMP Types: | Type Code Description | 00 echo-reply (pong) | 3 destination-unreachable [snip] | 12 TOS-host-unreachable | 13 communication-prohibited | 14 host-precedence-violation | 15 precedence-cutoff to which the short answer is, don't go there then. More to the point, you should *not* be filtering ICMP type 3 anyway. http://logi.cc/linux/NetfilterLogAnalyzer.php3 is your friend. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual logging
[EMAIL PROTECTED] writes: Packet log: input DENY eth0 PROTO=1 yyy.y.yy.yy:3 xxx.xx.xxx.xxx:13 L=56 S=0x00 I=29688 F=0x T=244 (#30) It's the :13 part that I found unusual, A little research has revealed that it may be an attempt to fingerprint our system to see what is available. I was lead to believe that this is the Timeday port. Is this correct ? xxx is our public IP address. And yyy is the remote IP address that is making the contact. You should've started with the PROTO=1 bit... | zsh, spodzone 12:00AM piglet % ipchains -h icmp | ipchains 1.3.10, 1-Sep-2000 | | Valid ICMP Types: | Type Code Description | 00 echo-reply (pong) | 3 destination-unreachable [snip] | 12 TOS-host-unreachable | 13 communication-prohibited | 14 host-precedence-violation | 15 precedence-cutoff to which the short answer is, don't go there then. More to the point, you should *not* be filtering ICMP type 3 anyway. http://logi.cc/linux/NetfilterLogAnalyzer.php3 is your friend. ~Tim -- http://spodzone.org.uk/
Re: IP chains logs to console
[EMAIL PROTECTED] writes: [snip] and set user = root group = adm on the file and the DENY messages are still logged to disk and the console. I've got plenty of disk space. I found two threads via Google (June '02 and Sept. '02) where people were having the same problem, but neither thread had a solution. http://lists.debian.org/debian-firewall/2001/debian-firewall-200106/msg00167.html http://www.progsoc.uts.edu.au/lists/slug/2001/September/msg00436.html Anyone know how I fix this? Thanks. `klogd -c 4' is your friend. Adjust /etc/init.d/klogd to suit. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IP chains logs to console
[EMAIL PROTECTED] writes: [snip] and set user = root group = adm on the file and the DENY messages are still logged to disk and the console. I've got plenty of disk space. I found two threads via Google (June '02 and Sept. '02) where people were having the same problem, but neither thread had a solution. http://lists.debian.org/debian-firewall/2001/debian-firewall-200106/msg00167.html http://www.progsoc.uts.edu.au/lists/slug/2001/September/msg00436.html Anyone know how I fix this? Thanks. `klogd -c 4' is your friend. Adjust /etc/init.d/klogd to suit. ~Tim -- http://spodzone.org.uk/
Re: Stupid Question - Proxy Internals
Josh Frick [EMAIL PROTECTED] writes: [snip] Something to be aware of is that having two firewalls of the same flavour will not buy you any more security. If a crack/exploit works on one then it will work on the other. Try replacing one of them with another OS and firewall solution. Eventually, I plan on replacing both Coyote boxes with IPtables-capable firewalls. (For statefull inspection). The choke will be Woody, I think, with SNORT, and the gateway will either be floppyfw or Devil Linux or a homebrew busybox. But they're still going to be i386 Linux. Hopefully, I can disable module support in both. If you're going in for multiple layers of firewalling (why??) then what the above says is that you shouldn't be using the same OS for each - the Linux is the same whether you change distributions around or what. You're looking at one of the BSDs as a relatively obvious choice when it's *variety* you want. Adding a third ipchains box will give you as much protection as adding a piece of wire. This is unclear. In the context of your first statement, I guess you're saying it's just as easy to break into? Hey look, I just broke the first level of firewall! Oh wow, the second one is just the same... And blow me down with a gnat's fart, but the 3rd as well? Coo that was hard. Last I checked, exploits didn't bother saying uh oh, I'm only supported on $DISTRO, they find instances of daemons with vulnerabilities, and wooie, quicker than a greased leech going through a wormhole, they're in. Where a proxy is extremely useful is being able to inspect (and correct or reject) the data it receives before it gives it to the client machine. That is you can plug a virus scanner into squid, remove active x, etc. How does it do so? By default? Or do I need to fine-tune squid.conf and danted.conf, or recompile both? If somone has access to a port running Dante or Squid, then it doesn't matter a jot whether they've gone through 1 firewall or 17 to get there, they're in your face and they're playing with a service you're providing. That's why you *must* secure the service as much as possible - set up proper ACLs preferably with username password authentication in both dante and squid, keep them both uptodate, only allow connections from inside going out, consider running both proxies within libsafe; you name it, you need to secure the services *far* more than you need to provide firewalls before you get there. Of *course* you've got to play with squid.conf and danted.conf. Wear asbestos gloves whilst reading the entirety of the config files *and* corresponding manpages, so you can set everything the way it should be. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Stupid Question - Proxy Internals
Josh Frick [EMAIL PROTECTED] writes: [snip] Something to be aware of is that having two firewalls of the same flavour will not buy you any more security. If a crack/exploit works on one then it will work on the other. Try replacing one of them with another OS and firewall solution. Eventually, I plan on replacing both Coyote boxes with IPtables-capable firewalls. (For statefull inspection). The choke will be Woody, I think, with SNORT, and the gateway will either be floppyfw or Devil Linux or a homebrew busybox. But they're still going to be i386 Linux. Hopefully, I can disable module support in both. If you're going in for multiple layers of firewalling (why??) then what the above says is that you shouldn't be using the same OS for each - the Linux is the same whether you change distributions around or what. You're looking at one of the BSDs as a relatively obvious choice when it's *variety* you want. Adding a third ipchains box will give you as much protection as adding a piece of wire. This is unclear. In the context of your first statement, I guess you're saying it's just as easy to break into? Hey look, I just broke the first level of firewall! Oh wow, the second one is just the same... And blow me down with a gnat's fart, but the 3rd as well? Coo that was hard. Last I checked, exploits didn't bother saying uh oh, I'm only supported on $DISTRO, they find instances of daemons with vulnerabilities, and wooie, quicker than a greased leech going through a wormhole, they're in. Where a proxy is extremely useful is being able to inspect (and correct or reject) the data it receives before it gives it to the client machine. That is you can plug a virus scanner into squid, remove active x, etc. How does it do so? By default? Or do I need to fine-tune squid.conf and danted.conf, or recompile both? If somone has access to a port running Dante or Squid, then it doesn't matter a jot whether they've gone through 1 firewall or 17 to get there, they're in your face and they're playing with a service you're providing. That's why you *must* secure the service as much as possible - set up proper ACLs preferably with username password authentication in both dante and squid, keep them both uptodate, only allow connections from inside going out, consider running both proxies within libsafe; you name it, you need to secure the services *far* more than you need to provide firewalls before you get there. Of *course* you've got to play with squid.conf and danted.conf. Wear asbestos gloves whilst reading the entirety of the config files *and* corresponding manpages, so you can set everything the way it should be. ~Tim -- http://spodzone.org.uk/
Re: webhosting
Sven Hoexter [EMAIL PROTECTED] writes: [snip] I'm still under the impression that it's quite possible to do a reasonably secure bind install. Bind9 has some nice security-related features, and a completely rewritten codebase (as opposed to bind8). I'm not sure what insecurities you'd impose upon yourself by installing it.. You forgot to mention that you can chroot bind since a 8.x release. The chroot is not the non plus ultra solution but it throws a few more stones in the way of the script kiddies. Heck, it's possible to run something listening on port 21 in a secure fashion... all it means is that you've got to be awake! Anyway it looks like the normal flamewars like sendmail vs. *your alternativ MTA here* :) Oh, definitely. Saying just use foo instead never got anyone anywhere. It's perfectly possible to run services in a secure manner - tighten Bind just like you would anything else - run in a virtual machine and/or chrooted, as a non-root user, statically linked, 53/tcp restricted to listed secondary NS boxes, use crypto sig things for updates, come back tomorrow and keep it uptodate, ... ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: webhosting
Sven Hoexter [EMAIL PROTECTED] writes: [snip] I'm still under the impression that it's quite possible to do a reasonably secure bind install. Bind9 has some nice security-related features, and a completely rewritten codebase (as opposed to bind8). I'm not sure what insecurities you'd impose upon yourself by installing it.. You forgot to mention that you can chroot bind since a 8.x release. The chroot is not the non plus ultra solution but it throws a few more stones in the way of the script kiddies. Heck, it's possible to run something listening on port 21 in a secure fashion... all it means is that you've got to be awake! Anyway it looks like the normal flamewars like sendmail vs. *your alternativ MTA here* :) Oh, definitely. Saying just use foo instead never got anyone anywhere. It's perfectly possible to run services in a secure manner - tighten Bind just like you would anything else - run in a virtual machine and/or chrooted, as a non-root user, statically linked, 53/tcp restricted to listed secondary NS boxes, use crypto sig things for updates, come back tomorrow and keep it uptodate, ... ~Tim -- http://spodzone.org.uk/
Re: root's home world readable (part 24 of 24)
Unusual System Events =-=-=-=-=-=-=-=-=-=-= Feb 1 04:58:15 sunbird uservd[19110]: call connected Feb 1 04:58:15 sunbird uservd/check[19109]: uservd[535] is running Feb 1 04:58:15 sunbird uservd[19110]: call connected Feb 1 04:58:15 sunbird uservd/check[19109]: uservd[535] is running From root Fri Feb 1 06:14:01 2002 Received: (from root@localhost) by .aimcomm.com (8.9.3/8.9.3/Debian 8.9.3-21) id GAA19224 for root; Fri, 1 Feb 2002 06:02:03 -0800 Date: Fri, 1 Feb 2002 06:02:03 -0800 From: root root Message-Id: 200202011402.GAA19224@.aimcomm.com To: root Subject: sunbird.aimcomm.com 02/01/02:06.02 system check Unusual System Events =-=-=-=-=-=-=-=-=-=-= Feb 1 05:58:15 sunbird uservd[19197]: call connected Feb 1 05:58:15 sunbird uservd/check[19196]: uservd[535] is running Feb 1 05:58:15 sunbird uservd[19197]: call connected Feb 1 05:58:15 sunbird uservd/check[19196]: uservd[535] is running From root Fri Feb 1 06:54:01 2002 Received: (from root@localhost) by .aimcomm.com (8.9.3/8.9.3/Debian 8.9.3-21) id GAA19261 for root; Fri, 1 Feb 2002 06:25:01 -0800 Date: Fri, 1 Feb 2002 06:25:01 -0800 Message-Id: 200202011425.GAA19261@.aimcomm.com From: root (Cron Daemon) To: root Subject: Cron root@sunbird root test -e /usr/sbin/anacron || run-parts --report /etc/cron.daily X-Cron-Env: SHELL=/bin/sh X-Cron-Env: PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin X-Cron-Env: HOME=/root X-Cron-Env: LOGNAME=root /bin/sh: root: command not found From root Fri Feb 1 06:54:01 2002 Received: (from root@localhost) by .aimcomm.com (8.9.3/8.9.3/Debian 8.9.3-21) id GAA19546 for root; Fri, 1 Feb 2002 06:52:02 -0800 Date: Fri, 1 Feb 2002 06:52:02 -0800 Message-Id: 200202011452.GAA19546@.aimcomm.com From: root (Cron Daemon) To: root Subject: Cron root@sunbird root test -e /usr/sbin/anacron || run-parts --report /etc/cron.monthly X-Cron-Env: SHELL=/bin/sh X-Cron-Env: PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin X-Cron-Env: HOME=/root X-Cron-Env: LOGNAME=root /bin/sh: root: command not found From root Fri Feb 1 07:14:01 2002 Received: (from root@localhost) by .aimcomm.com (8.9.3/8.9.3/Debian 8.9.3-21) id HAA19583 for root; Fri, 1 Feb 2002 07:02:04 -0800 Date: Fri, 1 Feb 2002 07:02:04 -0800 From: root root Message-Id: 200202011502.HAA19583@.aimcomm.com To: root Subject: sunbird.aimcomm.com 02/01/02:07.02 system check Unusual System Events =-=-=-=-=-=-=-=-=-=-= Feb 1 06:25:30 sunbird syslog-ng[528]: new configuration initialized Feb 1 06:52:02 sunbird anacron[19549]: Updated timestamp for job `cron.monthly' to 2002-02-01 Feb 1 06:58:15 sunbird uservd[19556]: call connected Feb 1 06:58:15 sunbird uservd/check[19555]: uservd[535] is running Feb 1 06:25:25 sunbird cracklib: updating dictionary 329055 329055 words. Feb 1 06:58:15 sunbird uservd[19556]: call connected Feb 1 06:58:15 sunbird uservd/check[19555]: uservd[535] is running From root Fri Feb 1 08:14:01 2002 Received: (from root@localhost) by .aimcomm.com (8.9.3/8.9.3/Debian 8.9.3-21) id IAA19675 for root; Fri, 1 Feb 2002 08:02:04 -0800 Date: Fri, 1 Feb 2002 08:02:04 -0800 From: root root Message-Id: 200202011602.IAA19675@.aimcomm.com To: root Subject: sunbird.aimcomm.com 02/01/02:08.02 system check Unusual System Events =-=-=-=-=-=-=-=-=-=-= Feb 1 07:30:01 sunbird anacron[19620]: Anacron 2.1 started on 2002-02-01 Feb 1 07:30:01 sunbird anacron[19620]: Normal exit (0 jobs run) Feb 1 07:58:15 sunbird uservd[19648]: call connected Feb 1 07:58:15 sunbird uservd/check[19647]: uservd[535] is running Feb 1 07:58:15 sunbird uservd[19648]: call connected Feb 1 07:58:15 sunbird uservd/check[19647]: uservd[535] is running From root Fri Feb 1 09:14:01 2002 Received: (from root@localhost) by .aimcomm.com (8.9.3/8.9.3/Debian 8.9.3-21) id JAA19762 for root; Fri, 1 Feb 2002 09:02:04 -0800 Date: Fri, 1 Feb 2002 09:02:04 -0800 From: root root Message-Id: 200202011702.JAA19762@.aimcomm.com To: root Subject: sunbird.aimcomm.com 02/01/02:09.02 system check Unusual System Events =-=-=-=-=-=-=-=-=-=-= Feb 1 08:58:15 sunbird uservd[19735]: call connected Feb 1 08:58:15 sunbird uservd/check[19734]: uservd[535] is running Feb 1 08:58:15 sunbird uservd[19735]: call connected Feb 1 08:58:15 sunbird uservd/check[19734]: uservd[535] is running From root Fri Feb 1 10:14:01 2002 Received: (from root@localhost) by .aimcomm.com (8.9.3/8.9.3/Debian 8.9.3-21) id KAA19898 for root; Fri, 1 Feb 2002 10:02:03 -0800 Date: Fri, 1 Feb 2002 10:02:03 -0800 From: root root Message-Id: 200202011802.KAA19898@.aimcomm.com To: root Subject: sunbird.aimcomm.com 02/01/02:10.02 system check Unusual System Events =-=-=-=-=-=-=-=-=-=-= Feb 1 09:58:15 sunbird uservd[19871]: call connected Feb 1 09:58:15 sunbird uservd/check[19870]: uservd[535] is running Feb 1 09:58:15 sunbird uservd[19871]: call connected Feb 1 09:58:15 sunbird uservd/check[19870]: uservd[535] is running From root Fri Feb 1 11:14:02 2002 Received: (from
Re: Port 113 (auth) accept or deny?
Brandon High [EMAIL PROTECTED] writes: should I open(accept) or close(deny, perhaps reject?) the port 113??? I've got it closed on my machines. I don't know what you might need it for. We've been through at least once, haven't we? *sigh* Obligatory link: http://logi.cc/linux/reject_or_deny.php3. I say you should close the port with a TCP RST flag unless you know otherwise. I know what port 113 is for: schitzo:~[1] grep 113 /etc/services auth113/tcp authentication tap ident I just don't know what you might need the ident server for. You use it to provide userid details to folks who want to know who's responsible for a given connection from your machine. Notably this includes mail, FTP and IRC servers. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Port 113 (auth) accept or deny?
Brandon High [EMAIL PROTECTED] writes: should I open(accept) or close(deny, perhaps reject?) the port 113??? I've got it closed on my machines. I don't know what you might need it for. We've been through at least once, haven't we? *sigh* Obligatory link: http://logi.cc/linux/reject_or_deny.php3. I say you should close the port with a TCP RST flag unless you know otherwise. I know what port 113 is for: schitzo:~[1] grep 113 /etc/services auth113/tcp authentication tap ident I just don't know what you might need the ident server for. You use it to provide userid details to folks who want to know who's responsible for a given connection from your machine. Notably this includes mail, FTP and IRC servers. ~Tim -- http://spodzone.org.uk/
Re: These 'roots' are bugging me.
Steve Mickeler [EMAIL PROTECTED] writes: Its neither a debian or linux problem. ports below 1024 are priviledged ports which can only be bound to by the super user. just like apache starts as root, but then spawns child processes as a non root user, the same thing is done with bind when started with the -u and -g options. It's a linux feature that you can get kernel patches to permit various processes / users to bind to various low ports. Otherwise, you don't need to be root, you need the relevant Capability in the kernel. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: These 'roots' are bugging me.
Steve Mickeler [EMAIL PROTECTED] writes: Its neither a debian or linux problem. ports below 1024 are priviledged ports which can only be bound to by the super user. just like apache starts as root, but then spawns child processes as a non root user, the same thing is done with bind when started with the -u and -g options. It's a linux feature that you can get kernel patches to permit various processes / users to bind to various low ports. Otherwise, you don't need to be root, you need the relevant Capability in the kernel. ~Tim -- http://spodzone.org.uk/
Re: root's home world readable
Noah L. Meyerhans [EMAIL PROTECTED] writes: I have changed /root to 0700 on all my installations because I am running mysql server. It hasn't broken anything. Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. Why do you want folks to be able to *see* that you have a .my.conf in there? Directory and file permissions work together; block r on the dir and the users won't be able to _ls_ in it. Block permissions on the file as well, and they won't be able to read it should they guess its existence. All to the good, as far as I'm concerned! ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root's home world readable
Noah L. Meyerhans [EMAIL PROTECTED] writes: On Mon, Jan 21, 2002 at 09:45:50PM +, Tim Haynes wrote: Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. Why do you want folks to be able to *see* that you have a .my.conf in there? What difference does it make? They know you have an /etc/shadow, /var/mail/$USER, ~/.bash_history, etc etc etc. 1 out of 3 ain't bad, apparently. Those don't need to be in read-protected directories. They can 'ls' them all they want, but it won't get them anywhere. This is where the per-file permissions come in. See below. Directory and file permissions work together; block r on the dir and the users won't be able to _ls_ in it. Block permissions on the file as well, and they won't be able to read it should they guess its existence. All to the good, as far as I'm concerned! Multiple layers of security are one thing, but this doesn't get you anything. Compromise one layer and you've necessarily compromised the other. What makes you think .my.conf is the *only* thing I'm going to want to keep in /root/? Permissions on the directory are not only a necessary part of protecting the contents, but a forward-looking prevention against the day you choose to store your firewall.sh in there for all to see as well. And your ipv6.sh. And... ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root's home world readable
Noah L. Meyerhans [EMAIL PROTECTED] writes: I have changed /root to 0700 on all my installations because I am running mysql server. It hasn't broken anything. Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. Why do you want folks to be able to *see* that you have a .my.conf in there? Directory and file permissions work together; block r on the dir and the users won't be able to _ls_ in it. Block permissions on the file as well, and they won't be able to read it should they guess its existence. All to the good, as far as I'm concerned! ~Tim -- http://spodzone.org.uk/
Re: root's home world readable
Noah L. Meyerhans [EMAIL PROTECTED] writes: On Mon, Jan 21, 2002 at 09:45:50PM +, Tim Haynes wrote: Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. Why do you want folks to be able to *see* that you have a .my.conf in there? What difference does it make? They know you have an /etc/shadow, /var/mail/$USER, ~/.bash_history, etc etc etc. 1 out of 3 ain't bad, apparently. Those don't need to be in read-protected directories. They can 'ls' them all they want, but it won't get them anywhere. This is where the per-file permissions come in. See below. Directory and file permissions work together; block r on the dir and the users won't be able to _ls_ in it. Block permissions on the file as well, and they won't be able to read it should they guess its existence. All to the good, as far as I'm concerned! Multiple layers of security are one thing, but this doesn't get you anything. Compromise one layer and you've necessarily compromised the other. What makes you think .my.conf is the *only* thing I'm going to want to keep in /root/? Permissions on the directory are not only a necessary part of protecting the contents, but a forward-looking prevention against the day you choose to store your firewall.sh in there for all to see as well. And your ipv6.sh. And... ~Tim -- http://spodzone.org.uk/
Re: FTP Bounce scan
Dries Kimpe [EMAIL PROTECTED] writes: Today, I saw in the snort logs the following: (removed ip date to get it in 78-col format) 193.189.224.13:21 - ip:58153 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42940 - ip:113 SYN 12S* RESERVEDBITS 193.189.224.13:42941 - ip:58154 UNKNOWN *2*A**S* RESERVEDBITS [snip] 193.189.224.13:42967 - ip:58177 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:21 - ip:58180 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:43074 - ip:113 SYN 12S* RESERVEDBITS 143.169.4.111:22 - ip:22 SYNFIN **SF 143.169.4.111:4614 - ip:22 SYN **S* Is this a so-called ftp-bounce scan? Because it starts every time with a connection from port 21, en next to a bunch of connections on higher ports. These came in bursts, each time for about one minute or so. Looks like FTP to me, full-stop. It's just that you've not sorted out your snort rules to cope with ECN yet, have you? ~Tim -- Tell me where oh where has summer gone | [EMAIL PROTECTED] It hasn't come this year| http://piglet.is.dreaming.org You always cry when swallows fly| With doubts in search of dreams | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FTP Bounce scan
Dries Kimpe [EMAIL PROTECTED] writes: Today, I saw in the snort logs the following: (removed ip date to get it in 78-col format) 193.189.224.13:21 - ip:58153 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42940 - ip:113 SYN 12S* RESERVEDBITS 193.189.224.13:42941 - ip:58154 UNKNOWN *2*A**S* RESERVEDBITS [snip] 193.189.224.13:42967 - ip:58177 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:21 - ip:58180 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:43074 - ip:113 SYN 12S* RESERVEDBITS 143.169.4.111:22 - ip:22 SYNFIN **SF 143.169.4.111:4614 - ip:22 SYN **S* Is this a so-called ftp-bounce scan? Because it starts every time with a connection from port 21, en next to a bunch of connections on higher ports. These came in bursts, each time for about one minute or so. Looks like FTP to me, full-stop. It's just that you've not sorted out your snort rules to cope with ECN yet, have you? ~Tim -- Tell me where oh where has summer gone | [EMAIL PROTECTED] It hasn't come this year| http://piglet.is.dreaming.org You always cry when swallows fly| With doubts in search of dreams |
Re: [2] Mailserver HDD organization
[EMAIL PROTECTED] writes: now i have tried postfix and exim and i like both. But wich is more secure? any body some knowledge about that? [snip] I thought both had had security-related fixes recently. Find one that you like more than the other, benchmark it yourself, test how readily you can implement all the features you want to, and just go with one or the other. And tomorrow, *stay uptodate*! ~Tim -- 19:32:12 up 73 days, 21:21, 11 users, load average: 0.24, 0.23, 0.17 [EMAIL PROTECTED] |Famous moments vanish without trace http://spodzone.org.uk/|Trees grow tall, fields grow wheat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [2] Mailserver HDD organization
[EMAIL PROTECTED] writes: now i have tried postfix and exim and i like both. But wich is more secure? any body some knowledge about that? [snip] I thought both had had security-related fixes recently. Find one that you like more than the other, benchmark it yourself, test how readily you can implement all the features you want to, and just go with one or the other. And tomorrow, *stay uptodate*! ~Tim -- 19:32:12 up 73 days, 21:21, 11 users, load average: 0.24, 0.23, 0.17 [EMAIL PROTECTED] |Famous moments vanish without trace http://spodzone.org.uk/|Trees grow tall, fields grow wheat
Re: default security
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) | Regarding limiting BIND's privileges you must be aware that if a | non-root user runs BIND, then BIND cannot detect new interfaces | automatically. For example, if you stick a PCMCIA card into your laptop. Like anyone would really want to run bind automatically on all transient interfaces... It's a *service*, to be run on *serv-ers*! If you want a named listening on such an interface, the due pain is deserved, IMHO. (I've been meaning to get that off my chest for a few months :8) The above URL links to a bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no\bug=50013, which seems to imply that chroot()ed behaviour will be expected ere long. Have I missed it, or shall I carry on hoping? :) [snip] ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
Tarjei [EMAIL PROTECTED] writes: Hmm. Here's a suggestion. - This idea is based on the asumtion that espesially serversystems need good security. *All* installed boxes need adequate securing. Linux worms would not propagate if it weren't for a critical mass of idiots running unpatched daemons packages; scanning by IP# is no respector of `this is a server' or `this is a workstation'; it just happens that servers *have* to be secure while workstations tend not to be. 1. Make a votingpage and anounce it on debian-users asking what are the main servers people are running on their debian systems. You'd want a control poll e.g. on slashdot or somewhere as well because the Internet as a whole will run different servers in different amounts - more web servers than DNS than email? Or similar numbers of each? 2. Go through the 10 highest and make sure they follow secure practies like libsafe. Personally I think a BIG disclaimer in the installer, `look, if you will run these things, on your head be it' for every daemon that gets installed would be in order. [snip] I apoligize to all the people reading this list for filling it with rants. Will stop now. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
Colin Phipps [EMAIL PROTECTED] writes: On Wed, Jan 16, 2002 at 01:42:50AM +1300, Adam Warner wrote: ...it took the Debian Security Team an average of 35 days to fix security-related vulnerabilites. An average based upon a very long tail is highly misleading. Please quote the median time to fix a vulnerability instead. It is not misleading in this case, the tail is the _most_ important part of the data. It doesn't matter if we patch every other hole in 10 minutes if we leave one open for months. Yes it does, if that remaining hole is merely a local non-root potential vulnerability with no known exploit that's a PITA to fix - you *must* weight the average accordingly. Much as I hate stats, I can see that what you want to measure is how much lethargy there is in Debian, which means excluding other influences, and instead of wondering about means modes and medians, you've got to weight the whole thing. Bah, complicated. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Deb-SEC]oddball ssh remote passwd question
David Ehle [EMAIL PROTECTED] writes: Hello all, if you do: ssh [EMAIL PROTECTED] password What is `password'? ssh will have you authenticate to host, and then bring up the password change prompt (current) UNIX password: on the remote machine. BUT when you start typing, the characters show up on screen- not hashed or unprinted. What is it that is striping this functionality from passwd? Failing finding a way to get ssh to not express these characters, I could swear there is a simple way of turning off echoing input to the screen, but for the life of me I can't remember the command or variable in bash. ssh(1): | -t Force pseudo-tty allocation. This can be used to execute arbi | trary screen-based programs on a remote machine, which can be | very useful, e.g., when implementing menu services. Multiple | -t options force tty allocation, even if ssh has no local tty. That any use? ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udp 32768
Jeff Teitel [EMAIL PROTECTED] writes: When I do a 'netstat -l' I get (among a bunch of stuff that looks OK): mail:# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign AddressState udp0 0 *:32768 *:* What is this, and should I be worried? You tell us. netstat(8): | -p, --program | Show the PID and name of the program to which each socket | belongs. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: default security
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: On Tue, Jan 15, 2002 at 10:21:00AM +0100, Tarjei wrote: I recall there being discussion a while back about packaging chroot bind. I don't know whether or not anything came of it at all. There is Debian being what it is, are there any reasons why the debian bind package should not be chroot as the default instalation? RTFM. That is: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-sec-bind :) | Regarding limiting BIND's privileges you must be aware that if a | non-root user runs BIND, then BIND cannot detect new interfaces | automatically. For example, if you stick a PCMCIA card into your laptop. Like anyone would really want to run bind automatically on all transient interfaces... It's a *service*, to be run on *serv-ers*! If you want a named listening on such an interface, the due pain is deserved, IMHO. (I've been meaning to get that off my chest for a few months :8) The above URL links to a bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no\bug=50013, which seems to imply that chroot()ed behaviour will be expected ere long. Have I missed it, or shall I carry on hoping? :) [snip] ~Tim -- http://spodzone.org.uk/
Re: default security
Tarjei [EMAIL PROTECTED] writes: Hmm. Here's a suggestion. - This idea is based on the asumtion that espesially serversystems need good security. *All* installed boxes need adequate securing. Linux worms would not propagate if it weren't for a critical mass of idiots running unpatched daemons packages; scanning by IP# is no respector of `this is a server' or `this is a workstation'; it just happens that servers *have* to be secure while workstations tend not to be. 1. Make a votingpage and anounce it on debian-users asking what are the main servers people are running on their debian systems. You'd want a control poll e.g. on slashdot or somewhere as well because the Internet as a whole will run different servers in different amounts - more web servers than DNS than email? Or similar numbers of each? 2. Go through the 10 highest and make sure they follow secure practies like libsafe. Personally I think a BIG disclaimer in the installer, `look, if you will run these things, on your head be it' for every daemon that gets installed would be in order. [snip] I apoligize to all the people reading this list for filling it with rants. Will stop now. ~Tim -- http://spodzone.org.uk/
Re: Debian security being trashed in Linux Today comments
Colin Phipps [EMAIL PROTECTED] writes: On Wed, Jan 16, 2002 at 01:42:50AM +1300, Adam Warner wrote: ...it took the Debian Security Team an average of 35 days to fix security-related vulnerabilites. An average based upon a very long tail is highly misleading. Please quote the median time to fix a vulnerability instead. It is not misleading in this case, the tail is the _most_ important part of the data. It doesn't matter if we patch every other hole in 10 minutes if we leave one open for months. Yes it does, if that remaining hole is merely a local non-root potential vulnerability with no known exploit that's a PITA to fix - you *must* weight the average accordingly. Much as I hate stats, I can see that what you want to measure is how much lethargy there is in Debian, which means excluding other influences, and instead of wondering about means modes and medians, you've got to weight the whole thing. Bah, complicated. ~Tim -- http://spodzone.org.uk/
Re: udp 32768
Jeff Teitel [EMAIL PROTECTED] writes: When I do a 'netstat -l' I get (among a bunch of stuff that looks OK): mail:# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign AddressState udp0 0 *:32768 *:* What is this, and should I be worried? You tell us. netstat(8): | -p, --program | Show the PID and name of the program to which each socket | belongs. ~Tim -- http://spodzone.org.uk/
Re: Debian security being trashed in Linux Today comments
Adam Warner [EMAIL PROTECTED] writes: http://www.linuxtoday.com/news_story.php3?ltsn=2002-01-14-002-20-SC-DB Someone with better knowledge of all the facts might want to comment on the claim that Debian is always the last to fix security holes and the tag team follow up I've been fighting for months now to try to convince them to release an advisory or fix for ftpd... Some of us wouldn't dare say such things without at least reviewing the given distro's security policy, FAQ and history. http://www.debian.org/security/ is over there --- . ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Don't panic (ssh)
Craigsc [EMAIL PROTECTED] writes: How do you disable ssh1 protocol with the current ssh on potato ? I don't think you have to. See http://www.debian.org/security/2001/dsa-086. Or have I really been so asleep as not to notice a major thou shalt not use ssh1 even though we applied all the fixes AS PER FAQ to the old version alert??? That might be commendable behaviour, but it hasn't been mandated by Debian that I saw. ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
Noah L. Meyerhans [EMAIL PROTECTED] writes: On Mon, Jan 14, 2002 at 01:37:50PM +, Simon Huggins wrote: So perhaps Debian security is only as good as the package maintainers? I'm sure most maintainers do care and do investigate bugs I probably just had a bad experience. That is the case in unstable and testing, but not stable. That is why you're encouraged to run stable on any machine connected to the internet. In its case, there is a group within Debian who is responsible for providing security updates in a timely manner with or without assistance from the package maintainer. Agreed. You have to decide for the situation at hand; as it happens, my favourite colo swerver runs Testing, on the grounds that one of these days, Stable will change en-masse and the last thing I want is for ssh not to restart in my daily dist-upgrades of nearly every package on the box - the machine came home for a bit of TLC one time and got put onto Testing so the daily dist-upgrade only does a few packages rather than the whole lot. In the meantime, security patches (notably only _mutt_ anyway) can come down from Unstable. Cheers, ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
Adam Warner [EMAIL PROTECTED] writes: http://www.linuxtoday.com/news_story.php3?ltsn=2002-01-14-002-20-SC-DB Someone with better knowledge of all the facts might want to comment on the claim that Debian is always the last to fix security holes and the tag team follow up I've been fighting for months now to try to convince them to release an advisory or fix for ftpd... Some of us wouldn't dare say such things without at least reviewing the given distro's security policy, FAQ and history. http://www.debian.org/security/ is over there --- . ~Tim -- http://spodzone.org.uk/
Re: Don't panic (ssh)
Craigsc [EMAIL PROTECTED] writes: How do you disable ssh1 protocol with the current ssh on potato ? I don't think you have to. See http://www.debian.org/security/2001/dsa-086. Or have I really been so asleep as not to notice a major thou shalt not use ssh1 even though we applied all the fixes AS PER FAQ to the old version alert??? That might be commendable behaviour, but it hasn't been mandated by Debian that I saw. ~Tim -- http://spodzone.org.uk/
Re: Debian security being trashed in Linux Today comments
Noah L. Meyerhans [EMAIL PROTECTED] writes: On Mon, Jan 14, 2002 at 01:37:50PM +, Simon Huggins wrote: So perhaps Debian security is only as good as the package maintainers? I'm sure most maintainers do care and do investigate bugs I probably just had a bad experience. That is the case in unstable and testing, but not stable. That is why you're encouraged to run stable on any machine connected to the internet. In its case, there is a group within Debian who is responsible for providing security updates in a timely manner with or without assistance from the package maintainer. Agreed. You have to decide for the situation at hand; as it happens, my favourite colo swerver runs Testing, on the grounds that one of these days, Stable will change en-masse and the last thing I want is for ssh not to restart in my daily dist-upgrades of nearly every package on the box - the machine came home for a bit of TLC one time and got put onto Testing so the daily dist-upgrade only does a few packages rather than the whole lot. In the meantime, security patches (notably only _mutt_ anyway) can come down from Unstable. Cheers, ~Tim -- http://spodzone.org.uk/
Re: Exim mail
[EMAIL PROTECTED] (Brian P. Flaherty) writes:
Josh [EMAIL PROTECTED] writes:
hmmm, im a bit of a newbie here, but how do you bind a
daemon, eg telnetd to a certain nic?
Try running xinetd, if you aren't already. In each service block, you can
use the 'bind' option, which ties the service to a NIC's IP address.
Someone please correct me if I am wrong, but I think this effectively
keeps the service from listening on other interfaces.
'Tis correct.
Example (for those who like using _sn_ as a news transport):
service nntp
{
socket_type = stream
protocol= tcp
wait= no
user= news
group = news
server = /usr/bin/env
server_args = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
/usr/sbin/snntpd logger -p news.info
bind= 127.0.0.1
}
However, you can also do exactly the same thing in exim.conf itself -
OTTOMH the directive is `local_interfaces', BICBW.
~Tim
--
Not every discomfort should |[EMAIL PROTECTED]
be criminalised. (Bill Unruh) |http://spodzone.org.uk/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Exim mail
[EMAIL PROTECTED] (Brian P. Flaherty) writes:
Josh [EMAIL PROTECTED] writes:
hmmm, im a bit of a newbie here, but how do you bind a
daemon, eg telnetd to a certain nic?
Try running xinetd, if you aren't already. In each service block, you can
use the 'bind' option, which ties the service to a NIC's IP address.
Someone please correct me if I am wrong, but I think this effectively
keeps the service from listening on other interfaces.
'Tis correct.
Example (for those who like using _sn_ as a news transport):
service nntp
{
socket_type = stream
protocol= tcp
wait= no
user= news
group = news
server = /usr/bin/env
server_args = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
/usr/sbin/snntpd logger -p news.info
bind= 127.0.0.1
}
However, you can also do exactly the same thing in exim.conf itself -
OTTOMH the directive is `local_interfaces', BICBW.
~Tim
--
Not every discomfort should |[EMAIL PROTECTED]
be criminalised. (Bill Unruh) |http://spodzone.org.uk/
Re: Fw: Can a daemon listen only on some interfaces?
Plato [EMAIL PROTECTED] writes: echo 1 /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. rp_filter will not help with that. I thought that rp_filter was for precisely this. Doesn't it stop packets which appear on interfaces with invalid IP addresses for that interface from getting through? It's a return-path filter; if flipping the src/dest IP#s wouldn't send it back out the same interface, it doesn't come in at all. So a specially routed packet from a.b.c.d - 127.0.0.1 coming in on eth0 becomes a packet from 127.0.0.1 - a.b.c.d going back out That certainly looks wrong to me, although I'm not /sure/ it would produce the required interface conflict for rp_filter. ~Tim -- We're just souls across a |[EMAIL PROTECTED] shrinking world |http://spodzone.org.uk/ In a distant starlit night | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
Guido Hennecke [EMAIL PROTECTED] writes: Sorry, I was transposing my thoughts into ipchains rules. Actually my firewall is iptables based. In iptables, packets that are being masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT chains. Thus if the rule was: iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP this should be OK I guess. Since packets on the INPUT are destined only to localhost. Pakets came from the externel interface from a ip address from this externel network will be masqeraded? I think the will not! I've got a problem with this, btw. Increasingly, I'm needing FORWARDING rules on various sites; what I want to know is, when I've got the following layout: | #Chain for incoming/forwarding filtering | iptables -N block | #chain to drop log stuff | iptables -N DLOG | ... | several `block' rules incl stateful allowing ESTABLISHED,RELATED | ... | ## Jump to that chain from INPUT and FORWARD chains. | iptables -A INPUT -j block | iptables -A FORWARD -j block how come packets still seem to get dropped when being forwarded between interfaces? (If this isn't the place for this question, point me at a *decent* bit of documentation by all means! (With emphasis on `decent', as in something that explains and details simultaneously.)) ~Tim -- 12:51:17 up 33 days, 14:46, 17 users, load average: 0.15, 0.18, 0.17 [EMAIL PROTECTED] |And your radiance shines http://piglet.is.dreaming.org |Like the moon of all innocent grace -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
Plato [EMAIL PROTECTED] writes: echo 1 /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. rp_filter will not help with that. I thought that rp_filter was for precisely this. Doesn't it stop packets which appear on interfaces with invalid IP addresses for that interface from getting through? It's a return-path filter; if flipping the src/dest IP#s wouldn't send it back out the same interface, it doesn't come in at all. So a specially routed packet from a.b.c.d - 127.0.0.1 coming in on eth0 becomes a packet from 127.0.0.1 - a.b.c.d going back out That certainly looks wrong to me, although I'm not /sure/ it would produce the required interface conflict for rp_filter. ~Tim -- We're just souls across a |[EMAIL PROTECTED] shrinking world |http://spodzone.org.uk/ In a distant starlit night |
Re: Fw: Can a daemon listen only on some interfaces?
Guido Hennecke [EMAIL PROTECTED] writes: Sorry, I was transposing my thoughts into ipchains rules. Actually my firewall is iptables based. In iptables, packets that are being masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT chains. Thus if the rule was: iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP this should be OK I guess. Since packets on the INPUT are destined only to localhost. Pakets came from the externel interface from a ip address from this externel network will be masqeraded? I think the will not! I've got a problem with this, btw. Increasingly, I'm needing FORWARDING rules on various sites; what I want to know is, when I've got the following layout: | #Chain for incoming/forwarding filtering | iptables -N block | #chain to drop log stuff | iptables -N DLOG | ... | several `block' rules incl stateful allowing ESTABLISHED,RELATED | ... | ## Jump to that chain from INPUT and FORWARD chains. | iptables -A INPUT -j block | iptables -A FORWARD -j block how come packets still seem to get dropped when being forwarded between interfaces? (If this isn't the place for this question, point me at a *decent* bit of documentation by all means! (With emphasis on `decent', as in something that explains and details simultaneously.)) ~Tim -- 12:51:17 up 33 days, 14:46, 17 users, load average: 0.15, 0.18, 0.17 [EMAIL PROTECTED] |And your radiance shines http://piglet.is.dreaming.org |Like the moon of all innocent grace
Re: Fw: Can a daemon listen only on some interfaces?
mdevin [EMAIL PROTECTED] writes: [snip firewall overview] how come packets still seem to get dropped when being forwarded between interfaces? I am not sure I have totall gotten what you are trying to do here. But, the packets will be dropped instead of being forwarded between interfaces because that is exactly what you have specified in your rules. What happens is this: 1. A packet comes in through one of your interfaces. 2. It hits the PREROUTING chain - where DNAT can occur or any tracked connections are de-SNATted or de-MASQUERADED. 3. Routing decision is made. Here is where the decision is made whether the packet is destined for localhost or to go out another interface. 4a. If the packet is destined for localhost then it traverses the INPUT chain. 4b. If the packet is for another host then it traverses the FORWARD chain. Righty. That's much as I expected. Thus what your rules will do is: Any packet not destined for localhost will traverse the FORWARD chain and will be -j (jumpped) to your block (user defined) chain. This will presumably LOG and the DROP the packets. Thus all your FORWARDED packets will be DROPPED. Ultimately, I want input forward to be drop-by-default. However, the `block' chain is meant to be good for both input forward scenarios; it has rules for stateful filtering and `open' things, then a drop log. If I put in a rule matching -i and/or -o as appropriate, it still doesn't seem to work. Maybe I've done something wrong (and I don't really want to post ork's firewall in any more detail). This is of course only if you don't have other rules in your FORWARD chain which explicitly ACCEPT the packets before they hit the FORWARD chain rule you have written above. What about if I kick *all* packets from forward onto `block', though? That's the bit I'm not wholly happy about. ~Tim -- A spark of life |[EMAIL PROTECTED] On a wire from heaven |http://spodzone.org.uk/
Re: Fw: Can a daemon listen only on some interfaces?
Phillip Hofmeister [EMAIL PROTECTED] writes: [snip] If an attacker in the same network sets a route like that: 127.0.0.1 Gateway your official ip address Interface his externel interface Couldn't this be countered with: ipchains -i !lo -d 127.0.0.1 -j DENY ? Better, iptables -A INPUT -m state --state INVALID -j LOG iptables -A INPUT -m state --state INVALID -j DROP (and OUTPUT as well, for those paranoid enough to do egress filtering). Also, echo 1 /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. ~Tim -- Another day,|[EMAIL PROTECTED] Another kernel recompile|http://spodzone.org.uk/
Re: Rãspuns: finding hidden processes
Tarjei Huse [EMAIL PROTECTED] writes upside-down: Thanks, I got: dev_to_tty tdev /dev/pts/%s /dev/%s /dev/tty%s /dev/pty%s /dev/%snsole Obsolete W option not supported. (You have a /dev/drum?) [snip] Identical to the same for /bin/ps on woody. I'd also include looking for `lib' as well, myself: |/lib/ld-linux.so.2 |libproc.so.2.0.7 |libc.so.6 |__libc_start_main |Compiled with: libc %d, internal version %d.%d |libc assumed lame, using fprintf to emulate fputs. |vm_lib |pid,tname,majflt,minflt,m_trs,m_drs,m_size,m_swap,rss,m_share,vm_lib,m_dt,args ~Tim -- 21:08:45 up 26 days, 23:04, 13 users, load average: 0.30, 0.23, 0.17 [EMAIL PROTECTED] |April comes to the new grass http://piglet.is.dreaming.org |On the hills of gold -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rãspuns: finding hidden processes
Tarjei Huse [EMAIL PROTECTED] writes upside-down: Thanks, I got: dev_to_tty tdev /dev/pts/%s /dev/%s /dev/tty%s /dev/pty%s /dev/%snsole Obsolete W option not supported. (You have a /dev/drum?) [snip] Identical to the same for /bin/ps on woody. I'd also include looking for `lib' as well, myself: |/lib/ld-linux.so.2 |libproc.so.2.0.7 |libc.so.6 |__libc_start_main |Compiled with: libc %d, internal version %d.%d |libc assumed lame, using fprintf to emulate fputs. |vm_lib |pid,tname,majflt,minflt,m_trs,m_drs,m_size,m_swap,rss,m_share,vm_lib,m_dt,args ~Tim -- 21:08:45 up 26 days, 23:04, 13 users, load average: 0.30, 0.23, 0.17 [EMAIL PROTECTED] |April comes to the new grass http://piglet.is.dreaming.org |On the hills of gold
Re: What this means in my logs?
Petre Daniel [EMAIL PROTECTED] writes: Heya,i got those lines often lately..Can anyone explain me every little part of it? If you can drop an url link too,it would be great.. Thank you. Nov 30 16:16:28 brutus-gw kernel: Packet log: input DENY eth1 PROTO=6 210.86.20.213:1621 194.102.92.21:6000 L=48 S=0x00 I=52039 F=0x4000 T=102 SYN (#1) Paste it into the ipchains analyser at http://logi.cc/; that'll tell you about every word in detail. ~Tim -- Clouds cross the black moonlight, |[EMAIL PROTECTED] Rushing on down to the sound|http://spodzone.org.uk/ of a turning world | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What this means in my logs?
Petre Daniel [EMAIL PROTECTED] writes: Heya,i got those lines often lately..Can anyone explain me every little part of it? If you can drop an url link too,it would be great.. Thank you. Nov 30 16:16:28 brutus-gw kernel: Packet log: input DENY eth1 PROTO=6 210.86.20.213:1621 194.102.92.21:6000 L=48 S=0x00 I=52039 F=0x4000 T=102 SYN (#1) Paste it into the ipchains analyser at http://logi.cc/; that'll tell you about every word in detail. ~Tim -- Clouds cross the black moonlight, |[EMAIL PROTECTED] Rushing on down to the sound|http://spodzone.org.uk/ of a turning world |
