openSUSE Security August 2003

security@lists.opensuse.org

122 participants
104 discussions

how to keep nimda and code red from filling apache logs

by Mathias Homann

Hi all, here's a bit of a step-by-step description on how to keep nimda and codered from filling your apache logs. Parts used: - SuSE 7.2 Professional - SuSEfirewall2 - iptables 1.2.3 - linux kernel 2.4.13-pre5 steps: 1. install kernel sources for a kernel >> 2.4.9, running 2.4.13- pre5 here, works fine so far 2. get the sources for iptables 1.2.3 from http://netfilter.samba.org 3. unpack sources somewhere 4. export KERNEL_DIR=$(where you put the kernel tree) 5. cd into unpacked iptables sources, there's a subdirectory named patch-o-matic there 6. apply wanted patches by running ./runme $(name.of.patch)patch for this here You'll want the string patch You can also apply other patches, like the irc-conntrack patch 7. now there's a little bug in this patch... here's a diff: --- linux/net/ipv4/netfilter/ipt_string.c~ Sun Oct 21 00:16:29 2001 +++ linux/net/ipv4/netfilter/ipt_string.c Sun Oct 21 16:54:45 2001 @@ -62,7 +62,7 @@ sk = skip[haystack[right_end - i]]; sh = shift[i]; - right_end = max(int, right_end - i + sk, right_end + sh); + right_end = max(right_end - i + sk, right_end + sh); } return NULL; 8. now, make config/menuconfig/xconfig... as usual. You can import your running kernel's config first. 9. enable the experimental stuff 10. go to networking options->netfilter, there's an option there to enable string matching; set that to M 11. compile and install kernel as usual; remember to uncomment the export INSTALL_PATH=/boot in the main makefile. 12. now build a rpm file for the new iptables stuff by installing the source rpm which comes with suse, then edit the spec file, put the iptables source in /usr/src/packages/SOURCE and rebuild. 13. now there are some small changes to the firewall config files. a) uncomment the last line in /etc/rc.config.d/firewall2.rc.config: FW_CUSTOMRULES="/etc/rc.config.d/firewall2-custom.rc.config" b) edit that file, I got the following stuff in mine: for forbidden_string in root.exe cmd.exe .ida; do iptables -I input_ext -p tcp --dport http -m string \ --string $forbidden_string -m state \ --state ESTABLISHED -j REJECT --reject-with tcp-reset done put that in the last supfunction defined in the custom rc file. c) change the FW_LOG setting in firewall2.rc.config from reading -log-level warning to -log-level kernel.warning 14. last: some small changes to /sbin/SuSEfirewall2 search in the script for the parts where the modules are loaded and unloaded; be sure to add ipt_string (and the other new modules you created by patching the kernel and enabling them in make config) to the modules loading/unloading code there. 15. reboot 16. if you try now to access (from outside, of course) one of the nimda or codered URLS, all you get is a 'connection reset by peer', and the request doesn't show in apache log files. btw, no guarantees, and the usual YMMV :) bye [L]

18 years, 9 months

rebuild from srpms

by Jeff Harris

I want to rebuild some rpms for various reasons, but mostly to change some of the configure settings. I must not be looking in the right place for directions on this, but all I can seem to find are directions on building a rpm file. I'm looking for tips and to make sure that my thinking is correct in what I do. Does building from srpm update the rpm database? To change some of the ./configure settings, would I simply change the spec file, or is there some other way of doing it? Thanks Jeff -- Registered Linux user #304026. "lynx -source http://www.rallycentral.us/~linux/jharris.asc | gpg --import" or "gpg --keyserver pgp.mit.edu --recv-key BD23A31E" Key fingerprint = FB8C 3210 8DE1 78F4 6505 5918 0C34 BE94 BD23 A31E

18 years, 10 months

postfix+amavis-new

by Dominik Składanowski

Hello. Because Sobig.F is still expanded, I have installed amavis-new with virus scanner on mail server. It works, worms and viruses are trashed. But I saw that if to mail server comes clear message without any worm or virus, but username is wrong, server don't send back mail. Server keeps it in queue. How can I fix it? -- ++++++++++++++++++++++++++++++++++++++++++ Dominik Składanowski ++++++++++++++++++++++++++++++++++++++++++

18 years, 10 months

nessus versions?

by Mathias Homann

Just a stupid question: nessus is at 2.0.7 as its current stable version... suse 8.2 still has 1.2.7... any reasons? bye, MH -- Die unaufgeforderte Zusendung einer Werbemail an Privatleute verstößt gegen §1 UWG und 823 I BGB (Beschluß des LG Berlin vom 2.8.1998 Az: 16 O 201/98). Jede kommerzielle Nutzung der übermittelten persönlichen Daten sowie deren Weitergabe an Dritte ist ausdrücklich untersagt! gpg key fingerprint: 5F64 4C92 9B77 DE37 D184 C5F9 B013 44E7 27BD 763C

18 years, 10 months

Bastille support?

by Richard Ems

Are there any plans to "port" Bastille to SuSE? In Bastille's mailing list I found a thread about Niki Rahimi (from IBM) working with Olaf Kirch on "porting" Bastille to SuSE! What happened with this effort? SuSE doesn't have harden_suse anymore, Bastille isn't supported, we (I!) do need such a system's security hardening tool! Olaf? Richard -- Richard Ems ... e-mail: r.ems(a)gmx.net ... Computer Science, University of Hamburg "Do or do not. There is no try" - Yoda Yoda never programmed in Java.

18 years, 10 months

Re: Offener Brief SuSE Installations Support

by Christian Prior

From: "claus" <ch(a)greenmail.ch> //snip Am Donnerstag, 28. August 2003 11:13 schrieb claus: //snip Rumkrakelen ohne Realname? Klasse Aktion, Mann.. -- Christian Prior http://www.prior-I.De

18 years, 10 months

Re: [suse-security] Re: stopping DrDOS attacks against Apache???

by Keith Roberts

Hi Steffen, As you can see, I'm no TCP guru (not yet anyway!) Here is my reply. > > > Do you really mean Apache, as a user land software? I guess > > > apache works on TCP sockets; for TCP socket the handshake is > > > transparent. How to notice a SYN flood attack from userland? > > > Maybe installing some raw socket for sniffing or such? mmm... not > > > clean and straightforward. Installing a kernel module? Complex. > > > So what is your way of handling that? > > > > > Which information? Sorry, I see no benefits for a userland > > > software here. Because of the random pattern you have no choice > > > to decide if a new SYN packet is part of an attack or a client > > > handshake. With limitation of SYN, you jsut reduce the damage of > > > the SYN flood - but it keeps a DOS. > > > > > I guess this would be very linux-specific, wouldn't it? How you > > > would start realizing this? > > > > Possibly as a DSO loadable Apache module. > > You do not see anything not established in userland, do you? Perhaps things need to be dealt with on a lower level then? > > it does not reply with the ACK packet that the > > servers are waiting for, to complete the three way TCP new > > connection initiation sequence. > > Ist that true? Isn't a RST sent? It could be - I'm not sure of the exact sequence. I may be getting way out of my depth here, so I can't say exactly. According to the explanation on grc.com, its SYN, SYN/ACK, then ACK. whatever it is at the moment is not to important. > > My idea is to keep a lookup table, possibly inside Apache > > itself, (maybe as a loadable module to start with for > > testing, then part of the core server) of all IP source > > addresses requesting a new connection to Apache that are not > > completed, and are 'hanging' - waiting for the 3 way TCP > > handshake to be completed. > > yes, what does this help? The idea is to identify the DrDos packets, and ONLY block those, while allowing ALL othe SYN packets through. Limiting by matching SYN connection packets will block all new connections - so I thought it would be handy just block the DrDoS attacks, and allow all other legit packets into the box. > > When certain limits are reached, the server can then > > release all hung connection attempts to the offending IP > > source address, and then block any future packets from > > trying to connect from that IP address, for a certain amount > > of time - possible an hour or more. > > This does help maybe against a SYN reflection DOS, but not > against a SYN flood, because here every IP is just used ONCE > (approximately, it's random, after all). So blocking does not > help. You do not know if its from a DOS attack or a slow client. I'm not trying to deal with the above issue at the moment Steffan. As each style of DOS attack varies, then it will obviously need a tailored response, specificallt to deal with the style of attack. > Additionally, for my understanding this has > nothing to do with Apache (you can use any TCP service). Perhaps the info I have been reading has been made to simplistic, to aid in the users understanding of the technology. I'm new to TCP protocols, but I'm willing to learn! > BTW, what is the advantage for an attacker to use a SYN > reflection instead of a standard mstream style flood? If you see the info on grc.com, DRDoS link, that should give you alot of info concerning this. Kind Regards - Keith Roberts

18 years, 10 months

Announced security patches

by Ulrich Roth

Hello people from SuSE, why isn't every security update announced here? As I want to update some of our servers, I looked through the list of downloadable patches on your server and found that some of them weren't announced in this list, e.g. patches for MySQL in June. Why is it like that? Regards Uli -- Ulrich Roth IMPACT Business & Technology Consulting GmbH Im Mediapark 8 / KölnTurm D-50670 Koeln Phone +49-221-93 70 80-29 Fax +49-221-93 70 80-15 E-Mail: roth at impact dot de

18 years, 10 months

FTP: can connect but cannot transfer data

by Jeroen Taalman

This may be quite basic for some of you. I'm using my own firewall script on a Suse 8.2P box. See below. Clients can connect and login but when a command like LS or GET is given, nothing happens. It seems data transfer is not possible. It doesn't make a difference whether passive mode is used or not. When I add a line to the script like this: IPTABLES -A INPUT -p tcp -s A.B.C.D -j ACCEPT then client with IP =A.B.C.D can transfer data. Of course this is not what I want because it is a potential risk. Any help will be appreciated. Regards, Jeroen Taalman Anywise This is the script I use: #!/bin/sh iptables -F # iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # # set defaults (policies) # iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP # # use connection state to bypass rule checking iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # # allow these ports iptables -A INPUT -p tcp -s 0/0 --dport 22 -j ACCEPT # SSH iptables -A INPUT -p tcp -s 0/0 --dport 20 -j ACCEPT # FTP iptables -A INPUT -p tcp -s 0/0 --dport 21 -j ACCEPT # FTP iptables -A INPUT -p tcp -s 0/0 --dport 25 -j ACCEPT # SMTP iptables -A INPUT -p tcp -s 0/0 --dport 80 -j ACCEPT # HTTP iptables -A INPUT -p tcp -s 0/0 --dport 443 -j ACCEPT # HTTPS iptables -A INPUT -p tcp -s 0/0 --dport 1984 -j ACCEPT # BB c2s iptables -A INPUT -p tcp -s 0/0 --dport 3306 -j ACCEPT # MySQL iptables -A INPUT -p tcp -s 0/0 --dport 3310 -j ACCEPT # MySQL iptables -A INPUT -p tcp -s 0/0 --dport 5222 -j ACCEPT # Jabber c2s iptables -A INPUT -p tcp -s 0/0 --dport 5269 -j ACCEPT # Jabber s2s iptables -A INPUT -p tcp -s 0/0 --dport 10000 -j ACCEPT # Webmin # # syn flood protection iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT # # furtive port scanner iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT # # ping of death iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

18 years, 10 months

SuSE(8.2)firewall2 and Dantz Retrospect client

by Christian Andersson

Greetings all you firewall-pros out there, I'm using SuSE PRO 8.2 on a machine which is partly backed up daily using Dantz Retrospect 6. The server is running on a remote Apple computer in our server HQ. The backup operations seems to work fine. However, the server machine is multicasting some kínd of polls to all the clients, which flood my firewall logs. It looks like this: //: Aug 27 00:11:02 torvalds kernel: SuSE-FW-ILLEGAL-TARGET IN=eth0 OUT= MAC=01:zz:5e:zz:00:zz:00:zz:93:zz:ff:zz:08:zz SRC=AAA.BBB.CCC.DDD DST=224.1.0.38 LEN=224 TOS=0x00 PREC=0x00 TTL=1 ID=3001 PROTO=UDP SPT=59174 DPT=497 LEN=204 :// (thousands of these on different high SPT:s) The Retrospect server AAA.BBB.CCC.DDD is registered among my FW_TRUSTED_NETS and the dantz service (sap 497) is in my FW_ALLOW_INCOMING_HIGHPORTS_UDP. I suspect, however, that it is the multicast DST address 224.1.0.38 that screws things up. Does anyone have any suggestions on how to deal with this in my client config, so that my syslog can get some rest? Thanks in advance -- Ch

18 years, 10 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

openSUSE Security August 2003