Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DMZ for logging

4 views
Skip to first unread message

Harry Putnam

unread,
Jan 29, 2012, 11:35:05 PM1/29/12
to
I hope to find experienced iptables users here who can tell me if this
idea is something I could setup with iptables.

I'd like to get a real good idea of what is coming at me from the
internet. Is there a technique where all incoming connections are
copied to a separate server that uses iptables to sort categorize and
log incoming traffic, but then drops it. At least the portion that is
at all suspect in any way.

After a while I would start to know what is just taking up log space
for no good reason and what is actually something likely to be
malicious in intent.

I want a first hand look at what comes down the pipe.

Enrico

unread,
Jan 30, 2012, 6:00:52 AM1/30/12
to
Il 30/01/2012 05:35, Harry Putnam ha scritto:
> Is there a technique where all incoming connections are
> copied to a separate server that uses iptables to sort categorize and
> log incoming traffic, but then drops it.

If you have the WAN on ethernet (from the router, for example) and your
traffic flow isn't big, you can setup a mirror port on a switch, if you
have one, then drop all traffic at the end of chains (policy action)
into the logging server (after LOG rules).

You need to assign all public IP to the "logging server" and make sure
that there are no connection attempts from that server out that
interface. Maybe you can only use "promisc" with "ifconfig", but I'm not
sure.

Enrico

J G Miller

unread,
Jan 30, 2012, 9:14:52 AM1/30/12
to
On Sunday, January 29th, 2012, at 23:35:05h -0500, Harry Putnam explained:

> I'd like to get a real good idea of what is coming at me from the
> internet.

Maybe you should be looking at ntop to do this?

<http://www.ntop.ORG/products/ntop/>

Harry Putnam

unread,
Jan 30, 2012, 9:40:15 AM1/30/12
to
How will ntop know about stuff that is blocked at the firewall that
ntop sits behind. Or do you mean ntop on a DMZ machine.

If so that is the topic here... how to setup a DMZ machine that just
logs and then drops incoming.

Dale Dellutri

unread,
Jan 30, 2012, 10:35:08 AM1/30/12
to
You can easily set up a log-before-drop rule using iptables itself,
and the logging then goes to wherever syslog sends kernel messages
(typically, on the machine running iptables). For example, on my
firewalls, the default rule for the INPUT chain is drop:
# Default policy: DROP
/sbin/iptables -P INPUT DROP
and then I have rules to accept all the traffic I want, and
finally a rule to log any traffic that remains (thus, unwanted):
# Log all else before default DROP
# (Perhaps add "-m limit" before -j LOG?)
/sbin/iptables -A INPUT -j LOG --log-prefix "iptables INPUT: "
Then, since the default policy is DROP, the packet is dropped.

In my case, the logging is done to /var/log/messages, for example:
Jan 29 20:17:24 <systemname> kernel: iptables INPUT: IN=eth1 OUT=
MAC=<macaddress> SRC=<ipaddress> DST=<ipaddress>
LEN=48 TOS=0x00 PREC=0x00 TTL=112 ID=61372 DF PROTO=TCP
SPT=3091 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0
I have logwatch running, and I get daily messages summarizing all
of the dropped messages, for example:
Logged 65 packets on interface eth1
From <ipaddress> - 1 packet to udp(5060)
From <ipaddress> - 1 packet to udp(5060)
From <ipaddress> - 5 packets to tcp(135)
...
So I have a good idea of which ip addresses are trying to
get in using whatever kinds of packets.

I also have logrotate running, so I keep 4 weeks worth of
/var/log/messages.

(The actual ip and mac addresses have been replaced with
<ipaddress> and <macaddress> in the notes above.)

I don't see why you need a DMZ machine for this.

--
Dale Dellutri <ddelQ...@panQQQix.com> (lose the Q's)

Harry Putnam

unread,
Jan 30, 2012, 10:34:29 AM1/30/12
to
Enrico <enri...@virgilio.it> writes:

> Il 30/01/2012 05:35, Harry Putnam ha scritto:
>> Is there a technique where all incoming connections are
>> copied to a separate server that uses iptables to sort categorize and
>> log incoming traffic, but then drops it.
>
> If you have the WAN on ethernet (from the router, for example) and
> your traffic flow isn't big, you can setup a mirror port on a switch,
> if you have one, then drop all traffic at the end of chains (policy
> action) into the logging server (after LOG rules).

I'm not following there about the mirror on a switch. Can you explain
a bit more?

> You need to assign all public IP to the "logging server" and make sure
> that there are no connection attempts from that server out that
> interface. Maybe you can only use "promisc" with "ifconfig", but I'm
> not sure.

I don't follow that either. Why do all public IP need to be assigned
to logging server... and if so how will any legitimate traffic get
thru to private lan?

My setup is pretty basic (except for the 2nd router I am fiddling
with being stuck awkwardly in there) and looks like this (roughly).

internet
|
Satellite modem
|
=== cisco WRT120 & firewall==
| | | | |
| | | | |
mob1 mob2 desktop mob3 router2 (WR1043ND)
2 nics |
| subnet
| |
|_____________________________|


The middle level there is on 192.168.1.0/24
subnet is on 192.168.2.0/24

One of the laptops (far left) has its wifi talking to net ..1.0/24 and
its ethernet port talking to net ..2.0/24

So the second router (far right) has its wan port connected to the
(cisco) lan router's lan port (router2 wan to router1 lan). 2nd
router's own lan ports are supplying the subnet 192.168.2.0

This is not supposed to be my attempt at the setup I'm asking about.
It's just me working on the 2nd router... adding openwrt router
software and familiarizing myself with iptables before I land myself
in hot water.

I think the setup I'm after would look about the same but would allow
only 1 lan port out, and a well filtered one. That would be to get at
the logs being compiled there.

Iptables would be running on 2nd router.


J G Miller

unread,
Jan 30, 2012, 10:51:10 AM1/30/12
to
On Mon, 30 Jan 2012 09:40:15 -0500, Harry Putnam wrote:

> Or do you mean ntop on a DMZ machine.

Yes that is what I meant.

> If so that is the topic here... how to setup a DMZ machine that just
> logs and then drops incoming.

The log and drop options on two IPTABLES rules then for the specified
type of package or incoming port?

Jorgen Grahn

unread,
Jan 30, 2012, 11:01:45 AM1/30/12
to
On Mon, 2012-01-30, Dale Dellutri wrote:
> On Sun, 29 Jan 2012 23:35:05 -0500, Harry Putnam <rea...@newsguy.com> wrote:
>> I hope to find experienced iptables users here who can tell me if this
>> idea is something I could setup with iptables.
>
>> I'd like to get a real good idea of what is coming at me from the
>> internet. Is there a technique where all incoming connections are
>> copied to a separate server that uses iptables to sort categorize and
>> log incoming traffic, but then drops it. At least the portion that is
>> at all suspect in any way.
>
>> After a while I would start to know what is just taking up log space
>> for no good reason and what is actually something likely to be
>> malicious in intent.
>
>> I want a first hand look at what comes down the pipe.
>
> You can easily set up a log-before-drop rule using iptables itself,
> and the logging then goes to wherever syslog sends kernel messages
> (typically, on the machine running iptables).
...
> I don't see why you need a DMZ machine for this.

It seems though that the OP wants to see /all/ traffic, not just what
stops in iptables. (Of course he can log e.g. all TCP SYNs without
dropping them.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn

unread,
Jan 30, 2012, 11:06:02 AM1/30/12
to
Or just a machine with an unconfigured eth0 attached to that mirroring
port. 'tcpdump -i eth0' and similar tools (ntop) should work nicely on
that setup, if that's the kind of tool he wants. And the machine will
be safe, since the IP/IPv6 stack will not care what happens on an
unconfigured interface.

Harry Putnam

unread,
Jan 31, 2012, 10:28:15 AM1/31/12
to
Dale Dellutri <ddelQ...@panQQQix.com> writes:

First, thanks to all posters for the input. Although I really
appreciate the input helpful effort.... I've ended up pretty confused
here.

I don't mean people have been unclear or the like, but that my own
weak understanding of what happens at firewalls, and how hacks get
through etc is a bit too thin for me to follow along easily.

> On Sun, 29 Jan 2012 23:35:05 -0500, Harry Putnam <rea...@newsguy.com> wrote:
>> I hope to find experienced iptables users here who can tell me if this
>> idea is something I could setup with iptables.
>
>> I'd like to get a real good idea of what is coming at me from the
>> internet. Is there a technique where all incoming connections are
>> copied to a separate server that uses iptables to sort categorize and
>> log incoming traffic, but then drops it. At least the portion that is
>> at all suspect in any way.
>
>> After a while I would start to know what is just taking up log space
>> for no good reason and what is actually something likely to be
>> malicious in intent.
>
>> I want a first hand look at what comes down the pipe.
>
> You can easily set up a log-before-drop rule using iptables itself,
> and the logging then goes to wherever syslog sends kernel messages
> (typically, on the machine running iptables). For example, on my
> firewalls, the default rule for the INPUT chain is drop:
> # Default policy: DROP
> /sbin/iptables -P INPUT DROP
> and then I have rules to accept all the traffic I want, and
> finally a rule to log any traffic that remains (thus, unwanted):
> # Log all else before default DROP
> # (Perhaps add "-m limit" before -j LOG?)
> /sbin/iptables -A INPUT -j LOG --log-prefix "iptables INPUT: "
> Then, since the default policy is DROP, the packet is dropped.

I think I follow that... not that I'd know how to set up, but ok, I
get the point there.

> In my case, the logging is done to /var/log/messages, for example:
> Jan 29 20:17:24 <systemname> kernel: iptables INPUT: IN=eth1 OUT=
> MAC=<macaddress> SRC=<ipaddress> DST=<ipaddress>
> LEN=48 TOS=0x00 PREC=0x00 TTL=112 ID=61372 DF PROTO=TCP
> SPT=3091 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0
> I have logwatch running, and I get daily messages summarizing all
> of the dropped messages, for example:
> Logged 65 packets on interface eth1
> From <ipaddress> - 1 packet to udp(5060)
> From <ipaddress> - 1 packet to udp(5060)
> From <ipaddress> - 5 packets to tcp(135)
> ...
> So I have a good idea of which ip addresses are trying to
> get in using whatever kinds of packets.

> I also have logrotate running, so I keep 4 weeks worth of
> /var/log/messages.
>
> (The actual ip and mac addresses have been replaced with
> <ipaddress> and <macaddress> in the notes above.)

So in general you are running/maintaining your own iptables setup right?

> I don't see why you need a DMZ machine for this.

I probably stated it badly in OP but I'm basically chicken and
doubtful of my own running/maintaining and fiddling with THE
firewall. (In my case its just a home lan, no commercial scale stuff
at all)

So I'm looking for a way to leave that job to a storebought setup that
I set and forget. (WR120N) but it has no logging capability (other
than login to it and manually view logs)

But behind that, (as in posted diagram), comes a custom setup using
openwrt on a WR1043ND.

So I'm asking how to send copies of everything that hits the firewall
to that 2nd router and have it setup so it is NOT an entry point for
malicious stuff, but is able to log such stuff and drop it.

So it would drop everything but also log and email or log to syslog
(in this case rsyslog) anything suspicious, not necessarily just log
everything, but filter it in some sensible way.

So in summary: I want some secure way to look through whatever is
coming at me, and I hope to learn enough about iptables and openwrt to
run my own setup from this activity.

Two people have mentioned `mirroring' a port. What does it actually
mean and how would it look in a diagram? Just a text style rough idea.

OH, and how would I set it up so that the wan (outward) side of this
experimental setup is getting all traffic (a copy of it) but the lan
side will allow me to login or allow emailing logs to me, but will
offer no other kind of ingress.

Enrico

unread,
Jan 31, 2012, 2:26:23 PM1/31/12
to
Il 31/01/2012 16:28, Harry Putnam ha scritto:
> Two people have mentioned `mirroring' a port. What does it actually
> mean and how would it look in a diagram? Just a text style rough idea.

A simple schematic:

WAN (ISP)
|
|
Ethernet Switch
|
|
Router/Firewall


If you have this situation (and you have a decent switch), you can
reconfigure your switch to "mirror" a port, eg. copy everything from
port X to Y. So:

WAN (ISP)
|
|
Ethernet Switch
X/ \Y
/ \
Router/FW Logging Server


Most switches have the capability to stop incoming traffic from mirrored
Y port, so your logging server will be passive.

In this case the switch literally do a raw copy of packets that are
incoming/outgoing over port X to port Y, just like you're watching the
traffic flow directly into the cable.

How configure that depends on your switch.

PS: sorry for my bad english.

Enrico
0 new messages