[ previous ] [ next ] [ threads ]
 From:  Hilton Travis <Hilton at QuarkAV dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] m0n0wall feature request
 Date:  Fri, 23 Jan 2004 22:09:29 +1000
Hi Manuel,

First, let me say that I am rather impressed with m0n0wall so far... 
Nice work!

On Fri, 2004-01-23 at 21:26, Manuel Kasper wrote:
> Jan Koetze wrote:
> > option to stop portscans the way portsentry does or at least drop the
> > request for a few minutes when a portscan occurs. With the current
> > release people can scan forever.
> So what?
> http://www.phildev.net/ipf/IPFques.html#18  <-- my opinion too

I agree.  People will portscan you - it is part of Internet life. 
Dropping the request, blocking their IP, and whatever will generally not
do much.  Good defensive rules are - by far - the best way to address

I do, however, like the idea of being able to automatically add IPs that
scan excessive ports in a short period of time to a "block" rule for a
user configurable period of time.  I'll look into this and get back to
the list.

> And RST and FIN scanning do not work with m0n0wall anyway due to the
> stateful filtering.
> > option to send a (hourly/daily) "firewall-report-message" to the 
> > administrator. With no external logserver available there are only a
> > limited number of records in the log. Changes are that the
> > administrator will never know the his systems where scanned or that
> > someone was trying something on a port that is closed. A VERY bad 
> > thing i would say.
> I for one have better things to do than finding out every day how many 
> people tried my NetBIOS ports. Better use an IDS (integrating one in 
> m0n0wall is being considered, but I won't promise anything).

I agree in part.  If the reports are user-configurable, then the user
can select to have, for example, reports of ONLY the "automatic block"
IPs as mentioned above.

A report of every scanned port will be overwhelming, and practically
useless.  It needs to be filtered somewhat.

> > There could be much more like Dos Attacks, PoD, Anti spoofing but
> Ping of Death? ICMP echo is blocked by default anyway, so those trying 
> to "ping you to death" will at most succeed in saturating your 
> downstream - something you cannot do anything about at all.

Yes.  And this is a concept that a lot of people do not understand. 
There is currently (almost) NOTHING that you can do if you are suffering
a DoS or DDoS attack from an address that is bandwidth-related.  If
someone with a 10mbps pipe tries to saturate your 2mbps pipe, they will
do it.  Simple.  Without technologies such as ECN, a DDoS (bandwidth)
attack will just have to be endured.  Of course, until ECN is
implemented by all router/firewall devices, and supoported by all ISPs,
then its benefits are limited (and its disadvantages can be

> About DoS... there might be the possibility of limiting the number of 
> connections per source IP address in the future - once more, when 
> ipfilter supports it.

http://www.securityfocus.com/infocus/1655 has an interesting article on
detecting and counteracting DDoS attacks.  Again, good defensive rules
come into play.

> Anti spoofing? Another vague term. m0n0wall already makes sure that no 
> spoofed source IP addresses appear on WAN (i.e. packets with source 
> addresses that claim to be from your LAN or an optional network) by default.

Yup - m0n0wall provides anti-spoofing (no internal IPs allowed to appear
inbound on the WAN/OPT interfaces.  This is what causes the "I cannot
get to my DMZ machines by their real-world addresses" issues that are
easily overcome by editing the /etc/hosts mappings on m0n0wall.



Hilton Travis                   Email: Hilton at QuarkAV dot com
Manager, Quark AudioVisual      Phone: +61-(0)7-3343-3889
         Quark Computers        Phone: +61-(0)419-792-394
(Brisbane, Australia)            http://www.QuarkAV.com/

Open Source Projects:		http://www.ares-desktop.org/

Non Linear Video Editing Solutions & Digital Audio Workstations
 Network Administration, SmoothWall Firewalls, NOD32 AntiVirus
  Conference and Seminar AudioVisual Production and Recording

War doesn't determine who is right. War determines who is left.