Re: Thousands of ssh probes
On Sun, Mar 7, 2010 at 16:48, Erik Norgaard norga...@locolomo.org wrote: On 07/03/10 21:41, dacoder wrote: has anybody suggested having sshd listen on a high port? Any number will do, think about it: a. The attacker doesn't really care which host is compromised any will do, and better yet someones home box as it is more difficult to trace him. In that case he will scan large ip-ranges for hosts listening on port 22. b. The attacker wants to gain control of a particular server. In that case he will scan all ports to see what services are running and determine which services are running on each port. In that case running ssh on a non-standard port is futile. However, I'm not really a fan of using non-standard ports for ssh, I don't believe it's the right solution to the problem: You have ssh access to the outside because people travel and need remote access. In that case they might find themselves under other security policies which block access to services deemed unnecessary. Running ssh on a non-standard port is likely to be blocked on the client network - unless you run on, say, port 80. The more uses you have, the more problems you will have running ssh on a non-standard port, the time you save checking your logs may easily be spent on end user support. OP referred to significant impact on bandwidth which I find difficult to believe. In case connections come from a single ip at a time then you should tweak LoginGraceTime, MaxAuthTries, MaxSessions to reduce the number of concurrent un-authenticate connections and slow down brute force attacks. Much better, restrict the client access to certain ranges of IPs. The different registries publish ip ranges assigned per country and you can create a list blocking countries you are certain not to visit, you can use my script: http://www.locolomo.org/pub/src/toolbox/inet.pl Great script! Just one question. Where do you put the list of denied ip ranges? BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On 08/03/10 18:56, Jason Garrett wrote: Much better, restrict the client access to certain ranges of IPs. The different registries publish ip ranges assigned per country and you can create a list blocking countries you are certain not to visit, you can use my script: http://www.locolomo.org/pub/src/toolbox/inet.pl Great script! Just one question. Where do you put the list of denied ip ranges? The output is written to be used with packet filter, if you use some other firewall you may need edit the script. If you use packet filter, then you can dump the list into a file and create tables like this: table blacklist persist file /etc/blacklist block in quick from blacklist I use blacklisting for mail while I use whitelisting for ssh. You should know the limits of the script, the problem is that some ranges have been assigned directly by IANA, particularly for US. These are not included. The list is limited as these are all /8 chunks, you can find it here: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml These ranges are managed by private organisations and assigned as they see fit. There is another thing I'd like to filter by: I'd like to eliminate dynamic ranges, particularly for mail. It's been recommended that reverse lookup resolves to something like dyn.example.com or dynamic.example.com, but there is no registry where you can simply look it up. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On Mon, Mar 8, 2010 at 16:11, Erik Norgaard norga...@locolomo.org wrote: On 08/03/10 18:56, Jason Garrett wrote: Much better, restrict the client access to certain ranges of IPs. The different registries publish ip ranges assigned per country and you can create a list blocking countries you are certain not to visit, you can use my script: http://www.locolomo.org/pub/src/toolbox/inet.pl Great script! Just one question. Where do you put the list of denied ip ranges? The output is written to be used with packet filter, if you use some other firewall you may need edit the script. If you use packet filter, then you can dump the list into a file and create tables like this: table blacklist persist file /etc/blacklist block in quick from blacklist I use blacklisting for mail while I use whitelisting for ssh. You should know the limits of the script, the problem is that some ranges have been assigned directly by IANA, particularly for US. These are not included. The list is limited as these are all /8 chunks, you can find it here: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml These ranges are managed by private organisations and assigned as they see fit. There is another thing I'd like to filter by: I'd like to eliminate dynamic ranges, particularly for mail. It's been recommended that reverse lookup resolves to something like dyn.example.com or dynamic.example.com, but there is no registry where you can simply look it up. Thanks! I'm not sure what ranges the OP is looking for, but I only want to allow from US ip's for now, since I never travel outside the country. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
+++ Erik Norgaard [06/03/10 02:44 +0100]: On 05/03/10 13:54, John wrote: My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? This is a frequent question on the list, search the archives. Basically there are few things that you can do: 1. limit the access to a range of IPs, for example, even if you travel a lot you go to al limited number of countries, why permit access from other continents? 2. limit access to certain users, there is no need to allow games or root user to authenticate via ssh. Use AllowUsers or AllowGroups to restrict access to real users. 3. limit the amount of concurrent non-authenticated connections, number of failed attempts and similar. 4. prohibit password authentication. If the problem is that these attacks consume significant bandwidth then moving your service to a different port may be a good solution, but if your concern is security, then the above is more effective. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org -- has anybody suggested having sshd listen on a high port? regards, david coder network engineer emeritus, verio/ntt telluride, co washington, dc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On 07/03/10 21:41, dacoder wrote: has anybody suggested having sshd listen on a high port? Any number will do, think about it: a. The attacker doesn't really care which host is compromised any will do, and better yet someones home box as it is more difficult to trace him. In that case he will scan large ip-ranges for hosts listening on port 22. b. The attacker wants to gain control of a particular server. In that case he will scan all ports to see what services are running and determine which services are running on each port. In that case running ssh on a non-standard port is futile. However, I'm not really a fan of using non-standard ports for ssh, I don't believe it's the right solution to the problem: You have ssh access to the outside because people travel and need remote access. In that case they might find themselves under other security policies which block access to services deemed unnecessary. Running ssh on a non-standard port is likely to be blocked on the client network - unless you run on, say, port 80. The more uses you have, the more problems you will have running ssh on a non-standard port, the time you save checking your logs may easily be spent on end user support. OP referred to significant impact on bandwidth which I find difficult to believe. In case connections come from a single ip at a time then you should tweak LoginGraceTime, MaxAuthTries, MaxSessions to reduce the number of concurrent un-authenticate connections and slow down brute force attacks. Much better, restrict the client access to certain ranges of IPs. The different registries publish ip ranges assigned per country and you can create a list blocking countries you are certain not to visit, you can use my script: http://www.locolomo.org/pub/src/toolbox/inet.pl BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2010 06:33:53, Ian Smith wrote: In freebsd-questions Digest, Vol 300, Issue 10, Message: 6 On Fri, 05 Mar 2010 16:07:29 + Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/03/2010 15:51:52, Randal L. Schwartz wrote: The spamtrap is a shiny object for spam, and anything that goes there gets blocked for an hour from hitting the low port. I presented this at a conference once. Having an IPv6-only high-mx seems to terminally confuse most spambots... I understand why IPv6 would confuse them, but don't follow why higher numbered MXs would be more attractive to them in the first place? Are they assuming a 'secondary' MX will be more likely to accept spam? Yes. Generally a high-numbered MX is more trusted than the run-of- the-mill internet by the actual mail server (lowest numbered MX)[*], so forwarding between MXes tends to bypass chunks of anti-spam protection. The high-numbered MX itself is usually a pretty low importance system at a location remote from all the rest of the mail servers, so it tends to have less effective anti-spam protection. Thus spammers ignore the normal MX priority rules and just attempt to inject spam through the highest numbered MX, because it is more likely to get through. On the whole, I don't see the value in having a high-numbered MX to dumbly accept, queue and forward messages like this. It doesn't really add any resilience: the SMTP protocol is intrinsically all about store and forward, and if a message cannot be delivered immediately, the sending side will keep it in a queue for up to 5 days anyhow. Low priority MXes make some sense for load shedding, but realistically as part of a cluster of servers at one site. If you want resilience against network outages, then you're going to have to provide a resilient solution for /reading/ the e-mails too, and that's a whole different ball game. Cheers, Matthew [*] Even if the low-priority MXes are treated as untrusted, you've still got the whole backscatter problem to consider. - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuSIgcACgkQ8Mjk52CukIxQEQCffVtAHVHs5u58+Sz0SIZlDM0Q 0pYAoJD8d6Tyd6xypSbx0Z/3qmScmbeR =VCWG -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On Mar 6, 2010, at 4:36 AM, Matthew Seaman wrote: Having an IPv6-only high-mx seems to terminally confuse most spambots... I understand why IPv6 would confuse them, but don't follow why higher numbered MXs would be more attractive to them in the first place? Are they assuming a 'secondary' MX will be more likely to accept spam? Yes. Generally a high-numbered MX is more trusted than the run-of- the-mill internet by the actual mail server (lowest numbered MX)[*], so forwarding between MXes tends to bypass chunks of anti-spam protection. The high-numbered MX itself is usually a pretty low importance system at a location remote from all the rest of the mail servers, so it tends to have less effective anti-spam protection. Thus spammers ignore the normal MX priority rules and just attempt to inject spam through the highest numbered MX, because it is more likely to get through. While this is undoubtedly true in some cases, you're offering too much credit to the spammers for other cases. :-) There are spambots which simply scan through IPv4 address space trying to talk to port 25, and they attempt to deliver the same spam (or some template put through an obfuscator which adds random text) to a list of usernames, regardless of MX records. Some try to deliver to unqualified addresses (ie, rcpt to: cswiger); others do a reverse lookup of each address and append the domain name to the addresses. It's pretty easy to notice this when you've got a bunch of IPs setup on different domains. Anyway, for personal domains, you can setup teergrubes on both high and low numbered MX records, which delay but never accept mail, and have your real mailserver in the middle. Unfortunately, there are so many broken SMTP servers out there, which don't retry delivery to all MX hosts, that a fair amount of legitimate email will be lost-- you can't realistically do this for normal users. On the whole, I don't see the value in having a high-numbered MX to dumbly accept, queue and forward messages like this. It doesn't really add any resilience: the SMTP protocol is intrinsically all about store and forward, and if a message cannot be delivered immediately, the sending side will keep it in a queue for up to 5 days anyhow. The two main uses are: 1) If your primary MX is where delivery happens, and it goes down or is otherwise unavailable for a while, you can do an ETRN against the secondary(-ies) and get all of the queued mail relatively immediately once you fix the issue. If you have drastic problems (ie, a box goes down permanently and you can't get a replacement up in less than a week due to shipping time), you can even have your secondary queue email for longer than the default 5 days if that becomes necessary. 2) Domains without permanent network connectivity: http://www.postfix.org/ETRN_README.html Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On Sat, 6 Mar 2010, Matthew Seaman wrote: On 06/03/2010 06:33:53, Ian Smith wrote: In freebsd-questions Digest, Vol 300, Issue 10, Message: 6 On Fri, 05 Mar 2010 16:07:29 + Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/03/2010 15:51:52, Randal L. Schwartz wrote: The spamtrap is a shiny object for spam, and anything that goes there gets blocked for an hour from hitting the low port. I presented this at a conference once. Having an IPv6-only high-mx seems to terminally confuse most spambots... I understand why IPv6 would confuse them, but don't follow why higher numbered MXs would be more attractive to them in the first place? Are they assuming a 'secondary' MX will be more likely to accept spam? Yes. Generally a high-numbered MX is more trusted than the run-of- the-mill internet by the actual mail server (lowest numbered MX)[*], so forwarding between MXes tends to bypass chunks of anti-spam protection. The high-numbered MX itself is usually a pretty low importance system at a location remote from all the rest of the mail servers, so it tends to have less effective anti-spam protection. Thus spammers ignore the normal MX priority rules and just attempt to inject spam through the highest numbered MX, because it is more likely to get through. Makes sense. Since I wrote that, some repressed memories surfaced .. On the whole, I don't see the value in having a high-numbered MX to dumbly accept, queue and forward messages like this. It doesn't really add any resilience: the SMTP protocol is intrinsically all about store and forward, and if a message cannot be delivered immediately, the sending side will keep it in a queue for up to 5 days anyhow. Low priority MXes make some sense for load shedding, but realistically as part of a cluster of servers at one site. If you want resilience against network outages, then you're going to have to provide a resilient solution for /reading/ the e-mails too, and that's a whole different ball game. Indeed. About 10 years ago when we ran a few domains on a 56k modem link with a secondary MX on $bigisp, woke up one day to find we were being DoS'd by some 90,000 big email from some marketing outfit via the unfiltered secondary MX. Had to cancel that on the spot to chuck them away or spend days doing nothing else; haven't bothered using one since. Cheers, Matthew [*] Even if the low-priority MXes are treated as untrusted, you've still got the whole backscatter problem to consider. Yea; another nightmare system 'inherited' had a qmail frontend accepting everything thrown at it, even for invalid usernames, passing it to a backend system to sort and sift through it and yes, generate something like 95% backscatter, mostly bound for nowhere. Talk about shooting yourself in the foot .. still getting resultant tryhard attempts 18 months after getting sendmail going - spambots have long memories! Thanks for the clear explanation, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
Matthew == Matthew Seaman m.sea...@infracaninophile.co.uk writes: Matthew On the whole, I don't see the value in having a high-numbered MX to Matthew dumbly accept, queue and forward messages like this. High-numbered MX came from a time where an internal machine could only be delivered from outside via an external gateway. If you want to deliver to internal.example.com, you tried its lowest MX first, and failing to connect, you fall back to the next MX, external.example.com. The idea is that external.example.com would then be able to see the next hop, and forward the mail. The modern recommendation is to avoid MX altogether, and rely on split-horizon DNS and SMTP delivery reattempts. But a lot of people are still stuck in the old ways. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On 03/05/10 06:54, John wrote: My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? Can you not deny all ssh attempts and then allow only from certain, trusted IPs? -- Yours In Christ, PIT Emails are not formal business letters, whatever businesses may want. Original content copyright under the OWL http://owl.apotheon.org Please do not CC me. If I'm posting to a list it is because I am subscribed. signature.asc Description: OpenPGP digital signature
Re: Thousands of ssh probes
On Fri, Mar 5, 2010 at 2:54 PM, John j...@starfire.mn.org wrote: My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? -- John Lind j...@starfire.mn.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Look at security/blocksshd and security/denyhosts Also changing SSH to a non-standard port helps - a lot. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On Fri, Mar 05, 2010 at 07:03:53AM -0600, Programmer In Training wrote: On 03/05/10 06:54, John wrote: My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? Can you not deny all ssh attempts and then allow only from certain, trusted IPs? Ah, I should have added that I travel a fair amount, and often have to get to my systems via hotel WiFi or Aircard, so it's impossible to predict my originating IP address in advance. If that were not the case, this would be an excellent suggestion. -- Yours In Christ, PIT Emails are not formal business letters, whatever businesses may want. Original content copyright under the OWL http://owl.apotheon.org Please do not CC me. If I'm posting to a list it is because I am subscribed. -- John Lind j...@starfire.mn.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On 2010-03-05 13:54, John wrote: My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? I use the pf firewall with sshguard. You'll see from the daily security how well it blocks :-) /Leslie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On Mar 5, 2010, at 8:26 AM, John wrote: On Fri, Mar 05, 2010 at 07:03:53AM -0600, Programmer In Training wrote: On 03/05/10 06:54, John wrote: My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? Can you not deny all ssh attempts and then allow only from certain, trusted IPs? Ah, I should have added that I travel a fair amount, and often have to get to my systems via hotel WiFi or Aircard, so it's impossible to predict my originating IP address in advance. If that were not the case, this would be an excellent suggestion. Way back about 10 years ago, I was playing around with IPFW a lot. I wrote a script to update IPFW from changes made to a MySql db. It was a just for fun project, that turned out to be rather useful I have some developers that I managed who like you were road warriors. They logged in to the https web page w/ their username and password which grabbed their IP address and stored it in a table on with their login id. The script called fud (for firewall update daemon) connected to the db and ran a query to check for any rule changes. If there were it would apply them to the rule set and clear the change flag. Using this combination I was able to allow ssh access only to the necessary ip addresses. I kind of scrapped it when VPNs became easier to deploy and I have no idea where this set of scripts are now, but it would be rather trivial to build a new version. If anyone thinks it's worth revisiting hit me off list. Cheers, Mikel King CEO, Olivent Technologies Senior Editor, BSD News Network Columnist, BSD Magazine 6 Alpine Court, Medford, NY 11763 o: 631.627.3055 c: 631.796.1499 skype:mikel.king http://olivent.com http://www.linkedin.com/in/mikelking http://twitter.com/mikelking ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On Fri, Mar 05, 2010 at 10:19:09AM -0500, mikel king wrote: On Mar 5, 2010, at 8:26 AM, John wrote: On Fri, Mar 05, 2010 at 07:03:53AM -0600, Programmer In Training wrote: On 03/05/10 06:54, John wrote: My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? Can you not deny all ssh attempts and then allow only from certain, trusted IPs? Ah, I should have added that I travel a fair amount, and often have to get to my systems via hotel WiFi or Aircard, so it's impossible to predict my originating IP address in advance. If that were not the case, this would be an excellent suggestion. Way back about 10 years ago, I was playing around with IPFW a lot. I wrote a script to update IPFW from changes made to a MySql db. It was a just for fun project, that turned out to be rather useful I have some developers that I managed who like you were road warriors. They logged in to the https web page w/ their username and password which grabbed their IP address and stored it in a table on with their login id. The script called fud (for firewall update daemon) connected to the db and ran a query to check for any rule changes. If there were it would apply them to the rule set and clear the change flag. Using this combination I was able to allow ssh access only to the necessary ip addresses. I kind of scrapped it when VPNs became easier to deploy and I have no idea where this set of scripts are now, but it would be rather trivial to build a new version. If anyone thinks it's worth revisiting hit me off list. Maybe I'll have to learn how to do a VPN from FreeBSD One thought that occurs to me is that pf tables would provide a direct API without having to hit a database. I think I really like this. I may have to implement it for pf. It should be really easy with CGI and calls to pfctl. -- John Lind j...@starfire.mn.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
Anton == Anton an...@sng.by writes: AntonBut, to allow acces for yourself - you could install wonderfull Antonutility = 'knock-knock'. Port knocking is false security. It's equivalent to adding precisely two bytes (per knock, which can't be too close or far apart or numerous) to the key length. Are you really thinking that increasing your key length from 2048 to 2050 helps? The right solution is proper ssh key management, and intrusion detection, and if you insist on having password access, use one-time passwords and/or strength checks. If you don't like your logfiles filling up, don't run ssh on port 22. I like 443, because corporate firewalls tend to pass that... :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On Fri, Mar 05, 2010 at 07:45:02AM -0800, Randal L. Schwartz wrote: Anton == Anton an...@sng.by writes: AntonBut, to allow acces for yourself - you could install wonderfull Antonutility = 'knock-knock'. Port knocking is false security. It's equivalent to adding precisely two bytes (per knock, which can't be too close or far apart or numerous) to the key length. Are you really thinking that increasing your key length from 2048 to 2050 helps? The right solution is proper ssh key management, and intrusion detection, and if you insist on having password access, use one-time passwords and/or strength checks. If you don't like your logfiles filling up, don't run ssh on port 22. I like 443, because corporate firewalls tend to pass that... :) Yes - that's exactly what I used to do, and exactly why I used to do it, but now I'm thinking of actually implement https. -- John Lind j...@starfire.mn.org The inherent vice of capitalism is the unequal sharing of blessings; the inherent virtue of socialism is the equal sharing of miseries. - Winston Churchill ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
John == John j...@starfire.mn.org writes: John Yes - that's exactly what I used to do, and exactly why I used to do John it, but now I'm thinking of actually implement https. Rent more than one IP. :) I have a block of 8 for exactly that reason. It allows me to run sshd on 443 *and* https on a different 443, and a mailer on one 25 and a high-mx mail spamtrap on another port 25. stonehenge.com mail is handled by 5 blue.stonehenge.com. stonehenge.com mail is handled by 666 spamtrap.stonehenge.com. The spamtrap is a shiny object for spam, and anything that goes there gets blocked for an hour from hitting the low port. I presented this at a conference once. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On Mar 5, 2010, at 10:44 AM, John wrote: On Fri, Mar 05, 2010 at 10:19:09AM -0500, mikel king wrote: On Mar 5, 2010, at 8:26 AM, John wrote: Way back about 10 years ago, I was playing around with IPFW a lot. I wrote a script to update IPFW from changes made to a MySql db. It was a just for fun project, that turned out to be rather useful I have some developers that I managed who like you were road warriors. They logged in to the https web page w/ their username and password which grabbed their IP address and stored it in a table on with their login id. The script called fud (for firewall update daemon) connected to the db and ran a query to check for any rule changes. If there were it would apply them to the rule set and clear the change flag. Using this combination I was able to allow ssh access only to the necessary ip addresses. I kind of scrapped it when VPNs became easier to deploy and I have no idea where this set of scripts are now, but it would be rather trivial to build a new version. If anyone thinks it's worth revisiting hit me off list. Maybe I'll have to learn how to do a VPN from FreeBSD One thought that occurs to me is that pf tables would provide a direct API without having to hit a database. I think I really like this. I may have to implement it for pf. It should be really easy with CGI and calls to pfctl. -- There's probably a dozen ways to slice it now. I went with php, mysql and ipfw, just because that was the theme back then. I also found it handy to be able to login into the system and manually enter the ip addressing if necessary. I would definitely add some better logging than I did back then. Hmmm giving me an idea for another article on BSDNews.net... ;-) cheers, m! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2010 15:44:39, John wrote: Maybe I'll have to learn how to do a VPN from FreeBSD One thought that occurs to me is that pf tables would provide a direct API without having to hit a database. I think I really like this. I may have to implement it for pf. It should be really easy with CGI and calls to pfctl. There's already a mechanism whereby you can connect into a PF firewall and have it open up extra access for you, all controlled by ssh keys. See: http://www.openbsd.org/faq/pf/authpf.html Not only that, but you can dynamically block brute force attempts to crack SSH passwords using just PF -- no need to scan through auth.log or use an external database. You need something like this in pf.conf: table ssh-bruteforce persist [...near the top of the rules section...] block drop in log quick on $ext_if from ssh-bruteforce [...later in the rules section...] pass in on $ext_if proto tcp \ from any to $ext_if port ssh \ flags S/SA keep state\ (max-src-conn-rate 3/30, overload ssh-bruteforce flush global) This adds IPs to the ssh-bruteforce table if there are too frequent attempts to connect from them (more than 3 within 30 seconds in this case) and so blocks all further access. You need to run a cron job to clear out old entries from the ssh-bruteforce table or it will grow continually over time: */12 * * * */sbin/pfctl -t ssh-bruteforce -T expire 86400 /dev/null 21 Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRKtwACgkQ8Mjk52CukIyodQCfZ42OO6DstB5TFCY49uP0KaZl Y+wAn3sBhwad03EGKioC7vBhcqE2vHvP =awJ9 -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2010 15:51:52, Randal L. Schwartz wrote: The spamtrap is a shiny object for spam, and anything that goes there gets blocked for an hour from hitting the low port. I presented this at a conference once. Having an IPv6-only high-mx seems to terminally confuse most spambots... Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRLEAACgkQ8Mjk52CukIw//gCfS3MaEN0c+8gaHqS8RbQq/Nsz KtEAnRb5oIrwk4DGMR4uzfB+tO5mh/sp =Duju -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
Matthew == Matthew Seaman m.sea...@infracaninophile.co.uk writes: Matthew On 05/03/2010 15:51:52, Randal L. Schwartz wrote: The spamtrap is a shiny object for spam, and anything that goes there gets blocked for an hour from hitting the low port. I presented this at a conference once. Matthew Having an IPv6-only high-mx seems to terminally confuse most spambots... Oooh! And arpnetworks gives me a /48 in 6 for free. I could have thousands of them. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2010 16:12:11, Randal L. Schwartz wrote: Matthew == Matthew Seaman m.sea...@infracaninophile.co.uk writes: Matthew On 05/03/2010 15:51:52, Randal L. Schwartz wrote: The spamtrap is a shiny object for spam, and anything that goes there gets blocked for an hour from hitting the low port. I presented this at a conference once. Matthew Having an IPv6-only high-mx seems to terminally confuse most spambots... Oooh! And arpnetworks gives me a /48 in 6 for free. I could have thousands of them. :) Thousands? Try billions. Sagans and sagans. More than the maximum possible number of hosts on the IPv4 internet. Muha ha Ha! Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRL5MACgkQ8Mjk52CukIzRQQCglZbgUd+Or9l/EQaBCUMoE2DN oE4Anjq34Oi7OOSgfFGn8/Znu9KAoWHU =XQGR -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
mikel king wrote: Way back about 10 years ago, I was playing around with IPFW a lot. I wrote a script to update IPFW from changes made to a MySql db. It was a just for fun project, that turned out to be rather useful I have some developers that I managed who like you were road warriors. They logged in to the https web page w/ their username and password which grabbed their IP address and stored it in a table on with their login id. The script called fud (for firewall update daemon) connected to the db and ran a query to check for any rule changes. If there were it would apply them to the rule set and clear the change flag. Using this combination I was able to allow ssh access only to the necessary ip addresses. We use a similar approach but only rely on tcpwrappers. Here's what we do (simplified obfuscated slightly), just for reference (or, maybe commentary :-D ) On server: [505] Fri 05.Mar.2010 10:21:37 [ad...@foo][~] cat /etc/hosts.allow | grep sshd # Wrapping sshd(8) is not normally a good idea, but if you sshd: /var/tmp/skyangel.ip : allow sshd: all : deny On skyangel: [13] Fri 05.Mar.2010 10:22:56 [ad...@skyangel][~] sudo crontab -l |grep dhcp @reboot /usr/local/bin/php -q /root/scripts/dhcp.php * */4*** /usr/local/bin/php -q /root/scripts/dhcp.php dhcp.php uses lynx to dump a server-side HTTPS page and sends a secret in the URI. Server-side page is able to decrypt this and determine it's really skyangel, then writes the connecting IP addy to /var/tmp/skyangel.ip. KDK ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
Hi, Am 05.03.10 17:01, schrieb Matthew Seaman: table ssh-bruteforce persist [...near the top of the rules section...] block drop in log quick on $ext_if fromssh-bruteforce [...later in the rules section...] pass in on $ext_if proto tcp \ from any to $ext_if port ssh \ flags S/SA keep state\ (max-src-conn-rate 3/30, overloadssh-bruteforce flush global) that is dangarous, if you use subversion over ssh you will sometimes get more then 10 requests in 30 seconds. That means you will also block users they are allowed to connect. Gruss, Matthias -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. -- Rich Cook ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On Fri, Mar 05, 2010 at 05:54:50PM +0100, Matthias Fechner wrote: Hi, Am 05.03.10 17:01, schrieb Matthew Seaman: table ssh-bruteforce persist [...near the top of the rules section...] block drop in log quick on $ext_if fromssh-bruteforce [...later in the rules section...] pass in on $ext_if proto tcp \ from any to $ext_if port ssh \ flags S/SA keep state\ (max-src-conn-rate 3/30, overloadssh-bruteforce flush global) that is dangarous, if you use subversion over ssh you will sometimes get more then 10 requests in 30 seconds. That means you will also block users they are allowed to connect. OK - that's good to know - but I'm not using subversion at this time, and this is working nicely so far. I've already picked off one hacker. # pfctl -t ssh-bruteforce -T show No ALTQ support in kernel ALTQ related functions disabled 218.56.61.114 Mar 5 10:40:05 elwood sshd[18452]: Invalid user test from 218.56.61.114 Mar 5 10:40:10 elwood sshd[18457]: Invalid user admin from 218.56.61.114 Apparently got him on the third attempt, just as advertised. -- John Lind j...@starfire.mn.org The inherent vice of capitalism is the unequal sharing of blessings; the inherent virtue of socialism is the equal sharing of miseries. - Winston Churchill ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2010 16:54:50, Matthias Fechner wrote:
Hi,
Am 05.03.10 17:01, schrieb Matthew Seaman:
table ssh-bruteforce persist
[...near the top of the rules section...]
block drop in log quick on $ext_if fromssh-bruteforce
[...later in the rules section...]
pass in on $ext_if proto tcp \
from any to $ext_if port ssh \
flags S/SA keep state\
(max-src-conn-rate 3/30, overloadssh-bruteforce flush global)
that is dangarous, if you use subversion over ssh you will sometimes get
more then 10 requests in 30 seconds.
That means you will also block users they are allowed to connect.
Yes. Almost all of the time I use this I've also had a ssh-whitelist
table -- addresses that will never be blocked in this way. Like this:
table ssh-bruteforce persist
table ssh-whitelist const { \
81.187.76.160/29 \
2001:8b0:151:1::/64 \
} persist
block drop in log quick on $ext_if from ssh-bruteforce
pass in on $ext_if proto tcp \
from ssh-whitelist to $ext_if port ssh \
flags S/SA keep state
pass in on $ext_if proto tcp \
from !ssh-whitelist to $ext_if port ssh \
flags S/SA keep state \
(max-src-conn-rate 3/30, overload ssh-bruteforce flush global)
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEUEARECAAYFAkuROYMACgkQ8Mjk52CukIwA7ACfcngE3ZsQmRAoTY7sW9aqXfLv
IW8Al1Pl4OaGfWbytHAYrfqnWYpNs40=
=Yg12
-END PGP SIGNATURE-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On Fri, Mar 05, 2010 at 05:04:03PM +, Matthew Seaman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2010 16:54:50, Matthias Fechner wrote:
Hi,
Am 05.03.10 17:01, schrieb Matthew Seaman:
table ssh-bruteforce persist
[...near the top of the rules section...]
block drop in log quick on $ext_if fromssh-bruteforce
[...later in the rules section...]
pass in on $ext_if proto tcp \
from any to $ext_if port ssh \
flags S/SA keep state\
(max-src-conn-rate 3/30, overloadssh-bruteforce flush global)
that is dangarous, if you use subversion over ssh you will sometimes get
more then 10 requests in 30 seconds.
That means you will also block users they are allowed to connect.
Yes. Almost all of the time I use this I've also had a ssh-whitelist
table -- addresses that will never be blocked in this way. Like this:
table ssh-bruteforce persist
table ssh-whitelist const { \
81.187.76.160/29 \
2001:8b0:151:1::/64 \
} persist
block drop in log quick on $ext_if from ssh-bruteforce
pass in on $ext_if proto tcp \
from ssh-whitelist to $ext_if port ssh \
flags S/SA keep state
pass in on $ext_if proto tcp \
from !ssh-whitelist to $ext_if port ssh \
flags S/SA keep state \
(max-src-conn-rate 3/30, overload ssh-bruteforce flush global)
Ah. I see. That's clever. Rather than overriding the bruteforce
list, which would require getting rid of quick, you use whitelist
to prevent things from ever going into the bruteforce table.
Nice!
I have just switched to pf from ipfw, so I am still learning the
nuances and style points.
--
John Lind
j...@starfire.mn.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
Hi, Am 05.03.2010 18:10, schrieb John: I have just switched to pf from ipfw, so I am still learning the nuances and style points. I switched now to security/sshguard-pf. It works perfectly and blocks also via pf. Blocking is working there with: table sshguard persist block in log quick proto tcp from sshguard to any label ssh bruteforce probability 85% So I let 15% of the pakets through in the hope that will slow down this brute force attacks and I can protect in this step other hosts. Hopefully the attacker keeps then longer in my tarpit. Bye Matthias -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. -- Rich Cook ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
Thousands of ssh probes Friday, March 5, 2010 1:54 PM From: John j...@starfire.mn.org To: freebsd-questions@freebsd.org My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? -- John Lind j...@starfire.mn.org * Hi John, I'm using pf as a firewall on FreeBSD. I used this handy website: http://www.bgnett.no/~peter/pf/en/bruteforce.html and especially this part: max-src-conn is the number of simultaneous connections you allow from one host. In this example, I've set it at 100, in your setup you may want a slightly higher or lower value. max-src-conn-rate is the rate of new connections allowed from any single host, here 15 connections per 5 seconds. Again, you are the one to judge what suits your setup. I then looked at ssh itself. Key-based authentication only is what I'm allowing on my network now and I have put the AllowUsers directive in my sshd_config. At the moment I'm so paranoid that I'm reading into this Mandatory Access Control part of the handbook as well. Good luck,Dino ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
Replies interspersed On 3/5/10, John j...@starfire.mn.org wrote: On Fri, Mar 05, 2010 at 07:03:53AM -0600, Programmer In Training wrote: On 03/05/10 06:54, John wrote: My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? Can you not deny all ssh attempts and then allow only from certain, trusted IPs? Ah, I should have added that I travel a fair amount, and often have to get to my systems via hotel WiFi or Aircard, so it's impossible to predict my originating IP address in advance. If that were not the case, this would be an excellent suggestion. I've been in that same boat. I eventually came to the decision to: Install PPTP server software, accepting connections from any IP. Once connected with PPTP, edit the sshd rule in pf to allow sshd connections. Optionally reconnect for sshd only. It's worked well. -- Yours In Christ, PIT Emails are not formal business letters, whatever businesses may want. Original content copyright under the OWL http://owl.apotheon.org Please do not CC me. If I'm posting to a list it is because I am subscribed. -- John Lind j...@starfire.mn.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
Matthew Seaman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2010 16:12:11, Randal L. Schwartz wrote: Matthew == Matthew Seaman m.sea...@infracaninophile.co.uk writes: Matthew On 05/03/2010 15:51:52, Randal L. Schwartz wrote: The spamtrap is a shiny object for spam, and anything that goes there gets blocked for an hour from hitting the low port. I presented this at a conference once. Matthew Having an IPv6-only high-mx seems to terminally confuse most spambots... Oooh! And arpnetworks gives me a /48 in 6 for free. I could have thousands of them. :) Thousands? Try billions. Sagans and sagans. More than the maximum possible number of hosts on the IPv4 internet. Muha ha Ha! I'd think we might have to increase the size of the container for /etc/rc.conf to do that, though? At any rate, that'd be a lot of ifconfig to read/edit/etc. KDK ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On 05/03/2010 13:26, John wrote: Ah, I should have added that I travel a fair amount, and often have to get to my systems via hotel WiFi or Aircard, so it's impossible to predict my originating IP address in advance. If that were not the case, this would be an excellent suggestion. What about the option of vpn access ? Mike Woods Full of squishy cynicism ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
Tim == Tim Judd taj...@gmail.com writes: Tim I've been in that same boat. I eventually came to the decision to: Tim Install PPTP server software, accepting connections from any IP. Whoa. Here we are, talking about making it *more* secure, and you go the other direction http://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol#Security_of_the_PPTP_protocol In short, you can't take anyone seriously who suggests PPTP when talking about security. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
Randal L. Schwartz wrote: Tim == Tim Judd taj...@gmail.com writes: Tim I've been in that same boat. I eventually came to the decision to: Tim Install PPTP server software, accepting connections from any IP. Whoa. Here we are, talking about making it *more* secure, and you go the other direction http://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol#Security_of_the_PPTP_protocol In short, you can't take anyone seriously who suggests PPTP when talking about security. Especially since rolling out OpenVPN and your own little CA to issue yourself and your 10 best friends certificates is pretty easy. I find it easier to wrap my head around than something like IPSEC for supporting a trusted server on trusted network attached to by laptops that wander around in sometimes sleazy parts of the Internet model. Just make sure you've kept up to date with your SSL libraries. :-) --Jon Radel j...@radel.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On 05/03/10 13:54, John wrote: My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? This is a frequent question on the list, search the archives. Basically there are few things that you can do: 1. limit the access to a range of IPs, for example, even if you travel a lot you go to al limited number of countries, why permit access from other continents? 2. limit access to certain users, there is no need to allow games or root user to authenticate via ssh. Use AllowUsers or AllowGroups to restrict access to real users. 3. limit the amount of concurrent non-authenticated connections, number of failed attempts and similar. 4. prohibit password authentication. If the problem is that these attacks consume significant bandwidth then moving your service to a different port may be a good solution, but if your concern is security, then the above is more effective. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On 3/5/2010 7:44 PM, Erik Norgaard wrote: On 05/03/10 13:54, John wrote: My nightly security logs have thousands upon thousands of ssh probes in them. One day, over 6500. This is enough that I can actually feel it in my network performance. Other than changing ssh to a non-standard port - is there a way to deal with these? Every day, they originate from several different IP addresses, so I can't just put in a static firewall rule. Is there a way to get ssh to quit responding to a port or a way to generate a dynamic pf rule in cases like this? This is a frequent question on the list, search the archives. Basically there are few things that you can do: 1. limit the access to a range of IPs, for example, even if you travel a lot you go to al limited number of countries, why permit access from other continents? 2. limit access to certain users, there is no need to allow games or root user to authenticate via ssh. Use AllowUsers or AllowGroups to restrict access to real users. 3. limit the amount of concurrent non-authenticated connections, number of failed attempts and similar. 4. prohibit password authentication. If the problem is that these attacks consume significant bandwidth then moving your service to a different port may be a good solution, but if your concern is security, then the above is more effective. BR, Erik I solved this problem a slightly different way with dynamic TCP wrapper control: http://www.tundraware.com/Software/tperimeter/ -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
On 3/5/10, Randal L. Schwartz mer...@stonehenge.com wrote: Tim == Tim Judd taj...@gmail.com writes: Tim I've been in that same boat. I eventually came to the decision to: Tim Install PPTP server software, accepting connections from any IP. Whoa. Here we are, talking about making it *more* secure, and you go the other direction http://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol#Security_of_the_PPTP_protocol In short, you can't take anyone seriously who suggests PPTP when talking about security. Randal, It's not meant as the solution for remote access. It's only a stopgap so you can ssh into your router and add the remote IP. Then disconnect from the VPN you've configured, PPTP or not, and use SSH. And the fact that I haven't (yet) seen random bots try vpn will keep my logs clean. I'm sorry, I respect Randal very much, but.. A) ..wikipedia? that's informative and useful, but not authoritative in any way. B) It's connected for maybe 5 minutes at most. While connected, your ssh session is still encrypted while you add the current remote IP. I stand by my statements. The other way (which requires a cron job) is to setup your roaming laptop with a dyndns address (or similar service) and have your router re-load it's firewall config periodically for any possible IPv4/IPv6 address changes to be picked up. I haven't done this to finish yet. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
That was just the quick summary. Google for PPTP security and you'll see a top link from Bruce Schneier who basically says no way to it. Sent from my iPhone, so blame Steve Jobs for any speeling misteaks. On Mar 5, 2010, at 9:20 PM, Tim Judd taj...@gmail.com wrote: ..wikipedia? that's informative and useful, but not authoritative in any way. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Thousands of ssh probes
In freebsd-questions Digest, Vol 300, Issue 10, Message: 6 On Fri, 05 Mar 2010 16:07:29 + Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/03/2010 15:51:52, Randal L. Schwartz wrote: The spamtrap is a shiny object for spam, and anything that goes there gets blocked for an hour from hitting the low port. I presented this at a conference once. Having an IPv6-only high-mx seems to terminally confuse most spambots... I understand why IPv6 would confuse them, but don't follow why higher numbered MXs would be more attractive to them in the first place? Are they assuming a 'secondary' MX will be more likely to accept spam? cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
