On 8/19/12 11:40 AM, Michelle Konzack wrote:
> Hello Max,
>
> Am 2012-08-19 01:06:15, hacktest Du folgendes herunter:
>> It is necessary to limit the number of connections to
>> sshwithiptables, for example:
>> /sbin/iptables -p tcp -syn -dport 22-m connlimit -connlimit-above 3 -j DROP
>
> Oops... I have locked me out!
>
> I am right, this DROP from any IP addresses connections, if there are
> more then 3 at the same time?
>
> My automated scripts and several 100 embedded security systems hit the
> limits.
>
> Question: Is there a possibility to set a TIME LIMIT
> together with the above iptables line?
>


Exclude your own networks and trusted sources.

~Seth


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50314832.7060704@rollernet.us">http://lists.debian.org/50314832.7060704@rollernet.us

On Sun, 19 Aug 2012 18:33:16 +0200, Michelle wrote in message
<20120819163316.GB28928@work1>:

> I am ongoing to sue <rackspace.com> since they refuse to respond to
> my mails. Also I have checked my spamdatabase (IP adresses) and it
> seems, that this enterpeise is hosting several 100 spambots.

..so why not just put them on the spam zap lists? Oh wait... ;o)

..seriously, isn't the rackspace.com guys the same ones who host
one of the xen/xcp projects? May be a way to get past the 1'st
line support droids...

--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120819225448.53db1a72@celsius.lan">http://lists.debian.org/20120819225448.53db1a72@celsius.lan

On Sun, 19 Aug 2012, Leo Goehrs wrote:
> Null route will not protect the servers from a syn flood, the only way is to null route the attacked servers.

Null routing the source of the attacks will protect the servers from
*everything*, including customers in the null-routed networks.

It is of limited use on a DDoS because the attack source is all over the
map, but if all the crapflood comes from rackspace, null-routing them will
be very effective.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120820010109.GD8690@khazad-dum.debian.net">http://lists.debian.org/20120820010109.GD8690@khazad-dum.debian.net

Michelle Konzack wrote at 2012-08-19 13:40 -0500:
> Oops... I have locked me out!
>
> I am right, this DROP from any IP addresses connections, if there are
> more then 3 at the same time?
>
> My automated scripts and several 100 embedded security systems hit the
> limits.

Using the recent module, you can limit the number of new connection attempts
per IP address in n seconds. The following (not tested) allows only 8 new
connection attempts per source IP address in 5 minutes.

iptables -N SSH_CHECK
iptables -N SSH_REJECTED
iptables -A INPUT -p tcp --dport ssh --match state --state NEW -j SSH_CHECK
iptables -A INPUT -p tcp --dport ssh --match state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A SSH_CHECK -p tcp --match recent --name SSH --set
iptables -A SSH_CHECK -p tcp --match recent --name SSH --update --seconds 300 --hitcount 8 -j SSH_REJECTED
iptables -A SSH_CHECK -p tcp -j ACCEPT
iptables -A SSH_REJECTED -p tcp --match limit --limit 1/second -j LOG --log-prefix Rejected-ssh_ --log-level notify
iptables -A SSH_REJECTED -p tcp -j DROP

On Sun, 19 Aug 2012, Seth Mattinen wrote:
> Exclude your own networks and trusted sources.

Indeed. Seth is correct, that's the 1st rule of any such active
defences: don't let it become friendly fire.

And if you want it to scale, try to use ip sets. AFAIK, it should take
just one iptables rule, and you add whoever you want blocked to the ip
set refered by the iptables rule, and give the entry added to the set a
TTL so that the kernel will remove it after a while. I haven't tested
this yet, though.

That said, why did you not null-route the rackspace ASNs that are at the
attack's origin on your border routers as soon as you noticed the scale
of the attack? Do it.

And why didn't you enlist your transit provider's help? They should not
have any difficulty getting in touch with the rackspace NOC, and they
should be able to null-route the attack traffic for you, since it is not
even a large DDoS (where the origin is all over the world, and thus very
hard to null-route).

Anyway, here:
http://www.peeringdb.com/view.php?asn=15395&peerParticipantsPublics_mOrder= Sorter_local_asn&peerParticipantsPublics_mDir=ASC

And also, from APNIC:
noc@rackspace.com
9725 Datapoint Drive, Suite 100
San Antonio, TX 78229
+1-210-312-4700

Call (and email) the NOC. Be polite, concise, use clear english, and
list the IPs attacking your servers and the exact manner of the attack.
There's a good chance this will actually get things done.

You may also bring the issue to rackspace in a very public way by
twitting @rackspacenoc #rackspace #attack.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120820013203.GE8690@khazad-dum.debian.net">http://lists.debian.org/20120820013203.GE8690@khazad-dum.debian.net

Hello Henrique de Moraes Holschuh,

Am 2012-08-19 22:01:09, hacktest Du folgendes herunter:
> Null routing the source of the attacks will protect the servers from
> *everything*, including customers in the null-routed networks.

What is the config for "null routing"?

Since there are only Servers in the network/netblock I do not think I
harm any normal users

> It is of limited use on a DDoS because the attack source is all over the
> map, but if all the crapflood comes from rackspace, null-routing them will
> be very effective.

Not all, but a bunch of IPs from there network.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
<http://www.debian.tamay-dogan.net/>

itsystems@tdnet Jabber linux4michelle@jabber.ccc.de
Owner Michelle Konzack

Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)

USt-ID: DE 278 049 239

Linux-User #280138 with the Linux Counter, http://counter.li.org/

Forget about the nullrouting, it will not work in your case. The idea, is for example to set on your cisco a command like:

Ip route XXX.XXX.XX.XXX 255.255.255.252.0 null0

It will discard the return route, but will not eliminate the incoming flow.

-----Original Message-----
From: Michelle Konzack [mailto:linux4michelle@tamay-dogan.net]
Sent: lundi 20 août 2012 21:15
To: debian-isp@lists.debian.org
Subject: Re: fail2ban increase loadaverage to 18

Hello Henrique de Moraes Holschuh,

Am 2012-08-19 22:01:09, hacktest Du folgendes herunter:
> Null routing the source of the attacks will protect the servers from
> *everything*, including customers in the null-routed networks.

What is the config for "null routing"?

Since there are only Servers in the network/netblock I do not think I harm any normal users

> It is of limited use on a DDoS because the attack source is all over
> the map, but if all the crapflood comes from rackspace, null-routing
> them will be very effective.

Not all, but a bunch of IPs from there network.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
<http://www.debian.tamay-dogan.net/>

itsystems@tdnet Jabber linux4michelle@jabber.ccc.de
Owner Michelle Konzack

Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)

USt-ID: DE 278 049 239

Linux-User #280138 with the Linux Counter, http://counter.li.org/


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 952DE7F89E170749AD4BBF678A82A78D0105092B66@AL-MEX01-VBO.mail.alionis.fr">http://lists.debian.org/952DE7F89E170749AD4BBF678A82A78D0105092B66@AL-MEX01-VBO.mail.alionis.fr

Yes, it will, but you need to enable uRPF loose mode on the external
interfaces


!
interface GigabitEthernet1/1
description External Provider 1
...
ip verify unicast source reachable-via any
...
!
ip route XXX.XXX.XX.XXX 255.255.255.252.0 null0
!

If you have more than one router you could trigger this remotely via BGP:
http://packetlife.net/blog/2010/aug/23/source-based-rtbh/
http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_urpf/configuration/12-4t/sec-data-urpf-12-4t-book.pdf



On 08/20/12 22:18, Leo Goehrs wrote:

Forget about the nullrouting, it will not work in your case. The idea, is for example to set on your cisco a command like:

Ip route XXX.XXX.XX.XXX 255.255.255.252.0 null0

It will discard the return route, but will not eliminate the incoming flow.

-----Original Message-----
From: Michelle Konzack [mailto:linux4michelle@tamay-dogan.net]
Sent: lundi 20 août 2012 21:15
To: debian-isp@lists.debian.org
Subject: Re: fail2ban increase loadaverage to 18

Hello Henrique de Moraes Holschuh,

Am 2012-08-19 22:01:09, hacktest Du folgendes herunter:

Null routing the source of the attacks will protect the servers from
*everything*, including customers in the null-routed networks.

What is the config for "null routing"?

Since there are only Servers in the network/netblock I do not think I harm any normal users


It is of limited use on a DDoS because the attack source is all over
the map, but if all the crapflood comes from rackspace, null-routing
them will be very effective.

Not all, but a bunch of IPs from there network.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

--
##################### Debian GNU/Linux Consultant ######################
Development of Intranet and Embedded Systems with Debian GNU/Linux
Internet Service Provider, Cloud Computing
<http://www.itsystems.tamay-dogan.net/>
<http://www.debian.tamay-dogan.net/>

itsystems@tdnet Jabber linux4michelle@jabber.ccc.de
Owner Michelle Konzack

Gewerbe Strasse 3 Tel office: +49-176-86004575
77694 Kehl Tel mobil: +49-177-9351947
Germany Tel mobil: +33-6-61925193 (France)

USt-ID: DE 278 049 239

Linux-User #280138 with the Linux Counter, http://counter.li.org/





--
Best regards,
Adrian Minta MA3173-RIPE, www.minta.ro



--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50329D6C.4000401@gmail.com">http://lists.debian.org/50329D6C.4000401@gmail.com

On 08/19/2012 06:06 AM, Max wrote:
> It is necessary to limit the number of connections to sshwithiptables,
> for example:
> /sbin/iptables -p tcp -syn -dport 22-m connlimit -connlimit-above 3 -j DROP

And do not forget:
echo "1" > /proc/sys/net/ipv4/tcp_syncookies

(note: there's even an example in /etc/sysctl.conf with a link to an
article explaining what syncookies are...)

Thomas


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5048CA71.9070909@debian.org">http://lists.debian.org/5048CA71.9070909@debian.org