Am 31.08.2011 15:18, schrieb Always Learning:
>>> uname -a = 2.6.35.4 #2 (don't know how this got installed)
>
>> This is not a CentOS-provided kernel; as has been said elsewhere
>> in the thread, this is likely an OpenVZ kernel. Your hosting
No stock OpenVZ kernel, see http://download.openvz.
Am 31.08.2011 15:35, schrieb Karanbir Singh:
>> PS: To install iptables from source is pretty straightforward:
>> get the tarball from netfilter.org, unpack and run:
>> ./configure --prefix=/opt/iptables&& make&& make install
>
> And at that point you lose. All management capability or
On 01/09/11 00:28, Always Learning wrote:
>
> On Wed, 2011-08-31 at 16:11 -0700, Craig White wrote:
>> More to the point, he disables SELinux and then spends hours trying to
>> improve security.
>
> Tell the world the ENTIRE story.
>
> Disabled it because things would not run. Said publicly in the
On Wed, 2011-08-31 at 18:06 -0700, John R Pierce wrote:
> On 08/31/11 4:28 PM, Always Learning wrote:
> > Disabled it because things would not run.
>
> Always Talking. Never Learning.
Always Learning despite the taunts !
Paul.
___
CentOS mailing li
On 08/31/11 4:28 PM, Always Learning wrote:
> Disabled it because things would not run.
Always Talking. Never Learning.
--
john r pierceN 37, W 122
santa cruz ca mid-left coast
___
CentOS mailing
On Thu, Sep 01, 2011 at 12:28:01AM +0100, Always Learning wrote:
>
> Tell the world the ENTIRE story.
That you never listen to anyone but yourself? I'm confident that this
is a known fact.
> I am trying to filter-out some web page access attepts in IP Tables.
> When will you accept that has no
On Wed, 2011-08-31 at 16:11 -0700, Craig White wrote:
> More to the point, he disables SELinux and then spends hours trying to
> improve security.
Tell the world the ENTIRE story.
Disabled it because things would not run. Said publicly in the last 7
days will find time to learn about Selinux an
On Aug 31, 2011, at 1:08 PM, Louis Lagendijk wrote:
> On Wed, 2011-08-31 at 19:00 +0100, Always Learning wrote:
>> On Wed, 2011-08-31 at 13:55 -0400, Lamar Owen wrote:
>>
>>> On Wednesday, August 31, 2011 01:33:31 PM Always Learning wrote:
Rather than being a willing or passive victim to 10
On Wed, 2011-08-31 at 22:08 +0200, Louis Lagendijk wrote:
> On Wed, 2011-08-31 at 19:00 +0100, Always Learning wrote:
> > On Wed, 2011-08-31 at 13:55 -0400, Lamar Owen wrote:
> >
> > > On Wednesday, August 31, 2011 01:33:31 PM Always Learning wrote:
> > > > Rather than being a willing or passive v
On Wed, 2011-08-31 at 19:00 +0100, Always Learning wrote:
> On Wed, 2011-08-31 at 13:55 -0400, Lamar Owen wrote:
>
> > On Wednesday, August 31, 2011 01:33:31 PM Always Learning wrote:
> > > Rather than being a willing or passive victim to 100% of the attacks, I
> > > aim to reduce the penetrabilit
On Wed, 2011-08-31 at 13:55 -0400, Lamar Owen wrote:
> On Wednesday, August 31, 2011 01:33:31 PM Always Learning wrote:
> > Rather than being a willing or passive victim to 100% of the attacks, I
> > aim to reduce the penetrability of most of them.
> Getting the last 10% will cost you 90% of you
On Wednesday, August 31, 2011 01:33:31 PM Always Learning wrote:
> Rather than being a willing or passive victim to 100% of the attacks, I
> aim to reduce the penetrability of most of them.
Getting the last 10% will cost you 90% of your time.
___
CentOS
On Wed, 2011-08-31 at 10:38 -0700, John R Pierce wrote:
> On 08/31/11 10:33 AM, Always Learning wrote:
> > Rather than being a willing or passive victim to 100% of the attacks, I
> > aim to reduce the penetrability of most of them.
>
> an attempted access of a non-vunerability won't be any more e
On 08/31/11 10:33 AM, Always Learning wrote:
> Rather than being a willing or passive victim to 100% of the attacks, I
> aim to reduce the penetrability of most of them.
an attempted access of a non-vunerability won't be any more effective
the millionth time its run than the first time. its the
On Wed, 2011-08-31 at 13:01 -0400, Lamar Owen wrote:
> On today's Internet you are simply not going to catch 100% of the
> attacks, full stop.
Rather than being a willing or passive victim to 100% of the attacks, I
aim to reduce the penetrability of most of them.
Paul.
__
On Wed, Aug 31, 2011 at 12:17 PM, John R Pierce wrote:
>> Wrong. Some can be determined by machine searching for 'known' invalid
>> URL strings which are not remotely similar to valid web page names.
>
> there's an infinite number of invalid strings, and only a finite number
> of valid ones.
>
> a
On Wed, 2011-08-31 at 10:17 -0700, John R Pierce wrote:
> anyways, your webserver already filters these out, its not going to
> respond to an invalid URL with anything other than '404'. thats its
> job.
The 'error' is trapped; a PHP routine examines the URL for known (in a
list) hacker strings
On 08/31/11 9:32 AM, Always Learning wrote:
> Wrong. Some can be determined by machine searching for 'known' invalid
> URL strings which are not remotely similar to valid web page names.
there's an infinite number of invalid strings, and only a finite number
of valid ones.
anyways, your webserve
On Wednesday, August 31, 2011 11:15:20 AM Always Learning wrote:
> Dangerous to ignore any background noise - far better to
> firmly shut the door and fill-in all known holes.
The unknown holes are the ones that will get you.
You are also setting yourself up for a denial-of-service vector. Refr
On Wed, 2011-08-31 at 09:11 -0700, John R Pierce wrote:
> iptables will filter on packet headers and such at layer 3, it can't
> and won't analyze the content of packets, regardless of your emotional
> attachments.
I believe IP Tables '-m string' will. If you think the custodians and
maintainers
UPDATE:
I started with kernel 2.6.35.4 #2 and lsmod | grep ipt = ipt_LOG 5419 2.
My service provider produced a replacement kernel 2.6.24-28-xen #1.
Now lsmod | grep ipt reveals ..
ipt_LOG 8192 2
iptable_filter 4608 1
ip_tables 24232 1 iptable_f
On 08/31/11 9:00 AM, Always Learning wrote:
> No I do not want "another piece of software to parse the http protocol
> and analyze the traffic".
>
> IT Tables, in which I have great confidence and trust, can do it.
iptables will filter on packet headers and such at layer 3, it can't and
won't an
On Wed, 2011-08-31 at 11:51 -0400, Bowie Bailey wrote:
> On 8/31/2011 11:32 AM, Always Learning wrote:
> > On Wed, 2011-08-31 at 11:29 -0400, Bowie Bailey wrote:
> >
> >> I assume this is an Apache server. Have you looked at mod_security
> >> (http://www.modsecurity.org/)? It is available from t
On Wed, 2011-08-31 at 08:41 -0700, John R Pierce wrote:
> On 08/31/11 8:22 AM, Always Learning wrote:
> > Looking at your example seems to suggest Fail2Ban is an 'after the
> > event' response. I would like to implement 'before the event' filtering
> > which prevents, even on the first detected h
On 8/31/2011 11:32 AM, Always Learning wrote:
> On Wed, 2011-08-31 at 11:29 -0400, Bowie Bailey wrote:
>
>> I assume this is an Apache server. Have you looked at mod_security
>> (http://www.modsecurity.org/)? It is available from the epel
>> repository. There is a bit of a learning curve to get
On 08/31/11 8:22 AM, Always Learning wrote:
> Looking at your example seems to suggest Fail2Ban is an 'after the
> event' response. I would like to implement 'before the event' filtering
> which prevents, even on the first detected hacking attempt, anything
> reaching HTTPD.
so you want another pi
Always Learning wrote:
>
> On Wed, 2011-08-31 at 11:16 -0400, m.r...@5-cent.us wrote:
>
>> Maybe not, for a small website. However, let me re-suggest fail2ban,
>> with
>> three lines from one of our config files:
>> failregex = -.*"GET
>> .*(php|pma|PMA|p/m/a|db|sql|admin).*/(config/c
>> onf
On Wed, 2011-08-31 at 11:29 -0400, Bowie Bailey wrote:
> I assume this is an Apache server. Have you looked at mod_security
> (http://www.modsecurity.org/)? It is available from the epel
> repository. There is a bit of a learning curve to get it running, but
> it protects against a ton of hack
On 8/31/2011 11:22 AM, Always Learning wrote:
> On Wed, 2011-08-31 at 11:16 -0400, m.r...@5-cent.us wrote:
>
>> Maybe not, for a small website. However, let me re-suggest fail2ban, with
>> three lines from one of our config files:
>> failregex = -.*"GET .*(php|pma|PMA|p/m/a|db|sql|admin).*/(config
On Wed, 2011-08-31 at 11:16 -0400, m.r...@5-cent.us wrote:
> Maybe not, for a small website. However, let me re-suggest fail2ban, with
> three lines from one of our config files:
> failregex = -.*"GET .*(php|pma|PMA|p/m/a|db|sql|admin).*/(config/c
> onfig\.inc|main)\.php.*".*404.*
>
John R Pierce wrote:
> On 08/31/11 7:22 AM, Always Learning wrote:
>> In the current 4,000 to 6,000 daily hits, the lunatic uses
>>
>> login.php
>> contact.php
>> forgotten_password.php
>
> your 'lunatic' aka 'hacker' is undoubtably a blind script ('bot')
> running on distributed pre
On Wed, 2011-08-31 at 08:07 -0700, John R Pierce wrote:
> On 08/31/11 7:22 AM, Always Learning wrote:
> > In the current 4,000 to 6,000 daily hits, the lunatic uses
> >
> > login.php
> > contact.php
> > forgotten_password.php
>
> your 'lunatic' aka 'hacker' is undoubtably a blind scr
On 08/31/11 7:22 AM, Always Learning wrote:
> In the current 4,000 to 6,000 daily hits, the lunatic uses
>
> login.php
> contact.php
> forgotten_password.php
your 'lunatic' aka 'hacker' is undoubtably a blind script ('bot')
running on distributed previously hacked hosts, and pro
Hi Mike,
> Perhaps the most important point here is that the script kiddies and/or
> bots usually make sure the target string, 'login' in your example is *not*
> contained within a single packet. You can verify this with wireshark. In
> any case just be aware that your solution will likely n
On Wed, 2011-08-31 at 09:54 -0400, Lamar Owen wrote:
> It's less than ideal to install anything from source, as Karanbir
> has so correctly pointed out downthread.
>
> Sometimes it is necessary; but it is never ideal, for the reasons KB
> stated
The service provider has suggested it needs the x
Perhaps the most important point here is that the script kiddies and/or
bots usually make sure the target string, 'login' in your example is *not*
contained within a single packet. You can verify this with wireshark. In
any case just be aware that your solution will likely not have the desired
On Wednesday, August 31, 2011 09:18:26 AM Always Learning wrote:
> A very helpful and knowledgeable poster, Walter Haidinger, in his email
> dated Wed, 31 Aug 2011 13:10:16 +0200 (12:10 BST), gave what appears to
> be an ideal solution.
> * get a more recent iptables from netfilter.org
It's
On 08/31/2011 12:10 PM, Walter Haidinger wrote:
> PS: To install iptables from source is pretty straightforward:
> get the tarball from netfilter.org, unpack and run:
> ./configure --prefix=/opt/iptables&& make&& make install
And at that point you lose. All management capability or the
On Wed, 2011-08-31 at 09:01 -0400, Lamar Owen wrote:
> On Tuesday, August 30, 2011 10:24:41 PM Always Learning wrote:
> > uname -a = 2.6.35.4 #2 (don't know how this got installed)
> This is not a CentOS-provided kernel; as has been said elsewhere
> in the thread, this is likely an OpenVZ ke
On Tuesday, August 30, 2011 10:24:41 PM Always Learning wrote:
> On a VPS I wanted to add to IP tables:-
> iptables -A -p tcp -m string --algo bm --string 'login' -j DROP
> iptables: Unknown error 18446744073709551615
> uname -a = 2.6.35.4 #2 (don't know how this got installed)
This
Am 31.08.2011 04:24, schrieb Always Learning:
>
> On a VPS I wanted to add to IP tables:-
> iptables -A -p tcp -m string --algo bm --string 'login' -j DROP
>
> I got:
> iptables: Unknown error 18446744073709551615
>
> uname -a = 2.6.35.4 #2 (don't know how this got installed)
> lsmod
On Tue, Aug 30, 2011 at 10:24 PM, Always Learning wrote:
>
> On a VPS I wanted to add to IP tables:-
>
> iptables -A -p tcp -m string --algo bm --string 'login' -j DROP
>
> I got:
>
> iptables: Unknown error 18446744073709551615
>
> uname -a = 2.6.35.4 #2 (don't know how this got ins
On Wed, Aug 31, 2011 at 04:43:46AM +0100, Always Learning wrote:
> That you for the useful enlightenment. I was unaware it was an OpenVZ. I
> thought is was XEN on Ubuntu.
Next time, try posting more usefull information stating that you are indeed
running CentOS on a CentOS support mailing list an
> Are you a dog lover ? I like dogs too. They usually bark at strangers.
> Paul.
PLONK
see also http://en.wikipedia.org/wiki/Plonk_%28Usenet%29
best regards
---
Michael
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/li
On Tue, 2011-08-30 at 23:08 -0500, John R. Dennison wrote:
> Sigh.
>
> Can you please stop barking?
Are you a dog lover ? I like dogs too. They usually bark at strangers.
Paul.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/ma
On Wed, Aug 31, 2011 at 04:54:33AM +0100, Always Learning wrote:
>
> Thanks for confirming that again. Its really nice of you to keep
> reminding me.
Sigh.
Can you please stop barking? Your need to get the last word in on EVERY
thread is more than a little annoying. Just to end this, you can b
On Tue, 2011-08-30 at 22:41 -0500, John R. Dennison wrote:
> The choice is indeed yours.
Thanks for confirming that again. Its really nice of you to keep
reminding me.
> You can 1) listen to those that know what
> they are talking about and probably have 50 years of combined experience;
> or
On Wed, 2011-08-31 at 13:30 +1000, Steve Walsh wrote:
> They have not been included, probably because you are running an openVZ
> 'stab' kernel. Failing to give us the complete output in your initial
> post means that anyone helping you is taking blind guesses.
That you for the useful enlighte
On Wed, Aug 31, 2011 at 04:30:37AM +0100, Always Learning wrote:
>
> Thank you for informing me the 'choice' is mine. Without such undoubted
> inspirational wisdom I would never have known I had a choice. I am most
> grateful to you.
The choice is indeed yours. You can 1) listen to those that kn
On Tue, 2011-08-30 at 22:22 -0500, John R. Dennison wrote:
> On Wed, Aug 31, 2011 at 04:17:36AM +0100, Always Learning wrote:
> >
> > NO I will not. I have already emailed them.
>
> Then you won't get the support. Period.
Utter rubbish. They are excellent either by phone or by email.
> It's
On 08/31/2011 01:17 PM, Always Learning wrote:
> NO I will not. I have already emailed them.
wowjust...wow.
> The necessary IP Tables facilities are not available. Therefore,
> contrary to your strange assertion "Has nothing to do with being
> up-to-date" that IP Tables version is certain O
On Wed, Aug 31, 2011 at 04:17:36AM +0100, Always Learning wrote:
>
> NO I will not. I have already emailed them.
Then you won't get the support. Period.
> The necessary IP Tables facilities are not available. Therefore,
> contrary to your strange assertion "Has nothing to do with being
> up-to-
On Tue, 2011-08-30 at 22:11 -0500, John R. Dennison wrote:
> On Wed, Aug 31, 2011 at 04:07:44AM +0100, Always Learning wrote:
> >
> > Have already done that. I'm getting about 6,000 web hits a day (all
> > wrong URLs) from a lunatic who I can stop in IP Tables but only if the
> > alleged Centos
On Wed, Aug 31, 2011 at 04:07:44AM +0100, Always Learning wrote:
>
> Have already done that. I'm getting about 6,000 web hits a day (all
> wrong URLs) from a lunatic who I can stop in IP Tables but only if the
> alleged Centos version is up-to-date.
Has nothing to do with being up-to-date; it has
On Wed, 2011-08-31 at 13:02 +1000, Steve Walsh wrote:
> I'm wagering that's not the full output of uname -a. As far as I'm
> aware, centos have never shipped a 2.6.35 kernel with any release, and
> that's the sort of error you get with a openVZ "stab" (or Stable)
> kernel, where unless the hos
On 08/31/2011 12:24 PM, Always Learning wrote:
> On a VPS I wanted to add to IP tables:-
>
> iptables -A -p tcp -m string --algo bm --string 'login' -j DROP
>
> I got:
>
> iptables: Unknown error 18446744073709551615
>
> uname -a = 2.6.35.4 #2 (don't know how this got installed)
I'm
On a VPS I wanted to add to IP tables:-
iptables -A -p tcp -m string --algo bm --string 'login' -j DROP
I got:
iptables: Unknown error 18446744073709551615
uname -a = 2.6.35.4 #2 (don't know how this got installed)
lsmod | grep ipt = ipt_LOG 5419 2
yum upgrade iptables* =
57 matches
Mail list logo