Re: Why does Debian allow all incoming traffic by default
- Date: Sat, 22 Sep 2018 13:38:11 +0300
- From: Reco <recoverym4n@xxxxxxxxx>
- Subject: Re: Why does Debian allow all incoming traffic by default
On Sat, Sep 22, 2018 at 06:05:01AM -0400, Henning Follmann wrote:
> On Fri, Sep 21, 2018 at 09:32:45PM +0300, Reco wrote:
> > Hi.
> > On Fri, Sep 21, 2018 at 07:14:03PM +0100, Brian wrote:
> > > On Fri 21 Sep 2018 at 19:25:22 +0300, Reco wrote:
> > >
> > > > Hi.
> > > >
> > > > On Fri, Sep 21, 2018 at 08:55:21AM -0400, Henning Follmann wrote:
> > > > > On Fri, Sep 21, 2018 at 08:34:50AM +0530, Subhadip Ghosh wrote:
> > > > > > Hi,
> > > > > >
> > TCP RST attack requires exactly that. That, and an absence of a
> > firewall.
> > > There is no point with a standard Debian installation (which is what the
> > > OP inquired about). Debian is already a good netizen.
> > Good person makes a TCP connection to unprotected (as in - no firewall
> > interference) host. Since there's nothing on a host that does not listen
> > appropriate TCP port - host's kernel sends back TCP RST packet.
> > Good person's connection terminates, everyone's happy. That's how it
> > goes in your typical LAN.
> Sorry that is not how a RST attack works.
> You send a TCP package two either or both ends where the RST flag is set by
> faking your address. This way mostTCP implementation close the exsisting
> connection. The china firewall works that way. It is a kind of denial of
> service attack.
That's how it goes if you're in-between router.
> If you send a TCP package to a computer not listening it will send a ICMP
> error back.
Does not work that way for me in a single L2 segment:
nmap -sT -p 23 <victim.host.has.no.telnet>
tcpdump -ni <outgoing interface>
13:28:17.826101 IP 10.20.0.1.37928 > 10.20.110.23.23: Flags [S], seq ...269
13:28:17.826111 IP 10.20.110.23.23 > 10.20.0.1.37928: Flags [R.], seq 0, ack ...270
Can I have my ICMP packet please? I can generate those with iptables'
REJECT target, but I get TCP RST only with empty INPUT chain.
> > Evil person makes a TCP connection to unprotected host, but forges
> > source IP. Host sends TCP RST to this forged IP, host acting as a
> > 'reflector' to an attack. And being a bad netizen at the same time.
> > Evil person takes as many of such hosts as possible - and there goes
> > your old-fashioned RST DDOS.
Yes. Nobody does it anymore as there are numerous ways of traffic
amplification, but still 'yes'.
> > I recall that you've stated that your servers do not run any kind of
> > packet filter. So, just in case - one cannot harm the reflector that
> > way.
> On those machines where I run a firewall, I use by default REJECT and not
> DROP. This also sends a ICMP back. In most cases this is desireable.
In a LAN that's definitely desirable. Helps with the troubleshooting and
stuff. Doing this in a WAN makes the host a bad netizen.
> If you
> drop the package without error the TCP sender will just think the package
> was lost and will resend the package. So in most cases REJECT might be
> better than DROP anyway.
I stopped catering for the needs of clearly broken software years ago,
so DROP for WAN is the way.