November 2001 - openSUSE Security - openSUSE Mailing Lists

SuSEfirwall | snort & portforwarding
by die schildkroete 06 Nov '01

06 Nov '01

Hi list! We are using SuSE packetfilter for our firewall. I'm planning to forward some ports to another machine, so my question is does the "packetfilter" protect the other machine on these ports or do I have to run another packetfilter on the forwarded ports? Is it the same problem within snort, so port forwarding is in a "higher priority" than any sniffer or filter in linux ... thank you, turtle

1 0

Re: [suse-security-announce] SuSE Security Announcement: kernel (update) (SuSE-SA:2001:039)
by Martin Köhling 06 Nov '01

06 Nov '01

Hi! On Fri, 2 Nov 2001, Roman Drahtmueller wrote: > * The attacker must be able to connect to at least one open > (unfiltered) tcp port. Does this apply only to incoming connections, or to outgoing connects, too? (Yes I know, the wording implies the former...) In other words: am I safe (from external attacks) if the box offers no services to the Internet, but just to the intranet? And: does "able to connect" include connects that are immediately broken because of hosts.deny rules? Or does an attack require a more "permanent" connection? Bye, Martin

2 1

AW: [suse-security] [Flame] A Disservice to the Linux Community
by Bitzer,Gerd 06 Nov '01

06 Nov '01

Very interesting debate, it's the first time I'm noticing that opensource devoted people agree with the meaning of Microsoft: http://www.heise.de/newsticker/data/lab-18.10.01-000/ -----Ursprüngliche Nachricht----- Von: Ken Schneider [mailto:kschneider@rtsx.com] Gesendet am: Montag, 5. November 2001 14:38 An: suse-security(a)suse.com Betreff: Re: [suse-security] [Flame] A Disservice to the Linux Community > > <flame> > You sir are an idiot. > > What we are talking about here is a pretty major bug in the Linux kernel. > Linux is now a mainstream product that is used comercially in many major organisations. > SuSE have done the responsible thing by giving the other comercial distributions a limited window in which to bring their distros up to date. > If YOU were a programmer/exploit developer and had found this bug yourself, you would be free to release this information to the general public first without giving the linux developers time to develop a fix. As it is, from a google search I can find no useful contribution from you regarding anything, not even help to someone else on a mailing list. > > Please go back into your corner, sit down and shut up. > > Feel free to speak again when you have something productive to offer > </flame> > > Not enought coffee today ... > Bravo, bravo. This guy does need to sit in a corner! I feel you took the correct route by NOT announcing a major kernel bug to people that could exploit it BEFORE having a fix available, including any competitors having a fix or knowledge. -- Ken Schneider Senior UNIX Administrator Network Administrator -- To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com For additional commands, e-mail: suse-security-help(a)suse.com

7 7

Re: [suse-security] Information on rootkit
by Frank Heimann 05 Nov '01

05 Nov '01

On Thu, Nov 01, 2001 at 05:33:10PM +0100, Sven Michels wrote: > Hi there, > Hi, > i've a old suse box (6.2) which is hacked and rootkitt'ed. > the rootkit seams to be a littlebit shitty .. but has > a backdoor etc.. i dunno the name of it and found only > warnings about the kit while searching the net. if somebody > of you have/found more informations about this kit, would > be nice to hear from you :) > All informations i have is: > it creates a directory: /usr/bin/duarawkz > has a udp backdoor and uses scripts to hide himself. during the last few weeks i noticed threads about this rootkit on serveral mailinglists. The rootkit consists of some major parts: * modified applications to hide their running programms, ls,ps - the original ls and ps were moved to /usr/bin/duarawkz and were replaced by wrapper apps - these read the (p|l)s.hidden files in /usr/bin/duarawkz which list the data, that will be hidden by the modified apps - the original ls and ps were copied to /usr/bin/duarawkz * 2 backdoors, dua.udp and a modified login - /bin/login was replaced by a backdoored version which is a wrapper app as well - the backdoored login allows to login without asking for a password, the backdoor looks for the DISPLAY environment variable in which the password has to be saved before logging in, the password to be saved in DISPLAY is saved in /usr/bin/duarawkz/loginpass - the original login was copied to /usr/bin/duarawkz - the dua.udp backdoor binds a shell to port 33991/udp, a simple "echo ls | nc -u <host> 33991" will work depending on what OS you use, nc might be called netcat * eggdrop irc bot - an ircbot runs out of /usr/bin/duarawkz/leaf - its a modified eggdrop bot calling itself "eggdrop v1.4.2+CbS v1.3" - a tcl-script is loaded on bot-startup - the channel-, user and configuration-files as well as the tcl script are encrypted, the logfiles are not encrypted, but don't help any - the scriptkiddies seemed to be pretty dumb, they left the toolkit that builds the configuration file and encrypts it on the box, hence i reverse-engineered it, you can find my work at: http://www.unixisnot4dummies.org in the projects section - with my tool you can decrypt the configuration-, the channel-file and the tcl-script - a lil' ircsniffer helped my finding them and logging some days of their conversation and channel takeovers on ircnet * further hacking tools - in /usr/bin/duarawkz/sploits are 3 exploits, dua.(amd|bnc|pop2) - in /usr/bin/duarawkz/\ / are some pretty interesting things: = 2 encrypted and password protected apps, i assume them to be exploits as well = an ssh exploit, its saying to work for: + 0: linux/x86 ssh.com 1.2.26-1.2.31 rhl + 1: linux/x86 openssh 1.2.3 (maybe others) + 2: linux/x86 openssh 2.2.0p1 (maybe others) + 3: freebsd 4.x, ssh.com 1.2.26-1.2.31 rhl NOTE: Be VERY carefully with this app, its infected by the RemoteShellTrojan (RST) - in /usr/bin/duarawkz/.../ is a fake-identd that helps the kiddies on irc - /usr/bin/duarawkz/dua.strobe is a portscanner - /usr/bin/duarawkz/dua.synscan is a clone of the well known synscan - /usr/bin/duarawkz/dua.mf is a mirkforce binary, used to gather as many ips on its current subnet as possible and use them for irc-clients - /usr/bin/duarawkz/dua.ethclean hides the interface aliases produced by dua.mf - /usr/bin/duarawkz/dua.glox is a cancerserver, pretty annoying thingy I hope this informations and my tool helps someone out there. Being hacked CAN be so much fun. ;-) Bye, Frank -- -- -- | "The price of freedom is eternal vigilance." | | -- Thomas Jefferson | | ------------------------------------------------------------- | |"If we want to avoid zombies, we have to wait for our children"| | -- W. Richard Stevens, | | in "Advanced Programming in the UNIX Environment", p. 281 | -- -- My public key is available at http://www.unixisnot4dummies.org/homy.pgp

1 0

been attacked ?
by ulschn＠home 05 Nov '01

05 Nov '01

Hi ! i let my system on overnight to download a huge package. This morning something strange happened and ended in a reboot. Has this been an attack? No suspicios root logins detected (all from me) ... Greetings Uli /var/log/messages Nov 4 07:18:46 panama isdnlog: Nov 04 07:18:46 tei 71 calling +49 xxxxxx, Berlin with +49 xxxxx, Nürnberg 423.CI 25.380 DM (after 7:02:00) ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@Nov 4 07:35:50 panama syslogd 1.3-3: restart. Nov 4 07:35:53 panama named[490]: starting. named 8.2.3-T5B Sat Jul 29 13:24:30 GMT 2000 ^Iroot@Egal:/usr/src/packages/BUILD/bind8-8.2.3/bin/named Nov 4 07:35:53 panama named[490]: hint zone "" (IN) loaded (serial 0) Nov 4 07:35:53 panama named[490]: master zone "localhost" (IN) loaded (serial 42) /var/log/firewall Nov 4 05:34:18 panama kernel: Packet log: input DENY ippp0 PROTO=6 4.61.240.9:3564 213.61.198.161:25 L=48 S=0x00 I=38526 F=0x4000 T=110 SYN (#27) Nov 4 05:34:21 panama kernel: Packet log: input DENY ippp0 PROTO=6 4.61.240.9:3564 213.61.198.161:25 L=48 S=0x00 I=38598 F=0x4000 T=110 SYN (#27) Nov 4 07:35:53 panama kernel: klogd 1.3-3, log source = /proc/kmsg started. Nov 4 07:35:53 panama kernel: Inspecting /boot/System.map-2.2.16 Nov 4 07:35:53 panama kernel: Loaded 9060 symbols from /boot/System.map-2.2.16. Nov 4 07:35:53 panama kernel: Symbols match kernel version 2.2.16. Nov 4 07:35:53 panama kernel: Loaded 111 symbols from 17 modules. Nov 4 07:35:53 panama kernel: CSLIP: code copyright 1989 Regents of the University of California

3 2

[Flame] A Disservice to the Linux Community
by Keith Hopkins 05 Nov '01

05 Nov '01

Greetings to those at linuxsecurity.com, In regards to http://www.linuxsecurity.com/advisories/suse_advisory-1680.html, there is a note that read.... <<QUOTE>> The information about this problem was withheld from the public in coordination with other Linux vendors/distributors in order to give the distributors enough time to update their kernel packages. We find that this coordination is beneficial for the community, while we regret that the bug could not be fixed in time before the other distributor's kernel updates. <<ENDQUOTE>> How dare you. I consider this to be a great disservice to the Linux community. Linux is not about the vendors/distributors. They are not the only ones out there with interests in security problems being fixed. By withholding information, you take away untold number of eyes that could be looking at the problem. Some of those eyes may even be better equipped to handle the problems than the vendors/distributors themselves, and can do so in a more timely fashion. You have produced an unnecessary window of opportunity for malicious attacks against unprotected systems. I do not believe the Linux community needs support from, or should support, those who would withhold valuable information from them. Please do not repeat this type of attitude and behavior. Regards, Keith Hopkins P.S. To all those reading this on a mailing list, I urge you to respond directly to info(a)linuxsecurity.com with your opinion.

9 10

Re: [suse-security] martian source message
by Alex Levit 05 Nov '01

05 Nov '01

If this annoys you. You can turn off martian source logging. Open /sbin/SuSEfirewall2 in editor, search for martian and you should see the following line: echo 1 > $i/log_martians 2> /dev/null Change 1 to 0 save and restart your firewall. /etc/rc.d/SuSEfirewall2_final reload It will not log martians anymore. :) The following message was sent by "Marios Marti" <mchu6mm3(a)hotmail.com> on Tue, 30 Oct 2001 16:35:39 +0000. > Hi all > i got the following messages in the message file and was wondering what it > really means? > > nobrain kernel:martian source 0100007f for ffffffff, dev eth0 > nobrain kernel:ll header ff ff ff ff ff ff 00 d0 59 2e 3b 65 08 00 > > Thanks > > Marios > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > -- > To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com > For additional commands, e-mail: suse-security-help(a)suse.com >

1 0

harden_suse script in 7.3?
by X-SoCiaL 03 Nov '01

03 Nov '01

Sorry for the repost but I really need some help here...

1 0

Weird Problem with SuSEfirewall (FW_LOG_ACCEPT_ALL)
by Matthias Rahn 03 Nov '01

03 Nov '01

Hi everybody, I got a weird problem here and would like to hear the opinion of other security-minded people, regarding this effect. First, excuse my bad english, i hope you will be able to understand anyway. This is (part of) my current (strictly private) setup: INTERNET | --------------- | Masq-Router | --------------- | ------------- --------- |-----| FTP-Server | | Sniffer |--| | 192.168.1.5 | --------- | ------------- -------- | Router | -------- | ------------------ | FTP + NFS-Server | | 192.168.2.3 | ------------------ The masq-router (Kernel 2.2.19 - SuSEfirewall 4.6) is configured to forward FTP-connections to the outer FTP with the following rule: FW_FORWARD_MASQ_TCP="0/0,192.168.1.5,21" The outer FTPs public FTP directory is mounted ro from the inner FTP/NFS, this is done like this: On the inner NFS: #/etc/exports /usr/local/ftp/pub 192.168.1.5(ro,insecure,all_squash) On the outer FTP: # mount -t nfs 192.168.2.3:/usr/local/ftp/pub /usr/local/ftp/pub I tried to connect to the FTP from an internet-client, login to the FTP seemed to work, directory listings seemed to work, but when i tried to get a file sized 1MB, the transmission startet (always with about 4kb/s - min 7kb should be possible), but then the transmission seemed to get slower and slower until it stand still. For further investigation, i set the variable FW_LOG_ACCEPT_ALL to "yes" and made another attempt, to see whats going wrong. But then, surprise, surprise, the transmission startet with correct speed at 7kb/s, and the file was transmitted nearly perfect. I verified this behaviour many times, it definitely depends on the changed logging parameter. I made a ipchains -L -n > with_logging ipchains -L -n > without_logging diff with_logging without_logging but the result seemed to be ok, only difference - as expected - where the differing ----l- flags. But I know, if the system is compromised by a LKM/rootkit, i can´t rely on that data anyway. To take a closer look on whats going on, i put a sniffer in the choke-net to work out what´s happening there. To my surprise, the error didn´t occur on the FTP-Client to FTP connection, instead the inner NFS to outer FTP connection seems to be faulty. Here´s what happens (NFS-specific) with logging: 192.168.1.5.2344796719 > 192.168.2.3.2049: 108 getattr fh Unknown/1 (DF) (ttl 64, id 0) 192.168.2.3.2049 > 192.168.1.5.2344796719: reply ok 96 getattr REG 100644 ids 0/0 sz 1232295 (ttl 63, id 31871) 192.168.1.5.2361573935 > 192.168.2.3.2049: 108 getattr fh Unknown/1 (DF) (ttl 64, id 0) 192.168.2.3.2049 > 192.168.1.5.2361573935: reply ok 96 getattr REG 100644 ids 0/0 sz 1232295 (ttl 63, id 31873) No probs, after this NFS-packets, FTP-transmission is nearly perfect. Now here´s what happens, when FW_LOG_ACCEPT_ALL is set to "no": First 4 packets are same as above, then errors occur: 192.168.1.5.918733359 > 192.168.2.3.2049: 124 lookup fh Unknown/1 [|nfs] (DF) (ttl 64, id 0) 192.168.2.3.2049 > 192.168.1.5.918733359: reply ok 28 lookup ERROR: No such file or directory (ttl 63, id 31781) After this, the FTP-transmission seems to get "confused" (sorry, don´t know better - yet) and stucks completely (i can send the logs of both transmissions, if wanted) I don´t get it. How can a logging-parameter on the masq-router take influence to the NFS-FTP-transmission? My first idea would be something like a LKM/rootkit, that came over my network in code-red-style (I´m a lazy patcher, my beginners-config isn´t secure anyway, i guess - but as this is my private net, i dont bother to much ;). This maybe could somehow make the net work properly if extensive logging is enabled - could this be possible, or am i way to paranoid? Or could there be some sort of misconfiguration, that could lead to the weird effect described above, i wouldn´t know, where to search... :o\ So, maybe someone here knows about those symptoms and can help me out a bit. TIA, Matthias

1 0

keeping files secure from prying eyes ???
by jfweber＠eternal.net 03 Nov '01

03 Nov '01

**** imagine; all of everything that is or was, can be reduced to an equation less than one inch long ! *** okay, here's the question ... I've been reading the books included w/ the "pro" versions of Suse7.0-7.3 , but I am still unclear about how it works , for instance it claims to hide all your data on a laptop , so if it's "lost, strayed or the other thing " the person who relocates it wont even know there is anything there... The problem I have it , I have to find a way to protect files which are mandated by federal law to be kept most secret, and only ever transmitted w/ the express permission of the person they represent. ( gee, I hope that is deciferable enough, while letting you guys know it's a major big deal w/ federal penalties attached, but surprisingly does NOT concern government secrets ... ) There are two problems w/ say packing them into a nice archive and then making certain only one person has permission to open , read , or write to them... the first is, they may be required several times during a single day , and would need to be easy to access for the fileowner , and they are sometimes required by more than one person in the office for perfectly legal and permissable use ... So they can't just be bundled into an archive.. and there are sure to be several different files each day.. and archives , made easy enough to recognise ( we may be talking about 1000's or records here, sometimes many thousands ) the archive names would give the game away .. and it seems to me that a clever , shall we say "hunter" or "seaker" would know just where to go in the system, should they find a way to tresspass it. So my solution to be practicle ( no good dreaming up a really secure setup if no one uses it!) was to have included this crypt file system for the ultimate storage , and perhaps some variant for the things needed more daily ... or perhaps up to some time in the more recent past, would have had some sort of archival storage which would keep casual browsers from noticing ( after all there are what seem like thousands of SuSE's files, for the document server and such, that are stored on one of the boxen here as archived files ... and these might be given some sort of a numbering system instead of names of the records , perhaps? Any help or locations to search , specific to a suse distro would be most helpful ... I have, as I said , read the most obvious ones .. man pages and so on .... TIA -- j afterthought : Law of Probability Dispersal:Whatever it is that hits the fan will not be evenly distributed.

1 0