Is it stupid when someone is trying to get on your box, leaves the ip and has a website on that ip ;-)
sshd: Authentication Failures: root (200.89.15.72): 59 Time(s) unknown (200.89.15.72): 42 Time(s) adm (200.89.15.72): 2 Time(s) apache (200.89.15.72): 1 Time(s) mysql (200.89.15.72): 1 Time(s) nobody (200.89.15.72): 1 Time(s) operator (200.89.15.72): 1 Time(s)
Hello, Justin Conover.
On 08.08.2005 17:45 you said the following:
Is it stupid when someone is trying to get on your box, leaves the ip and has a website on that ip ;-)
May be it's not a someone's IP. Probably it's a gateway with NAT and http service, and may be there are 1000 users behind that NAT.
On 8/8/05, Boris B. Zhmurov bb@kernelpanic.ru wrote:
Hello, Justin Conover.
On 08.08.2005 17:45 you said the following:
Is it stupid when someone is trying to get on your box, leaves the ip and has a website on that ip ;-)
May be it's not a someone's IP. Probably it's a gateway with NAT and http service, and may be there are 1000 users behind that NAT.
-- Boris B. Zhmurov mailto: bb@kernelpanic.ru "wget http://kernelpanic.ru/bb_public_key.pgp -O - | gpg --import"
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
Very true
OrgName: Latin American and Caribbean IP address Regional Registry OrgID: LACNIC Address: Potosi 1517 City: Montevideo StateProv: PostalCode: 11500 Country: UY
ReferralServer: whois://whois.lacnic.net
NetRange: 200.0.0.0 - 200.255.255.255 CIDR: 200.0.0.0/8 NetName: LACNIC-200 NetHandle: NET-200-0-0-0-1 Parent: NetType: Allocated to LACNIC NameServer: NS.LACNIC.NET NameServer: TINNIE.ARIN.NET NameServer: NS-SEC.RIPE.NET NameServer: SEC3.APNIC.NET NameServer: NS2.DNS.BR Comment: This IP address range is under LACNIC responsibility for further Comment: allocations to users in LACNIC region. Comment: Please see http://www.lacnic.net/ for further details, or check the Comment: WHOIS server located at whois.lacnic.net RegDate: 2002-07-27 Updated: 2005-03-29
OrgTechHandle: LACNIC-ARIN OrgTechName: LACNIC Whois Info OrgTechPhone: (+55) 11 5509-3522 OrgTechEmail: whois-contact@lacnic.net
# ARIN WHOIS database, last updated 2005-08-07 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database.
man, 08.08.2005 kl. 15.53 skrev Boris B. Zhmurov:
Hello, Justin Conover.
On 08.08.2005 17:45 you said the following:
Is it stupid when someone is trying to get on your box, leaves the ip and has a website on that ip ;-)
May be it's not a someone's IP. Probably it's a gateway with NAT and http service, and may be there are 1000 users behind that NAT.
Or somebodys hacked box. Send them a mail - often they do not know that they are being exploited, and are quite gratefull.
Or mail their ISP. That also tends to stop it...
"JC" == Justin Conover justin.conover@gmail.com writes:
JC> Is it stupid when someone is trying to get on your box, leaves the JC> ip and has a website on that ip ;-)
Yes, but most of these hosts have been hacked and are just running automated tools to find other hackable boxes.
To protect yourself, install denyhosts from extras, tune it to your environment and enjoy the satisfaction of having these be blocked automatically.
I hope to have an updated version of denyhosts checked into extras soon.
- J<
On 8/8/05, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"JC" == Justin Conover justin.conover@gmail.com writes:
JC> Is it stupid when someone is trying to get on your box, leaves the JC> ip and has a website on that ip ;-)
Yes, but most of these hosts have been hacked and are just running automated tools to find other hackable boxes.
To protect yourself, install denyhosts from extras, tune it to your environment and enjoy the satisfaction of having these be blocked automatically.
I hope to have an updated version of denyhosts checked into extras soon.
- J<
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
Very nice
Justin Conover schrieb:
On 8/8/05, Jason L Tibbitts III tibbs@math.uh.edu wrote:
>"JC" == Justin Conover justin.conover@gmail.com writes:
JC> Is it stupid when someone is trying to get on your box, leaves the JC> ip and has a website on that ip ;-)
Yes, but most of these hosts have been hacked and are just running automated tools to find other hackable boxes.
To protect yourself, install denyhosts from extras, tune it to your environment and enjoy the satisfaction of having these be blocked automatically.
I hope to have an updated version of denyhosts checked into extras soon.
- J<
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
Very nice
the easiest would be, telling iptables not allowing connection to port 22 for given hosts - known as stealthing ports ;-)
Since i do that, i have no longer 100s of entries in my logs. The firewall automatically drops all ssh-connection-tries not coming from this ip.
iptables -I RH-Firewall-1-INPUT 10 -p tcp -s 192.168.0.10 --dport 22 -j ACCEPT
e.g. this would allow ssh-access from 192.168.0.10 to this machine only. all others would get "no route to host". since this, i have no more brute-force-attacks against ssh on my server.
would be nice, having this in system-config-securitylevel ;-)
Roger
That's also why I don't put SSH on the standard port - that raises the bar so that the average script kiddie won't find it, and thus filters out the bulk of the crap.
Of course, that is no substitute for taking other security measures, such as locking out hosts that have too many login failures, requiring the use of keypairs rather than using password authentication, and so on.
Hi - What exactly is denyhosts? I've been seeing things like this on my machine at home, and I've been manually adding rules to my firewall to keep them from coming back... Something that does it automatically would be very useful to me...
I'm running FC3 on my firewall machine at home. Can I do a 'yum install denyhosts'? Is there documentation on how to configure it? I'll look around on the web today and see what I can find on my own. But any pointers or info you can give me would be appreciated...
Thanks,
nbc
On Mon, 2005-08-08 at 09:25 -0500, Jason L Tibbitts III wrote:
"JC" == Justin Conover justin.conover@gmail.com writes:
JC> Is it stupid when someone is trying to get on your box, leaves the JC> ip and has a website on that ip ;-)
Yes, but most of these hosts have been hacked and are just running automated tools to find other hackable boxes.
To protect yourself, install denyhosts from extras, tune it to your environment and enjoy the satisfaction of having these be blocked automatically.
I hope to have an updated version of denyhosts checked into extras soon.
- J<
"NBC" == Neil B Cohen nbc@cisco.com writes:
NBC> Hi - What exactly is denyhosts?
yum info denyhosts
Setting up Repos Reading repository metadata in from local files base : ################################################## 1667/1667 updates : ################################################## 966/966 local : ################################################## 70/70 extras : ################################################## 1177/1177 Available Packages Name : denyhosts Arch : noarch Version: 0.6.0 Release: 1.fc3 Size : 19 k Repo : extras Summary: A script to help thwart ssh server attacks Description: DenyHosts is a Python script that analyzes the sshd server log messages to determine which hosts are attempting to hack into your system. It also determines what user accounts are being targeted. It keeps track of the frequency of attempts from each host and, upon discovering a repeated attack host, updates the /etc/hosts.deny file to prevent future break-in attempts from that host. Email reports can be sent to a system admin.
There's also the web site at denyhosts.sf.net.
NBC> I'm running FC3 on my firewall machine at home. Can I do a 'yum NBC> install denyhosts'?
Yes, if you have the extras repo enabled.
NBC> Is there documentation on how to configure it?
Not much to it; you just do
chkconfig denyhosts on; service denyhosts start
adjust the run frequency in /etc/cron.d/denyhosts and look over the well-commented /etc/denyhosts.conf
- J<
On Mon, 2005-08-08 at 09:25 -0500, Jason L Tibbitts III wrote:
"JC" == Justin Conover justin.conover@gmail.com writes:
JC> Is it stupid when someone is trying to get on your box, leaves the JC> ip and has a website on that ip ;-)
Yes, but most of these hosts have been hacked and are just running automated tools to find other hackable boxes.
To protect yourself, install denyhosts from extras, tune it to your environment and enjoy the satisfaction of having these be blocked automatically.
I hope to have an updated version of denyhosts checked into extras soon.
That sounds like auto-shunning, a term that Dan Kaminsky, uses. You are basically allowing the cracker add rules. Auto-shunning + IP Spoofing = Nastiness. They could say spoof your default gateway, root dns servers, the dns servers you use, etc. Then you automatically block those things that you need access to. They can also do this to you so that they can pretend to be you. They just get you to block the people that they want to appear to you to. The reverse is also possible. They get you to block your bank and then pretend to be your bank to phish you.
On Mon, 8 Aug 2005, Nathan Grennan wrote:
That sounds like auto-shunning, a term that Dan Kaminsky, uses. You are basically allowing the cracker add rules. Auto-shunning + IP Spoofing = Nastiness. They could say spoof your default gateway, root dns servers, the dns servers you use, etc. Then you automatically block those things that you need access to. They can also do this to you so that they can pretend to be you. They just get you to block the people that they want to appear to you to. The reverse is also possible. They get you to block your bank and then pretend to be your bank to phish you.
AFAIK no this is not possible with denyhosts. The logs it looks for requires complete end to end TCP connections. Good luck spoofing a complete end to end TCP connection on the modern internet (hint:source routing does not work for some 15 years now).
Another good one is pam_abl. And I'm afraid that one is immune to spoofing also.
-Dan
"NG" == Nathan Grennan fedora-test-list@cygnusx-1.org writes:
NG> That sounds like auto-shunning, a term that Dan Kaminsky, NG> uses. You are basically allowing the cracker add NG> rules.
Good thing that's not the case. Sure, if you have concerns then by all means don't install the software, but at least do a little checking before spreading FUD.
- J<
On Mon, 2005-08-08 at 13:25 -0500, Jason L Tibbitts III wrote:
Good thing that's not the case. Sure, if you have concerns then by all means don't install the software, but at least do a little checking before spreading FUD.
I said sounds like, not is. I provided information about why auto-shunning in general can be a bad idea. After a little more research(though not intensive) it sounds like denyhosts isn't the best way, but most likely good enough. pam_abl's default behavior of not blocking the ability to make a connection, but instead just causing the authentication to fail for that ip address makes more sense.
I recently set up some rules. I know they could be abused for dos, but for me this is a minor problem. Warning: I am not sure if they work correct, or if they make some problems.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
"Marco" == Marco Meyerhofer marco_meyerhofer@freesurf.ch writes:
Marco> I recently set up some rules. I know they could be abused for Marco> dos, but for me this is a minor problem. Warning: I am not Marco> sure if they work correct, or if they make some problems.
Marco> # SSH brute force protection $EXT_IF Marco> $IPTABLES -N ssh_brute Marco> $IPTABLES -A INPUT -i $EXT_IF -p tcp --dport 22 -m state --state NEW -j ssh_brute Marco> $IPTABLES -A ssh_brute -m recent --set Marco> $IPTABLES -A ssh_brute -m recent --update --seconds 120 ! --hitcount 4 -j RETURN Marco> $IPTABLES -A ssh_brute -m limit -j LOG --log-prefix "ssh bruteforce " Marco> $IPTABLES -A ssh_brute -j DROP
A better rule (IMHO), I use:
$IPTABLES -A INPUT -m hashlimit -m tcp -p tcp --dport 22 --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT
This has the advantage of only blocking the offending IP if they go over 1/min, but letting all other ip's still have access until they go over the limit.
kevin
On Tue, 2005-08-09 at 09:39 -0600, Kevin Fenzi wrote:
A better rule (IMHO), I use:
$IPTABLES -A INPUT -m hashlimit -m tcp -p tcp --dport 22 --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT
This has the advantage of only blocking the offending IP if they go over 1/min, but letting all other ip's still have access until they go over the limit.
I've used similar rules for some time now and they've proven very effective. The only problem I've run into is with subversion over SSH, it generates a lot of short connections sometimes (for example when browsing a repository) and can look like an attack to this kind of block. For that reason I am interested in testing DENYHOSTS.
On 8/9/05, Brian Gaynor briang@pmccorp.com wrote:
On Tue, 2005-08-09 at 09:39 -0600, Kevin Fenzi wrote:
A better rule (IMHO), I use:
$IPTABLES -A INPUT -m hashlimit -m tcp -p tcp --dport 22 --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT
This has the advantage of only blocking the offending IP if they go over 1/min, but letting all other ip's still have access until they go over the limit.
I've used similar rules for some time now and they've proven very effective. The only problem I've run into is with subversion over SSH, it generates a lot of short connections sometimes (for example when browsing a repository) and can look like an attack to this kind of block. For that reason I am interested in testing DENYHOSTS.
-- Brian Gaynor www.pmccorp.com FC4/Linux on DELL Inspiron 5160 3.0Ghz canis 08:55:20 up 26 min, 1 user, load average: 0.27, 0.22,
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
Bastards really want in.
sshd: Authentication Failures: root (61.185.220.46): 528 Time(s) unknown (61.185.220.46): 221 Time(s) mail (61.185.220.46): 2 Time(s) mysql (61.185.220.46): 2 Time(s) news (61.185.220.46): 2 Time(s) adm (61.185.220.46): 1 Time(s) apache (61.185.220.46): 1 Time(s) bin (61.185.220.46): 1 Time(s) ftp (61.185.220.46): 1 Time(s) games (61.185.220.46): 1 Time(s) ldap (61.185.220.46): 1 Time(s) lp (61.185.220.46): 1 Time(s) nobody (61.185.220.46): 1 Time(s) operator (61.185.220.46): 1 Time(s) root (201.145.24.178): 1 Time(s) rpm (61.185.220.46): 1 Time(s) squid (61.185.220.46): 1 Time(s) sshd (61.185.220.46): 1 Time(s) Invalid Users: Unknown Account: 221 Time(s) Bad User: root: 1 Time(s) Sessions Opened: justin: 1 Time(s)
On 8/9/05, Justin Conover justin.conover@gmail.com wrote:
On 8/9/05, Brian Gaynor briang@pmccorp.com wrote:
On Tue, 2005-08-09 at 09:39 -0600, Kevin Fenzi wrote:
A better rule (IMHO), I use:
$IPTABLES -A INPUT -m hashlimit -m tcp -p tcp --dport 22 --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT
This has the advantage of only blocking the offending IP if they go over 1/min, but letting all other ip's still have access until they go over the limit.
I've used similar rules for some time now and they've proven very effective. The only problem I've run into is with subversion over SSH, it generates a lot of short connections sometimes (for example when browsing a repository) and can look like an attack to this kind of block. For that reason I am interested in testing DENYHOSTS.
-- Brian Gaynor www.pmccorp.com FC4/Linux on DELL Inspiron 5160 3.0Ghz canis 08:55:20 up 26 min, 1 user, load average: 0.27, 0.22,
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
Bastards really want in.
sshd: Authentication Failures: root (61.185.220.46): 528 Time(s) unknown (61.185.220.46): 221 Time(s) mail (61.185.220.46): 2 Time(s) mysql (61.185.220.46): 2 Time(s) news (61.185.220.46): 2 Time(s) adm (61.185.220.46): 1 Time(s) apache (61.185.220.46): 1 Time(s) bin (61.185.220.46): 1 Time(s) ftp (61.185.220.46): 1 Time(s) games (61.185.220.46): 1 Time(s) ldap (61.185.220.46): 1 Time(s) lp (61.185.220.46): 1 Time(s) nobody (61.185.220.46): 1 Time(s) operator (61.185.220.46): 1 Time(s) root (201.145.24.178): 1 Time(s) rpm (61.185.220.46): 1 Time(s) squid (61.185.220.46): 1 Time(s) sshd (61.185.220.46): 1 Time(s) Invalid Users: Unknown Account: 221 Time(s) Bad User: root: 1 Time(s) Sessions Opened: justin: 1 Time(s)
ssh bob@<myIP> Stay the **** off my box! Loosers, you can't get in. Your a bunch of script-kiddes that suckled on your momma to long. If you think your talented, than use it to do real hacking, like on Open Source Linux. Otherwise, take your noobie cracking ass back to school!
On Tue, 2005-08-09 at 13:32 -0500, Justin Conover wrote:
On 8/9/05, Justin Conover justin.conover@gmail.com wrote:
On 8/9/05, Brian Gaynor briang@pmccorp.com wrote:
On Tue, 2005-08-09 at 09:39 -0600, Kevin Fenzi wrote:
A better rule (IMHO), I use:
$IPTABLES -A INPUT -m hashlimit -m tcp -p tcp --dport 22 --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT
This has the advantage of only blocking the offending IP if they go over 1/min, but letting all other ip's still have access until they go over the limit.
I've used similar rules for some time now and they've proven very effective. The only problem I've run into is with subversion over SSH, it generates a lot of short connections sometimes (for example when browsing a repository) and can look like an attack to this kind of block. For that reason I am interested in testing DENYHOSTS.
-- Brian Gaynor www.pmccorp.com FC4/Linux on DELL Inspiron 5160 3.0Ghz canis 08:55:20 up 26 min, 1 user, load average: 0.27, 0.22,
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
Bastards really want in.
sshd: Authentication Failures: root (61.185.220.46): 528 Time(s) unknown (61.185.220.46): 221 Time(s) mail (61.185.220.46): 2 Time(s) mysql (61.185.220.46): 2 Time(s) news (61.185.220.46): 2 Time(s) adm (61.185.220.46): 1 Time(s) apache (61.185.220.46): 1 Time(s) bin (61.185.220.46): 1 Time(s) ftp (61.185.220.46): 1 Time(s) games (61.185.220.46): 1 Time(s) ldap (61.185.220.46): 1 Time(s) lp (61.185.220.46): 1 Time(s) nobody (61.185.220.46): 1 Time(s) operator (61.185.220.46): 1 Time(s) root (201.145.24.178): 1 Time(s) rpm (61.185.220.46): 1 Time(s) squid (61.185.220.46): 1 Time(s) sshd (61.185.220.46): 1 Time(s) Invalid Users: Unknown Account: 221 Time(s) Bad User: root: 1 Time(s) Sessions Opened: justin: 1 Time(s)
ssh bob@<myIP> Stay the **** off my box! Loosers, you can't get in. Your a bunch of script-kiddes that suckled on your momma to long. If you think your talented, than use it to do real hacking, like on Open Source Linux. Otherwise, take your noobie cracking ass back to school!
What is really going to be funny, is when someone ends up with a few hundred thousands lines of firewall config and restart's their firewall or reloads their box. I don't see where most people would benefit from a slew of 32 bit length firewall rules. Now if it where smart enough to block the entire ip block, preferably top registration that would be much more useful.
Be careful what you wish for, you might just get it.
Ted
On Tue, 9 Aug 2005, Ted Kaczmarek wrote:
What is really going to be funny, is when someone ends up with a few hundred thousands lines of firewall config and restart's their firewall or reloads their box. I don't see where most people would benefit from a slew of 32 bit length firewall rules. Now if it where smart enough to block the entire ip block, preferably top registration that would be much more useful.
that's why pam_abl is so nice. not only does it deceive the attackers, it's also near zero-cost. no huge in-kernel firewall rules. simple. easy. painless.
-Dan
On Tue, 2005-08-09 at 09:00 -0700, Brian Gaynor wrote:
On Tue, 2005-08-09 at 09:39 -0600, Kevin Fenzi wrote:
$IPTABLES -A INPUT -m hashlimit -m tcp -p tcp --dport 22 --hashlimit 1/min --hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j ACCEPT
I've used similar rules for some time now and they've proven very effective. The only problem I've run into is with subversion over SSH, it generates a lot of short connections sometimes (for example when browsing a repository) and can look like an attack to this kind of block.
That issue has been addressed by the newly released openssh-4.2
http://www.mindrot.org/pipermail/openssh-unix-announce/2005-September/000083...
Quote: - Many bugfixes and improvements to connection multiplexing, including:
- Added ControlMaster=auto/autoask options to support opportunistic multiplexing (see the ssh_config(5) manpage for details).
My former iptables ruleset was wrong. This seems to work better:
# SSH brute force protection $EXT_IF $IPTABLES -N ssh_brute $IPTABLES -A INPUT -i $EXT_IF -p tcp --dport 22 -m state --state NEW \ -j ssh_brute $IPTABLES -A ssh_brute -m recent --set $IPTABLES -A ssh_brute -m recent ! --rcheck --seconds 300 --hitcount \ 4 -j RETURN $IPTABLES -A ssh_brute -m limit -j LOG --log-prefix "ssh_bruteforce " $IPTABLES -A ssh_brute -j DROP
-
Boris B. Zhmurov -
Brian Gaynor -
Dan Hollis -
David Hagood -
Florin Andrei -
Jason L Tibbitts III -
Justin Conover -
Kevin Fenzi -
Kyrre Ness Sjobak -
Marco Meyerhofer -
Nathan Grennan -
Neil B. Cohen -
Roger Grosswiler -
Ted Kaczmarek