Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
iptables and networking
16 views
Skip to first unread message
Pol Hallen
Jun 19, 2013, 2:10:01 PM6/19/13
to
Hey all :-)
take again iptables, I need to configure another server.
On my server I've:
eth0 Link encap:Ethernet HWaddr 00:55:d0:c4:f8:1b
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
route -n
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
office
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 dsl
[...]
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -d 0/0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -d
192.168.1.0/24 -j ACCEPT
[...]
On new server
eth0 Link encap:Ethernet HWaddr 00:21:5e:46:7b:10
inet addr:95.110.207.165 Bcast:95.110.207.255 Mask:255.255.248.0
route -n
0.0.0.0 95.110.200.1 0.0.0.0 UG 0 0 0 eth0
95.110.200.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0
is it correct do:
[...]
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 95.110.207.0/21 -d 0/0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -d
95.110.207.0/21 -j ACCEPT
[...]
Second question: the FORWARD chain is useful only with another pc on
same lan. If this is server is only a file server (i.e.) I can commented
out FORWARD chain. On not?
thanks for help!
Pol
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51C1F36D...@fuckaround.org
take again iptables, I need to configure another server.
On my server I've:
eth0 Link encap:Ethernet HWaddr 00:55:d0:c4:f8:1b
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
route -n
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
office
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 dsl
[...]
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -d 0/0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -d
192.168.1.0/24 -j ACCEPT
[...]
On new server
eth0 Link encap:Ethernet HWaddr 00:21:5e:46:7b:10
inet addr:95.110.207.165 Bcast:95.110.207.255 Mask:255.255.248.0
route -n
0.0.0.0 95.110.200.1 0.0.0.0 UG 0 0 0 eth0
95.110.200.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0
is it correct do:
[...]
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 95.110.207.0/21 -d 0/0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -d
95.110.207.0/21 -j ACCEPT
[...]
Second question: the FORWARD chain is useful only with another pc on
same lan. If this is server is only a file server (i.e.) I can commented
out FORWARD chain. On not?
thanks for help!
Pol
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51C1F36D...@fuckaround.org
Steven Post
Jun 19, 2013, 3:20:02 PM6/19/13
to
If you only have these 2 rules, your server will be able to connect to
other machines and the internet, but it will not accept new connections.
If your server needs to be accessed by others (webserver, running SSH,
printing server, etc.) you need to define additional rules to allow that
incoming traffic.
In the above I am assuming a default policy of 'drop' on at least the
INPUT chain, the command (as root, no quotes) "iptables -L -vn" will
print all currently active rules and the default policy (what should
happen if no rule is matched). If the default policy is 'ACCEPT' those 2
rules by themselves have no effect.
Also, be careful no to lock yourself out of the machine if configuring
iptables using SSH.
>
> Second question: the FORWARD chain is useful only with another pc on
> same lan. If this is server is only a file server (i.e.) I can commented
> out FORWARD chain. On not?
forwarded by that machine (if it is acting as a router for example)
A machine with only 1 network interface (not counting the loopback
interface(s), but counting real interfaces, VPN and similar) does not
need rules in the FORWARD chain.
>
> thanks for help!
>
> Pol
>
>
Regards,
Steven
Pol Hallen
Jun 20, 2013, 7:00:01 AM6/20/13
to
> For the FORWARD chain, see below.
> If you only have these 2 rules, your server will be able to connect to
> other machines and the internet, but it will not accept new connections.
> If your server needs to be accessed by others (webserver, running SSH,
> printing server, etc.) you need to define additional rules to allow that
> incoming traffic.
Hi Steven and thanks for your reply :-)
> If you only have these 2 rules, your server will be able to connect to
> other machines and the internet, but it will not accept new connections.
> If your server needs to be accessed by others (webserver, running SSH,
> printing server, etc.) you need to define additional rules to allow that
> incoming traffic.
This is my full iptables config:
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -A INPUT -f -j DROP
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -f -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p icmp -j ACCEPT
with this way my actually server runs perfectly. Is there other rules to
block ddos attack, or other type of attacks?
> In the above I am assuming a default policy of 'drop' on at least the
> INPUT chain, the command (as root, no quotes) "iptables -L -vn" will
> print all currently active rules and the default policy (what should
> happen if no rule is matched). If the default policy is 'ACCEPT' those 2
> rules by themselves have no effect.
>
> Also, be careful no to lock yourself out of the machine if configuring
> iptables using SSH.
Pol
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steven Post
Jun 20, 2013, 3:30:02 PM6/20/13
to
On Thu, 2013-06-20 at 12:53 +0200, Pol Hallen wrote:
[...]
>
> This is my full iptables config:
[... snip iptables rules...]
an attacker might just be flooding the connection, there are commercial
services for that if you really want them, but these are not cheap.
Some other things you might consider blocking on the firewall are
repeated attempts to log in to the server, such as a brute force attack
on your SSH service.
You can block repeated attempts to log in with iptables using the
'recent' module, an alternative is 'fail2ban', which monitors your
server logs (ssh, apache, and others) for failed login attempts and then
adds an iptables rule for the offending IP. It is available in the
repository, but I cannot comment on its working much as I don't use it
(yet?). I heard it's really good.
For my simple home server I use the 'recent' module:
iptables -A INPUT -i $EXTIF -p tcp --dport 22 -m state --state NEW -m
recent --set
iptables -A INPUT -i $EXTIF -p tcp --dport 22 -m state --state NEW -m
recent --update --seconds 120 --hitcount 3 -j DROP
iptables -A INPUT -i $EXTIF -p tcp --dport 22 -m state --state NEW -j
ACCEPT
This blocks new connections if a host attempts more than 3 connections
within 120 seconds, still enough if I type in the wrong password
(openssh will allow 3 attempts before disconnecting if I recall
correctly). This is sufficient for most attacks on ssh, of course you
already disabled direct root login.
In some cases the 'limit' module for iptables might be useful, for
example (not really a good one):
iptables -A INPUT -i $EXTIF -p tcp --dport 21 -m state --state NEW -m
limit --limit 1/min --limit-burst 3 -j ACCEPT
This will only allow 1 connection attempt on an FTP server per minute,
with an initial burst of 3 before limiting.
Regards,
Steven
PS: no need to send the mail directly to me, I'm subscribed to the list.
[...]
>
> Hi Steven and thanks for your reply :-)
You're welcome.
> Hi Steven and thanks for your reply :-)
>
> This is my full iptables config:
>
> with this way my actually server runs perfectly. Is there other rules to
> block ddos attack, or other type of attacks?
A real ddos cannot really be blocked by using iptables on the server, as
> with this way my actually server runs perfectly. Is there other rules to
> block ddos attack, or other type of attacks?
an attacker might just be flooding the connection, there are commercial
services for that if you really want them, but these are not cheap.
Some other things you might consider blocking on the firewall are
repeated attempts to log in to the server, such as a brute force attack
on your SSH service.
You can block repeated attempts to log in with iptables using the
'recent' module, an alternative is 'fail2ban', which monitors your
server logs (ssh, apache, and others) for failed login attempts and then
adds an iptables rule for the offending IP. It is available in the
repository, but I cannot comment on its working much as I don't use it
(yet?). I heard it's really good.
For my simple home server I use the 'recent' module:
iptables -A INPUT -i $EXTIF -p tcp --dport 22 -m state --state NEW -m
recent --set
iptables -A INPUT -i $EXTIF -p tcp --dport 22 -m state --state NEW -m
recent --update --seconds 120 --hitcount 3 -j DROP
iptables -A INPUT -i $EXTIF -p tcp --dport 22 -m state --state NEW -j
ACCEPT
This blocks new connections if a host attempts more than 3 connections
within 120 seconds, still enough if I type in the wrong password
(openssh will allow 3 attempts before disconnecting if I recall
correctly). This is sufficient for most attacks on ssh, of course you
already disabled direct root login.
In some cases the 'limit' module for iptables might be useful, for
example (not really a good one):
iptables -A INPUT -i $EXTIF -p tcp --dport 21 -m state --state NEW -m
limit --limit 1/min --limit-burst 3 -j ACCEPT
This will only allow 1 connection attempt on an FTP server per minute,
with an initial burst of 3 before limiting.
Regards,
Steven
PS: no need to send the mail directly to me, I'm subscribed to the list.
Redalert Commander
Jun 21, 2013, 7:20:01 AM6/21/13
to
Forward message back to the list, as agreed to by Igor.
---------- Forwarded message ----------
From: Igor Cicimov
Date: 2013/6/21
Subject: Re: iptables and networking
To: Steven Post
Another option is the hashlimit module. Its based simply on the fact
that ddos sends bursts of traffic over the connection. Example below
for port 80 but can be applied to 22 or any othet service.
iptables -A INPUT -p tcp --dport 80 -m hashlimit --hashlimit-upto
50/min \ --hashlimit-burst 500 --hashlimit-mode srcip --hashlimit-name
http -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
What this does is allows up to 500 packets (not connections, because
HTTP can do multiple transactions per connection you have to consider
whether you want to do this on all packets or SYN packets only). If
there are more than 500/min, it will then throttle it down to 50/min
until the rate drops. Anything outside of these limits gets dropped.
This combined with limiting the number of simultanious connections per
source ip and low connection timeout should give good ddos protection.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAMDu+mPx-AcvODdjEUM2_g2TtR=aKu0t23Dt+h...@mail.gmail.com
---------- Forwarded message ----------
From: Igor Cicimov
Date: 2013/6/21
Subject: Re: iptables and networking
To: Steven Post
that ddos sends bursts of traffic over the connection. Example below
for port 80 but can be applied to 22 or any othet service.
iptables -A INPUT -p tcp --dport 80 -m hashlimit --hashlimit-upto
50/min \ --hashlimit-burst 500 --hashlimit-mode srcip --hashlimit-name
http -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
What this does is allows up to 500 packets (not connections, because
HTTP can do multiple transactions per connection you have to consider
whether you want to do this on all packets or SYN packets only). If
there are more than 500/min, it will then throttle it down to 50/min
until the rate drops. Anything outside of these limits gets dropped.
This combined with limiting the number of simultanious connections per
source ip and low connection timeout should give good ddos protection.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pascal Hambourg
Jun 30, 2013, 9:30:02 AM6/30/13
to
Hello,
Pol Hallen a écrit :
> iptables -P OUTPUT ACCEPT
Should be DROP as well.
> iptables -P FORWARD DROP
> iptables -P INPUT DROP
OK.
> iptables -A INPUT -f -j DROP
Useless. IPv4 connection tracking (needed by the 'state' match)
reassembles packets so iptables won't see any fragments.
> iptables -A INPUT -m state --state INVALID -j DROP
Useless if policy is already DROP and further rules accept only state
NEW, ESTABLISHED or RELATED.
> iptables -A OUTPUT -f -j DROP
See above.
> iptables -A OUTPUT -m state --state INVALID -j DROP
See above.
> iptables -A INPUT -i lo -j ACCEPT
OK.
> iptables -A OUTPUT -o lo -j ACCEPT
Useless if policy is left to ACCEPT.
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
OK.
> iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Useless if policy is left to ACCEPT.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51D02D80...@plouf.fr.eu.org
Pol Hallen a écrit :
>
> This is my full iptables config:
>
> iptables -F
> iptables -t nat -F
> iptables -t mangle -F
> iptables -X
OK.
> This is my full iptables config:
>
> iptables -F
> iptables -t nat -F
> iptables -t mangle -F
> iptables -X
> iptables -P OUTPUT ACCEPT
Should be DROP as well.
> iptables -P FORWARD DROP
> iptables -P INPUT DROP
> iptables -A INPUT -f -j DROP
reassembles packets so iptables won't see any fragments.
> iptables -A INPUT -m state --state INVALID -j DROP
NEW, ESTABLISHED or RELATED.
> iptables -A OUTPUT -f -j DROP
> iptables -A OUTPUT -m state --state INVALID -j DROP
> iptables -A INPUT -i lo -j ACCEPT
> iptables -A OUTPUT -o lo -j ACCEPT
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pascal Hambourg
Jun 30, 2013, 9:40:01 AM6/30/13
to
Redalert Commander a écrit :
be abused to cause a DoS for the spoofed address. fail2ban is much less
vulnerable to such attacks.
>> In some cases the 'limit' module for iptables might be useful, for
>> example (not really a good one):
The limit match is even worse as it can be easily abused to cause a DoS
for all clients.
>> iptables -A INPUT -i $EXTIF -p tcp --dport 21 -m state --state NEW -m
>> limit --limit 1/min --limit-burst 3 -j ACCEPT
>>
>> This will only allow 1 connection attempt on an FTP server per minute,
>> with an initial burst of 3 before limiting.
So an attacker just needs to send 3 packets per minute to block all
access for anyone to the server. Great.
> Another option is the hashlimit module. Its based simply on the fact
> that ddos sends bursts of traffic over the connection. Example below
> for port 80 but can be applied to 22 or any othet service.
Hashlimit won't protect against DDoS attacks or DoS attacks using source
IP address spoofing.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51D02F83...@plouf.fr.eu.org
>
> ---------- Forwarded message ----------
> From: Igor Cicimov
>
> ---------- Forwarded message ----------
> From: Igor Cicimov
>
>> You can block repeated attempts to log in with iptables using the
>> 'recent' module, an alternative is 'fail2ban', which monitors your
>> server logs (ssh, apache, and others) for failed login attempts and then
>> adds an iptables rule for the offending IP.
The 'recent' match is vulnerable to source IP address spoofing and can
>> 'recent' module, an alternative is 'fail2ban', which monitors your
>> server logs (ssh, apache, and others) for failed login attempts and then
>> adds an iptables rule for the offending IP.
be abused to cause a DoS for the spoofed address. fail2ban is much less
vulnerable to such attacks.
>> In some cases the 'limit' module for iptables might be useful, for
>> example (not really a good one):
for all clients.
>> iptables -A INPUT -i $EXTIF -p tcp --dport 21 -m state --state NEW -m
>> limit --limit 1/min --limit-burst 3 -j ACCEPT
>>
>> This will only allow 1 connection attempt on an FTP server per minute,
>> with an initial burst of 3 before limiting.
access for anyone to the server. Great.
> Another option is the hashlimit module. Its based simply on the fact
> that ddos sends bursts of traffic over the connection. Example below
> for port 80 but can be applied to 22 or any othet service.
IP address spoofing.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jerry Stuckle
Jun 30, 2013, 11:10:01 AM6/30/13
to
On 6/30/2013 9:15 AM, Pascal Hambourg wrote:
> Redalert Commander a écrit :
>>
>> ---------- Forwarded message ----------
>> From: Igor Cicimov
>>
>>> You can block repeated attempts to log in with iptables using the
>>> 'recent' module, an alternative is 'fail2ban', which monitors your
>>> server logs (ssh, apache, and others) for failed login attempts and then
>>> adds an iptables rule for the offending IP.
>
> The 'recent' match is vulnerable to source IP address spoofing and can
> be abused to cause a DoS for the spoofed address. fail2ban is much less
> vulnerable to such attacks.
>
I don't understand this statement. How is 'recent' more vulnerable to
> Redalert Commander a écrit :
>>
>> ---------- Forwarded message ----------
>> From: Igor Cicimov
>>
>>> You can block repeated attempts to log in with iptables using the
>>> 'recent' module, an alternative is 'fail2ban', which monitors your
>>> server logs (ssh, apache, and others) for failed login attempts and then
>>> adds an iptables rule for the offending IP.
>
> The 'recent' match is vulnerable to source IP address spoofing and can
> be abused to cause a DoS for the spoofed address. fail2ban is much less
> vulnerable to such attacks.
>
source IP address spoofing than fail2ban? Both depend only on the
supplied address.
And how can recent 'be abused to cause a DoS...' any more than fail2ban?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
staticsafe
Jun 30, 2013, 12:00:02 PM6/30/13
to
(Hint - three way handshake for TCP).
--
staticsafe
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post.
Please don't CC! I'm subscribed to whatever list I just posted on.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pascal Hambourg
Jun 30, 2013, 2:40:03 PM6/30/13
to
staticsafe a écrit :
the NEW state, i.e. the initial SYN. A single SYN packet can be easily
forged with a spoofed source address. Fail2ban is based on
authentication failures, which first requires a TCP connection to be
established with the 3-way handshake. As it involves a positive reply
from the spoofed address, this is much harder to achieve, unless the
attacker is in a special position on the network.
> And how can recent 'be abused to cause a DoS...' any more than fail2ban?
This is just the consequence of the above.
> IP address spoofing with TCP, what?
Yes.
> That only works with UDP.
No. It works with any mechanism which is based on a simple packet
instead of a real "stateful" connection (including a positive reply).
Which is the case here, see below.
> (Hint - three way handshake for TCP).
As I wrote above, the proposed rulesets using the 'recent' and 'limit'
matches are only based on the initial SYN packets. They do not care
about the 3-way handshake.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51D07700...@plouf.fr.eu.org
> On Sun, Jun 30, 2013 at 03:15:47PM +0200, Pascal Hambourg wrote:
>> Redalert Commander a écrit :
>>> ---------- Forwarded message ----------
>>> From: Igor Cicimov
>>>
>>>> You can block repeated attempts to log in with iptables using the
>>>> 'recent' module, an alternative is 'fail2ban', which monitors your
>>>> server logs (ssh, apache, and others) for failed login attempts and then
>>>> adds an iptables rule for the offending IP.
>>
>> The 'recent' match is vulnerable to source IP address spoofing and can
>> be abused to cause a DoS for the spoofed address. fail2ban is much less
>> vulnerable to such attacks.
Jerry Stuckle a écrit :
>> Redalert Commander a écrit :
>>> ---------- Forwarded message ----------
>>> From: Igor Cicimov
>>>
>>>> You can block repeated attempts to log in with iptables using the
>>>> 'recent' module, an alternative is 'fail2ban', which monitors your
>>>> server logs (ssh, apache, and others) for failed login attempts and then
>>>> adds an iptables rule for the offending IP.
>>
>> The 'recent' match is vulnerable to source IP address spoofing and can
>> be abused to cause a DoS for the spoofed address. fail2ban is much less
>> vulnerable to such attacks.
> I don't understand this statement. How is 'recent' more vulnerable to
> source IP address spoofing than fail2ban? Both depend only on the
> supplied address.
The ruleset using the 'recent' match is based only on TCP packets with
> source IP address spoofing than fail2ban? Both depend only on the
> supplied address.
the NEW state, i.e. the initial SYN. A single SYN packet can be easily
forged with a spoofed source address. Fail2ban is based on
authentication failures, which first requires a TCP connection to be
established with the 3-way handshake. As it involves a positive reply
from the spoofed address, this is much harder to achieve, unless the
attacker is in a special position on the network.
> And how can recent 'be abused to cause a DoS...' any more than fail2ban?
> IP address spoofing with TCP, what?
> That only works with UDP.
instead of a real "stateful" connection (including a positive reply).
Which is the case here, see below.
> (Hint - three way handshake for TCP).
matches are only based on the initial SYN packets. They do not care
about the 3-way handshake.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
staticsafe
Jun 30, 2013, 3:10:01 PM6/30/13
to
On that topic, if you are getting flooded with SYNs, it is a good idea
to enable syncookies (kernel option).
--
staticsafe
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post.
Please don't CC! I'm subscribed to whatever list I just posted on.
staticsafe
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post.
Please don't CC! I'm subscribed to whatever list I just posted on.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013063019...@uriel.asininetech.com
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jerry Stuckle
Jun 30, 2013, 3:40:01 PM6/30/13
to
fail2ban, also. The first one is it requires an authentication failure.
Port probing will not trigger it (but recent can). The second being
it depends on log entries, which can be buffered. I have it monitoring
my email (smtp/imap/pop3) ports. Even though it is set to trigger after
two failures, I have seen as many as 50+ failures logged from the same
ip address within seconds before fail2ban is triggered.
I'm not so worried about SYN attacks from spoofed IP addresses as I am
attempts to break in (despite several security measures). I want to
shut them off ASAP.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kushal Kumaran
Jul 1, 2013, 2:20:01 AM7/1/13
to
Jerry Stuckle <jstu...@attglobal.net> writes:
>> <snipped previous context>
fail2ban does not require authentication failures. sshd will log a
message of the form "Did not receive identification string from <IP>" if
someone makes a TCP connection and then disconnects without going
through the SSH handshake.
> I'm not so worried about SYN attacks from spoofed IP addresses as I am
> attempts to break in (despite several security measures). I want to
> shut them off ASAP.
>
--
regards,
kushal
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51d11e9f.e4d8...@mx.google.com
>> <snipped previous context>
>
> OK, that makes a lot of sense. However, there are two problems with
> fail2ban, also. The first one is it requires an authentication failure.
> Port probing will not trigger it (but recent can). The second being
> it depends on log entries, which can be buffered. I have it monitoring
> my email (smtp/imap/pop3) ports. Even though it is set to trigger after
> two failures, I have seen as many as 50+ failures logged from the same
> ip address within seconds before fail2ban is triggered.
>
To address your first problem with fail2ban, the sshd-ddos filter for
> OK, that makes a lot of sense. However, there are two problems with
> fail2ban, also. The first one is it requires an authentication failure.
> Port probing will not trigger it (but recent can). The second being
> it depends on log entries, which can be buffered. I have it monitoring
> my email (smtp/imap/pop3) ports. Even though it is set to trigger after
> two failures, I have seen as many as 50+ failures logged from the same
> ip address within seconds before fail2ban is triggered.
>
fail2ban does not require authentication failures. sshd will log a
message of the form "Did not receive identification string from <IP>" if
someone makes a TCP connection and then disconnects without going
through the SSH handshake.
> I'm not so worried about SYN attacks from spoofed IP addresses as I am
> attempts to break in (despite several security measures). I want to
> shut them off ASAP.
>
--
kushal
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pascal Hambourg
Jul 1, 2013, 8:00:03 AM7/1/13
to
One more bit on the use of the 'recent' match against DoS.
Pascal Hambourg a écrit :
packet of the TCP 3-way handshake sent by the client, confirming the
connection is established. Unfortunately it just looks like any other
ACK packet in the stream (same TCP flags, same conntrack ctstate and
ctstatus), except that it is the first ACK (without SYN). Using
connection mark and packet mark, I guess it is possible to detect it :
By default, packet mark and connection mark are 0
If an ACK is received in the original direction and the connection mark
is 0, then set the packet mark and connection mark to 1
Translated into iptables rules :
-A INPUT -p tcp --tcp-flags SYN,ACK,RST ACK -m connmark --mark 0 \
-m ctstate --ctstate ESTABLISHED --ctdir ORIGINAL -j MARK --set-mark 1
-A INPUT -p tcp -m mark --mark 1 -j CONNMARK --set-mark 1
It seems to work, but I have not tested it extensively.
WARNING : --ctdir is inverted in kernels older than 2.6.39 (fix not
backported in any stable/longterm release at kernel.org), so you must
use REPLY instead of ORIGINAL (or negation with !) if you use such kernel.
If your ruleset already use packet marks or connection marks for other
purposes, you may need to apply masks to divide the marks into bitfields.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51D1697F...@plouf.fr.eu.org
Pascal Hambourg a écrit :
>
> The ruleset using the 'recent' match is based only on TCP packets with
> the NEW state, i.e. the initial SYN. A single SYN packet can be easily
> forged with a spoofed source address. Fail2ban is based on
> authentication failures, which first requires a TCP connection to be
> established with the 3-way handshake. As it involves a positive reply
> from the spoofed address, this is much harder to achieve, unless the
> attacker is in a special position on the network.
The 'recent' match could be used if it was possible to detect the last
> The ruleset using the 'recent' match is based only on TCP packets with
> the NEW state, i.e. the initial SYN. A single SYN packet can be easily
> forged with a spoofed source address. Fail2ban is based on
> authentication failures, which first requires a TCP connection to be
> established with the 3-way handshake. As it involves a positive reply
> from the spoofed address, this is much harder to achieve, unless the
> attacker is in a special position on the network.
packet of the TCP 3-way handshake sent by the client, confirming the
connection is established. Unfortunately it just looks like any other
ACK packet in the stream (same TCP flags, same conntrack ctstate and
ctstatus), except that it is the first ACK (without SYN). Using
connection mark and packet mark, I guess it is possible to detect it :
By default, packet mark and connection mark are 0
If an ACK is received in the original direction and the connection mark
is 0, then set the packet mark and connection mark to 1
Translated into iptables rules :
-A INPUT -p tcp --tcp-flags SYN,ACK,RST ACK -m connmark --mark 0 \
-m ctstate --ctstate ESTABLISHED --ctdir ORIGINAL -j MARK --set-mark 1
-A INPUT -p tcp -m mark --mark 1 -j CONNMARK --set-mark 1
It seems to work, but I have not tested it extensively.
WARNING : --ctdir is inverted in kernels older than 2.6.39 (fix not
backported in any stable/longterm release at kernel.org), so you must
use REPLY instead of ORIGINAL (or negation with !) if you use such kernel.
If your ruleset already use packet marks or connection marks for other
purposes, you may need to apply masks to divide the marks into bitfields.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jerry Stuckle
Jul 1, 2013, 8:30:01 AM7/1/13
to
On 7/1/2013 2:15 AM, Kushal Kumaran wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>
>>> <snipped previous context>
>>
>> OK, that makes a lot of sense. However, there are two problems with
>> fail2ban, also. The first one is it requires an authentication failure.
>> Port probing will not trigger it (but recent can). The second being
>> it depends on log entries, which can be buffered. I have it monitoring
>> my email (smtp/imap/pop3) ports. Even though it is set to trigger after
>> two failures, I have seen as many as 50+ failures logged from the same
>> ip address within seconds before fail2ban is triggered.
>>
>
> To address your first problem with fail2ban, the sshd-ddos filter for
> fail2ban does not require authentication failures. sshd will log a
> message of the form "Did not receive identification string from <IP>" if
> someone makes a TCP connection and then disconnects without going
> through the SSH handshake.
>
That's one message which can be logged (for SSH). But the message (and
> Jerry Stuckle <jstu...@attglobal.net> writes:
>
>>> <snipped previous context>
>>
>> OK, that makes a lot of sense. However, there are two problems with
>> fail2ban, also. The first one is it requires an authentication failure.
>> Port probing will not trigger it (but recent can). The second being
>> it depends on log entries, which can be buffered. I have it monitoring
>> my email (smtp/imap/pop3) ports. Even though it is set to trigger after
>> two failures, I have seen as many as 50+ failures logged from the same
>> ip address within seconds before fail2ban is triggered.
>>
>
> To address your first problem with fail2ban, the sshd-ddos filter for
> fail2ban does not require authentication failures. sshd will log a
> message of the form "Did not receive identification string from <IP>" if
> someone makes a TCP connection and then disconnects without going
> through the SSH handshake.
>
where it is logged) is going to be dependent on the program/service
running on the particular port (and sometimes the version of the
program/service).
After all, SSH is not the only possible entry point.
>> I'm not so worried about SYN attacks from spoofed IP addresses as I am
>> attempts to break in (despite several security measures). I want to
>> shut them off ASAP.
>>
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51D175FB...@attglobal.net
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages