On 6/16/2014 8:52 PM, Chuck Campbell wrote:
> I ran a script after fail2ban was started. It looks like this:
> #!/bin/sh
> iptables -A INPUT -s 116.10.191.0/24 -j DROP
> iptables -A INPUT -s 183.136.220.0/24 -j DROP
> iptables -A INPUT -s 183.136.221.0/24 -j DROP
> iptables -A INPUT -s 183.136.222.
>>>
>>>
>> As John R Pierce mentioned one of your first rule in the chain is
>> "RH-Firewall-1-INPUT all -- anywhere anywhere", this
>> simply mean everything with "DROP" after it will be ignored. iptables
>> will work its way down the chain, therefore you have to options
>> 1. remo
On 6/16/2014 9:44 PM, Earl Ramirez wrote:
> On Mon, 2014-06-16 at 21:42 -0500, Chuck Campbell wrote:
>> All of the suggestions are graciously accepted, however, I was actually
>> asking
>> what I was doing wrong with iptables, and why, with the rules I put in place,
>> someone was still able to co
On Mon, 2014-06-16 at 21:42 -0500, Chuck Campbell wrote:
> All of the suggestions are graciously accepted, however, I was actually
> asking
> what I was doing wrong with iptables, and why, with the rules I put in place,
> someone was still able to connect to my machine.
>
> I understand there m
All of the suggestions are graciously accepted, however, I was actually asking
what I was doing wrong with iptables, and why, with the rules I put in place,
someone was still able to connect to my machine.
I understand there might be better ways, but if I don't understand what I did
wrong last
[previous article hasn't appeared on gmane yet]
On 2014-06-16, Eliezer Croitoru wrote:
> On 06/17/2014 01:46 AM, Bret Taylor wrote:
>> Get rid of fail2ban, it's not needed. Just write a proper firewall.
> Are you series??
> There are applications that fail2ban offers them things which others
> j
On 06/17/2014 01:46 AM, Bret Taylor wrote:
> Get rid of fail2ban, it's not needed. Just write a proper firewall.
Are you series??
There are applications that fail2ban offers them things which others
just can't..
If you can email me the ip for your servers and also the root password
and allow me
On 06/17/2014 01:11 AM, John R Pierce wrote:
> On 6/16/2014 2:58 PM, Chuck Campbell wrote:
>> >Chain INPUT (policy ACCEPT)
>> >target prot opt source destination
>> >fail2ban-VSFTPD tcp -- anywhere anywheretcp
>> >dpt:ftp
>> >fail2ban-SSH tcp -- anyw
On 6/16/2014 2:58 PM, Chuck Campbell wrote:
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> fail2ban-VSFTPD tcp -- anywhere anywheretcp dpt:ftp
> fail2ban-SSH tcp -- anywhere anywheretcp dpt:ssh
> RH-Firewa
On Mon, 16 Jun 2014 16:58:18 -0500
Chuck Campbell wrote:
> Why is this ip range still able to attempt connections? Have I done something
> wrong with my address ranges, or added them in the wrong place?
Have you considered taking the opposite approach and allowing only the IP
addresses that you
On Mon, 2014-06-16 at 16:58 -0500, Chuck Campbell wrote:
> I'm running fail2ban to attempt to block malicious brute-force password
> dictionary attacks against ssh.
You could:-
(1) Change the SSHD port to something obscure.
(2) Restrict access to the SSHD port, using iptables, to a group of
ap
I'm running fail2ban to attempt to block malicious brute-force password
dictionary attacks against ssh. They seem to be rolling through a block of ip
addresses as the source to defeat this kind of screening, so I've set some ip
addresses to be blocked in iptables. Here is the output of iptables -L
On 16/06/14 02:55 PM, m.r...@5-cent.us wrote:
> Digimer wrote:
>> On 16/06/14 02:19 PM, John R Pierce wrote:
>>> On 6/16/2014 10:55 AM, Digimer wrote:
The main downside to fabric fencing is that the failed node will have
no
chance of recovering without human intervention. Further, it
Digimer wrote:
> On 16/06/14 02:19 PM, John R Pierce wrote:
>> On 6/16/2014 10:55 AM, Digimer wrote:
>>> The main downside to fabric fencing is that the failed node will have
>>> no
>>> chance of recovering without human intervention. Further, it places the
>>> onus on the admin to not simply unfen
On 16/06/14 02:19 PM, John R Pierce wrote:
> On 6/16/2014 10:55 AM, Digimer wrote:
>> The main downside to fabric fencing is that the failed node will have no
>> chance of recovering without human intervention. Further, it places the
>> onus on the admin to not simply unfence the node without first
On 6/16/2014 10:55 AM, Digimer wrote:
> The main downside to fabric fencing is that the failed node will have no
> chance of recovering without human intervention. Further, it places the
> onus on the admin to not simply unfence the node without first doing
> proper cleanup/recovery. For these reas
On 6/16/2014 10:13 AM, m.r...@5-cent.us wrote:
> Chuck Campbell wrote:
>> I've recently built a new mail server with centos6.5, and decided to bite
>> the bullet and leave SELinux running. I've stumbled through making
> things work
>> and am mostly there.
>>
>> I've got my own spam and ham corpus a
On 16/06/14 01:36 PM, John R Pierce wrote:
> On 6/16/2014 2:39 AM, Alessandro Baggi wrote:
>> Hi Digimer,
>> there is a chance to make fencing without hardware, but only software?
>
> the most common fence in TCP connected systems is to disable the
> ethernet ports of the fenced system, done via a
On 6/16/2014 2:39 AM, Alessandro Baggi wrote:
> Hi Digimer,
> there is a chance to make fencing without hardware, but only software?
the most common fence in TCP connected systems is to disable the
ethernet ports of the fenced system, done via a 'smart ethernet
switch'. if you're using shared
On 06/16/2014 11:13 AM, m.r...@5-cent.us wrote:
> Chuck Campbell wrote:
>> I've recently built a new mail server with centos6.5, and decided to bite
>> the bullet and leave SELinux running. I've stumbled through making
> things work
>> and am mostly there.
>>
>> I've got my own spam and ham corpus
On a running system, I was just logging in, and it took for-bloody-ever. I
run top, and ok, a load of 5 still shouldn't do that; we have folks that
do put real loads on these systems. But top shows me power_saving
frequently coming to the top, with a 94% - 100% CPU usage, and there's two
threads of
Chuck Campbell wrote:
>
> I've recently built a new mail server with centos6.5, and decided to bite
> the bullet and leave SELinux running. I've stumbled through making
things work
> and am mostly there.
>
> I've got my own spam and ham corpus as mbox files in
> /home/user/Mail/learned.
> These fil
Dan Hyatt wrote:
>I worked in the SSD lab at STEC for a while, testing SSD's and fixing
> SSD's that failed...
> I knew how to blow up the drives, run them well beyond the capacity of
> spinner drives. But then I would flash the firmware and the drive would
> be good as new. I would be runnin
I've recently built a new mail server with centos6.5, and decided to bite the
bullet and leave SELinux running. I've stumbled through making things work and
am mostly there.
I've got my own spam and ham corpus as mbox files in /home/user/Mail/learned.
These files came from my backup of the cen
I worked in the SSD lab at STEC for a while, testing SSD's and fixing
SSD's that failed...
When I was working in the lab on the Zuess drives (First enterprise
class SSD drive) . When the drives came back from our customers hosed,
all we had to do was re-flash the firmware (helps if you have
No. For fencing to be worthwhile, it *must* work when the node is in any
state. For this, it must be independent of node. A great way to see why
is to test crashing the node (echo c > /proc/sysrq-trigger) or simply
cutting the power to the node. With the node totally disabled, the
surviving pee
Hi Digimer,
there is a chance to make fencing without hardware, but only software?
Il 15/06/2014 17:28, Digimer ha scritto:
> On 15/06/14 08:54 AM, Alessandro Baggi wrote:
>> Another question is about fencing. I've ridden that a cluster must have
>> fencing to be considered as such. On CentOS 6.5
27 matches
Mail list logo
