Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #1022 > unrolled thread

DMZ for logging

Back to article view | Back to comp.os.linux.networking

Contents

  DMZ for logging Harry Putnam <reader@newsguy.com> - 2012-01-29 23:35 -0500
    Re: DMZ for logging Enrico <enrico204@virgilio.it> - 2012-01-30 12:00 +0100
      Re: DMZ for logging Harry Putnam <reader@newsguy.com> - 2012-01-30 10:34 -0500
    Re: DMZ for logging J G Miller <miller@yoyo.ORG> - 2012-01-30 14:14 +0000
      Re: DMZ for logging Harry Putnam <reader@newsguy.com> - 2012-01-30 09:40 -0500
        Re: DMZ for logging J G Miller <miller@yoyo.ORG> - 2012-01-30 15:51 +0000
          Re: DMZ for logging Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-30 16:06 +0000
    Re: DMZ for logging Dale Dellutri <ddelQQQlutr@panQQQix.com> - 2012-01-30 15:35 +0000
      Re: DMZ for logging Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-30 16:01 +0000
      Re: DMZ for logging Harry Putnam <reader@newsguy.com> - 2012-01-31 10:28 -0500
        Re: DMZ for logging Enrico <enrico204@virgilio.it> - 2012-01-31 20:26 +0100

#1022 — DMZ for logging

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.

[toc] | [next] | [standalone]

#1023

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

[toc] | [prev] | [next] | [standalone]

#1027

Enrico <enrico204@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.

 

[toc] | [prev] | [next] | [standalone]

#1024

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/>

[toc] | [prev] | [next] | [standalone]

#1025

J G Miller <miller@yoyo.ORG> writes:

> 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/>

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.

[toc] | [prev] | [next] | [standalone]

#1028

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?

[toc] | [prev] | [next] | [standalone]

#1031

On Mon, 2012-01-30, J G Miller wrote:
> 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?

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.

/Jorgen

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

[toc] | [prev] | [next] | [standalone]

#1026

On Sun, 29 Jan 2012 23:35:05 -0500, Harry Putnam <reader@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.

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 <ddelQQQlutr@panQQQix.com> (lose the Q's)

[toc] | [prev] | [next] | [standalone]

#1029

On Mon, 2012-01-30, Dale Dellutri wrote:
> On Sun, 29 Jan 2012 23:35:05 -0500, Harry Putnam <reader@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   .

[toc] | [prev] | [next] | [standalone]

#1036

Dale Dellutri <ddelQQQlutr@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 <reader@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.

[toc] | [prev] | [next] | [standalone]

#1037

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web