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]
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
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
++++++++++++++++++++++++++++++++++++++++++
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
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.
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
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
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
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
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