Re: Blocking "shodan.io" - What are my options?
Sorry, I haven't tried it yet. I'll do it ASAP. On Tue, 15 Jan 2019 21:05:32 -0600 ed...@pettijohn-web.com wrote: > On Sun, Jan 13, 2019 at 01:39:13PM -0600, ed...@pettijohn-web.com wrote: > > On Sun, Jan 13, 2019 at 08:04:32PM +0100, Radek wrote: > > > Hi, > > > > > > I would gladly play with your script. Would you please share it @misc. > > > Maybe our community could develope it further... > > Just curious if anyone has tried it out. I've been running it for about > 48 hours now and it doesn't appear to be having any issues. Plus my pf > table is growing. > > $ doas pfctl -t badguys -T show | wc -l > 697 > > I have it running on about 10 ports. Obviously the majority of the scans > are on 22, but I was surprised to see so many on 23. > > $ egrep "23$" /var/log/messages | wc -l > 247 > > Edgar > > > > > > > On Sun, 13 Jan 2019 12:43:15 -0600 > > > ed...@pettijohn-web.com wrote: > > > > > > > On Fri, Jan 11, 2019 at 09:30:38AM +1100, Aaron Mason wrote: > > > > > I knew it wouldn't trigger on the first attempt, but I had a sneaking > > > > > suspicion that you'd need something to listen on that port. Is there > > > > > a way to achieve what we seek, in that case, without userland tools? > > > > > > > > > > On Thu, Jan 10, 2019 at 9:18 PM Stuart Henderson > > > > > wrote: > > > > > > > > > > > > On 2019-01-09, Aaron Mason wrote: > > > > > > > Hi Jordan > > > > > > > > > > > > > > I've set it up to try it, but I'm not having much luck. Even > > > > > > > when I > > > > > > > trigger more than one, it still doesn't populate the bad_hosts > > > > > > > table, > > > > > > > even again when I extend the rate period to 86400 seconds. I've > > > > > > > added > > > > > > > logging so I know the rule is triggering. See below. > > > > > > > > > > > > max-src-conn-rate is only triggered when a TCP connection is > > > > > > established, you need to have something listening (and it will only > > > > > > trigger on the *second* connection). > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Aaron Mason - Programmer, open source addict > > > > > I've taken my software vows - for beta or for worse > > > > > > > > > > > > > I wrote a little daemon to do what we're looking for. It listens on > > > > specified ports, accepts the connection and executes a script so you can > > > > either use something like logger or pfctl, etc to do what you want with > > > > the address it connected from. If anyone wants to play with it let me > > > > know and I'll send you the tarball. > > > > > > > > Edgar > > > > > > > > > > > > > -- > > > radek > > > > It can be obtained at http://www.pettijohn-web.com/void-1.0.0.tar.gz > > > > The manual isn't quite complete. The supplied script could really use > > some help as well as an rc script. The makefile is also cobbled > > together. It is pledged and unveiled. I think it can have a few of the > > pledges removed, but I haven't gotten that far. I think it is unveiled > > correctly, but this was my first time playing with it. > > > > The only requirement is libevent2 to aid in portability, which was the > > driving force behind executing a script so that it could tie into > > whatever packet filter is in use. Any constructive suggestions and > > patches are more than welcome. > > > > Enjoy. > > > > Edgar > > -- radek
Re: Blocking "shodan.io" - What are my options?
On Sun, Jan 13, 2019 at 01:39:13PM -0600, ed...@pettijohn-web.com wrote: > On Sun, Jan 13, 2019 at 08:04:32PM +0100, Radek wrote: > > Hi, > > > > I would gladly play with your script. Would you please share it @misc. > > Maybe our community could develope it further... Just curious if anyone has tried it out. I've been running it for about 48 hours now and it doesn't appear to be having any issues. Plus my pf table is growing. $ doas pfctl -t badguys -T show | wc -l 697 I have it running on about 10 ports. Obviously the majority of the scans are on 22, but I was surprised to see so many on 23. $ egrep "23$" /var/log/messages | wc -l 247 Edgar > > > > On Sun, 13 Jan 2019 12:43:15 -0600 > > ed...@pettijohn-web.com wrote: > > > > > On Fri, Jan 11, 2019 at 09:30:38AM +1100, Aaron Mason wrote: > > > > I knew it wouldn't trigger on the first attempt, but I had a sneaking > > > > suspicion that you'd need something to listen on that port. Is there > > > > a way to achieve what we seek, in that case, without userland tools? > > > > > > > > On Thu, Jan 10, 2019 at 9:18 PM Stuart Henderson > > > > wrote: > > > > > > > > > > On 2019-01-09, Aaron Mason wrote: > > > > > > Hi Jordan > > > > > > > > > > > > I've set it up to try it, but I'm not having much luck. Even when I > > > > > > trigger more than one, it still doesn't populate the bad_hosts > > > > > > table, > > > > > > even again when I extend the rate period to 86400 seconds. I've > > > > > > added > > > > > > logging so I know the rule is triggering. See below. > > > > > > > > > > max-src-conn-rate is only triggered when a TCP connection is > > > > > established, you need to have something listening (and it will only > > > > > trigger on the *second* connection). > > > > > > > > > > > > > > > > > > > > > > -- > > > > Aaron Mason - Programmer, open source addict > > > > I've taken my software vows - for beta or for worse > > > > > > > > > > I wrote a little daemon to do what we're looking for. It listens on > > > specified ports, accepts the connection and executes a script so you can > > > either use something like logger or pfctl, etc to do what you want with > > > the address it connected from. If anyone wants to play with it let me > > > know and I'll send you the tarball. > > > > > > Edgar > > > > > > > > > -- > > radek > > It can be obtained at http://www.pettijohn-web.com/void-1.0.0.tar.gz > > The manual isn't quite complete. The supplied script could really use > some help as well as an rc script. The makefile is also cobbled > together. It is pledged and unveiled. I think it can have a few of the > pledges removed, but I haven't gotten that far. I think it is unveiled > correctly, but this was my first time playing with it. > > The only requirement is libevent2 to aid in portability, which was the > driving force behind executing a script so that it could tie into > whatever packet filter is in use. Any constructive suggestions and > patches are more than welcome. > > Enjoy. > > Edgar >
Re: Blocking "shodan.io" - What are my options?
On Sun, Jan 13, 2019 at 08:04:32PM +0100, Radek wrote: > Hi, > > I would gladly play with your script. Would you please share it @misc. Maybe > our community could develope it further... > > On Sun, 13 Jan 2019 12:43:15 -0600 > ed...@pettijohn-web.com wrote: > > > On Fri, Jan 11, 2019 at 09:30:38AM +1100, Aaron Mason wrote: > > > I knew it wouldn't trigger on the first attempt, but I had a sneaking > > > suspicion that you'd need something to listen on that port. Is there > > > a way to achieve what we seek, in that case, without userland tools? > > > > > > On Thu, Jan 10, 2019 at 9:18 PM Stuart Henderson > > > wrote: > > > > > > > > On 2019-01-09, Aaron Mason wrote: > > > > > Hi Jordan > > > > > > > > > > I've set it up to try it, but I'm not having much luck. Even when I > > > > > trigger more than one, it still doesn't populate the bad_hosts table, > > > > > even again when I extend the rate period to 86400 seconds. I've added > > > > > logging so I know the rule is triggering. See below. > > > > > > > > max-src-conn-rate is only triggered when a TCP connection is > > > > established, you need to have something listening (and it will only > > > > trigger on the *second* connection). > > > > > > > > > > > > > > > > > -- > > > Aaron Mason - Programmer, open source addict > > > I've taken my software vows - for beta or for worse > > > > > > > I wrote a little daemon to do what we're looking for. It listens on > > specified ports, accepts the connection and executes a script so you can > > either use something like logger or pfctl, etc to do what you want with > > the address it connected from. If anyone wants to play with it let me > > know and I'll send you the tarball. > > > > Edgar > > > > > -- > radek It can be obtained at http://www.pettijohn-web.com/void-1.0.0.tar.gz The manual isn't quite complete. The supplied script could really use some help as well as an rc script. The makefile is also cobbled together. It is pledged and unveiled. I think it can have a few of the pledges removed, but I haven't gotten that far. I think it is unveiled correctly, but this was my first time playing with it. The only requirement is libevent2 to aid in portability, which was the driving force behind executing a script so that it could tie into whatever packet filter is in use. Any constructive suggestions and patches are more than welcome. Enjoy. Edgar
Re: Blocking "shodan.io" - What are my options?
Hi, I would gladly play with your script. Would you please share it @misc. Maybe our community could develope it further... On Sun, 13 Jan 2019 12:43:15 -0600 ed...@pettijohn-web.com wrote: > On Fri, Jan 11, 2019 at 09:30:38AM +1100, Aaron Mason wrote: > > I knew it wouldn't trigger on the first attempt, but I had a sneaking > > suspicion that you'd need something to listen on that port. Is there > > a way to achieve what we seek, in that case, without userland tools? > > > > On Thu, Jan 10, 2019 at 9:18 PM Stuart Henderson > > wrote: > > > > > > On 2019-01-09, Aaron Mason wrote: > > > > Hi Jordan > > > > > > > > I've set it up to try it, but I'm not having much luck. Even when I > > > > trigger more than one, it still doesn't populate the bad_hosts table, > > > > even again when I extend the rate period to 86400 seconds. I've added > > > > logging so I know the rule is triggering. See below. > > > > > > max-src-conn-rate is only triggered when a TCP connection is > > > established, you need to have something listening (and it will only > > > trigger on the *second* connection). > > > > > > > > > > > > -- > > Aaron Mason - Programmer, open source addict > > I've taken my software vows - for beta or for worse > > > > I wrote a little daemon to do what we're looking for. It listens on > specified ports, accepts the connection and executes a script so you can > either use something like logger or pfctl, etc to do what you want with > the address it connected from. If anyone wants to play with it let me > know and I'll send you the tarball. > > Edgar > -- radek
Re: Blocking "shodan.io" - What are my options?
On Fri, Jan 11, 2019 at 09:30:38AM +1100, Aaron Mason wrote: > I knew it wouldn't trigger on the first attempt, but I had a sneaking > suspicion that you'd need something to listen on that port. Is there > a way to achieve what we seek, in that case, without userland tools? > > On Thu, Jan 10, 2019 at 9:18 PM Stuart Henderson wrote: > > > > On 2019-01-09, Aaron Mason wrote: > > > Hi Jordan > > > > > > I've set it up to try it, but I'm not having much luck. Even when I > > > trigger more than one, it still doesn't populate the bad_hosts table, > > > even again when I extend the rate period to 86400 seconds. I've added > > > logging so I know the rule is triggering. See below. > > > > max-src-conn-rate is only triggered when a TCP connection is > > established, you need to have something listening (and it will only > > trigger on the *second* connection). > > > > > > > -- > Aaron Mason - Programmer, open source addict > I've taken my software vows - for beta or for worse > I wrote a little daemon to do what we're looking for. It listens on specified ports, accepts the connection and executes a script so you can either use something like logger or pfctl, etc to do what you want with the address it connected from. If anyone wants to play with it let me know and I'll send you the tarball. Edgar
Re: Blocking "shodan.io" - What are my options?
On 2019-01-10, Aaron Mason wrote: > On Thu, Jan 10, 2019 at 9:18 PM Stuart Henderson wrote: >> >> On 2019-01-09, Aaron Mason wrote: >> > Hi Jordan >> > >> > I've set it up to try it, but I'm not having much luck. Even when I >> > trigger more than one, it still doesn't populate the bad_hosts table, >> > even again when I extend the rate period to 86400 seconds. I've added >> > logging so I know the rule is triggering. See below. >> >> max-src-conn-rate is only triggered when a TCP connection is >> established, you need to have something listening (and it will only >> trigger on the *second* connection). >> > I knew it wouldn't trigger on the first attempt, but I had a sneaking > suspicion that you'd need something to listen on that port. Is there > a way to achieve what we seek, in that case, without userland tools? No. But you could probably manage it with just one listening port to cover all the ones you're interested in (via rdr-to).
Re: Blocking "shodan.io" - What are my options?
I knew it wouldn't trigger on the first attempt, but I had a sneaking suspicion that you'd need something to listen on that port. Is there a way to achieve what we seek, in that case, without userland tools? On Thu, Jan 10, 2019 at 9:18 PM Stuart Henderson wrote: > > On 2019-01-09, Aaron Mason wrote: > > Hi Jordan > > > > I've set it up to try it, but I'm not having much luck. Even when I > > trigger more than one, it still doesn't populate the bad_hosts table, > > even again when I extend the rate period to 86400 seconds. I've added > > logging so I know the rule is triggering. See below. > > max-src-conn-rate is only triggered when a TCP connection is > established, you need to have something listening (and it will only > trigger on the *second* connection). > > -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: Blocking "shodan.io" - What are my options?
On 2019-01-09, Aaron Mason wrote: > Hi Jordan > > I've set it up to try it, but I'm not having much luck. Even when I > trigger more than one, it still doesn't populate the bad_hosts table, > even again when I extend the rate period to 86400 seconds. I've added > logging so I know the rule is triggering. See below. max-src-conn-rate is only triggered when a TCP connection is established, you need to have something listening (and it will only trigger on the *second* connection).
Re: Blocking "shodan.io" - What are my options?
Hi Jordan
I've set it up to try it, but I'm not having much luck. Even when I
trigger more than one, it still doesn't populate the bad_hosts table,
even again when I extend the rate period to 86400 seconds. I've added
logging so I know the rule is triggering. See below.
git# tcpdump -i pflog0
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
08:50:41.100611 111-222-33-45.dyn.isp.net.au.49643 >
git.mydomain.com.telnet: S 3935794887:3935794887(0) win 8192 (DF)
08:50:41.630593 111-222-33-45.dyn.isp.net.au.49643 >
git.mydomain.com.telnet: S 3935794887:3935794887(0) win 8192 (DF)
08:50:42.155612 111-222-33-45.dyn.isp.net.au.49643 >
git.mydomain.com.telnet: S 3935794887:3935794887(0) win 8192 (DF)
08:50:43.496590 111-222-33-45.dyn.isp.net.au.49649 >
git.mydomain.com.telnet: S 2579184023:2579184023(0) win 8192 (DF)
08:50:44.038541 111-222-33-45.dyn.isp.net.au.49649 >
git.mydomain.com.telnet: S 2579184023:2579184023(0) win 8192 (DF)
08:50:44.571563 111-222-33-45.dyn.isp.net.au.49649 >
git.mydomain.com.telnet: S 2579184023:2579184023(0) win 8192 (DF)
08:50:46.879666 111-222-33-45.dyn.isp.net.au.49660 >
git.mydomain.com.telnet: S 1029456025:1029456025(0) win 8192 (DF)
08:50:47.408720 111-222-33-45.dyn.isp.net.au.49660 >
git.mydomain.com.telnet: S 1029456025:1029456025(0) win 8192 (DF)
08:50:47.938650 111-222-33-45.dyn.isp.net.au.49660 >
git.mydomain.com.telnet: S 1029456025:1029456025(0) win 8192 (DF)
^C
9 packets received by filter
0 packets dropped by kernel
git# cat /etc/pf.conf
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
ext_if=vio0
ext_ip=111.222.33.44
set skip on lo
block return# block stateless traffic
pass# establish keep-state
block quick from
pass in log on $ext_if proto tcp to $ext_ip port telnet keep state
(max-src-conn-rate 1/86400, overload flush global)
# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010
# Port build user does not need network
block return out log proto {tcp udp} user _pbuild
git#
On Wed, Jan 9, 2019 at 1:30 PM Jordan Geoghegan wrote:
>
>
>
> On 01/08/19 18:08, tomr wrote:
> >
> > On 1/9/19 12:42 PM, Jordan Geoghegan wrote:
> >> Yikes. Everything you are (erroneously) trying to do here can be done
> >> without leaving your pf.conf.
> >>
> >> Remember, KISS.
> >>
> > Is there a way to add an address to a table from within a rule, or
> > something to that effect? I can't see such an option. A la...
> >
> > block in quick on $ext_if to any port ! { $allowed_ports } add-to
> >
> >
> > (Otherwise I don't see how the whole show could be completed without
> > logging, monitoring the log, then running pfctl, ie with leaving your
> > pf.conf)
>
> Without wasting too much time on this, the "overload" example from the
> pf.conf man page could be pretty easily adapted to meet the specified needs:
>
> pass in on egress proto tcp to egress port 22 keep state
> (max-src-conn-rate 1/10, overload flush global)
>
> or to copy basically verbatim from the man page, (with only the
> src-conn-rate and port number adjusted):
>
> block quick from
> pass in on $ext_if proto tcp to $webserver port ssh keep state \
>(max-src-conn-rate 1/10, overload flush global)
>
>
> I havent tested this personally, but it should be adequate.
>
>
>
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: Blocking "shodan.io" - What are my options?
Hi,
I am bit surprised how this subject has spiralled. Interesting reading from all
the comments and suggestions.
Nino
> On 9 Jan 2019, at 1:23 pm, Jordan Geoghegan wrote:
>
>
>
> On 01/08/19 18:08, tomr wrote:
>>
>> On 1/9/19 12:42 PM, Jordan Geoghegan wrote:
>>> Yikes. Everything you are (erroneously) trying to do here can be done
>>> without leaving your pf.conf.
>>>
>>> Remember, KISS.
>>>
>> Is there a way to add an address to a table from within a rule, or
>> something to that effect? I can't see such an option. A la...
>>
>> block in quick on $ext_if to any port ! { $allowed_ports } add-to
>>
>>
>> (Otherwise I don't see how the whole show could be completed without
>> logging, monitoring the log, then running pfctl, ie with leaving your
>> pf.conf)
>
> Without wasting too much time on this, the "overload" example from the
> pf.conf man page could be pretty easily adapted to meet the specified needs:
>
> pass in on egress proto tcp to egress port 22 keep state (max-src-conn-rate
> 1/10, overload flush global)
>
> or to copy basically verbatim from the man page, (with only the src-conn-rate
> and port number adjusted):
>
> block quick from
> pass in on $ext_if proto tcp to $webserver port ssh keep state \
> (max-src-conn-rate 1/10, overload flush global)
>
>
> I havent tested this personally, but it should be adequate.
>
>
>
Re: Blocking "shodan.io" - What are my options?
On 01/08/19 18:08, tomr wrote:
On 1/9/19 12:42 PM, Jordan Geoghegan wrote:
Yikes. Everything you are (erroneously) trying to do here can be done
without leaving your pf.conf.
Remember, KISS.
Is there a way to add an address to a table from within a rule, or
something to that effect? I can't see such an option. A la...
block in quick on $ext_if to any port ! { $allowed_ports } add-to
(Otherwise I don't see how the whole show could be completed without
logging, monitoring the log, then running pfctl, ie with leaving your
pf.conf)
Without wasting too much time on this, the "overload" example from the
pf.conf man page could be pretty easily adapted to meet the specified needs:
pass in on egress proto tcp to egress port 22 keep state
(max-src-conn-rate 1/10, overload flush global)
or to copy basically verbatim from the man page, (with only the
src-conn-rate and port number adjusted):
block quick from
pass in on $ext_if proto tcp to $webserver port ssh keep state \
(max-src-conn-rate 1/10, overload flush global)
I havent tested this personally, but it should be adequate.
Re: Blocking "shodan.io" - What are my options?
On 1/9/19 12:42 PM, Jordan Geoghegan wrote:
>
> Yikes. Everything you are (erroneously) trying to do here can be done
> without leaving your pf.conf.
>
> Remember, KISS.
>
Is there a way to add an address to a table from within a rule, or
something to that effect? I can't see such an option. A la...
block in quick on $ext_if to any port ! { $allowed_ports } add-to
(Otherwise I don't see how the whole show could be completed without
logging, monitoring the log, then running pfctl, ie with leaving your
pf.conf)
Re: Blocking "shodan.io" - What are my options?
On 01/08/19 16:46, Daniel Jakots wrote: On Tue, 8 Jan 2019 16:07:43 -0800, Misc User wrote: Doing some work on it the other day, I noticed it opens a pretty big command injection hole if pfctl doesn't kill the connection before the connecting source gets a chance to send data. An attacker could connect to the port and send the string "Ncat: Connection from 172.16.11.152.\ && " and whatever it uses for will be done by a privileged account (At least one with permissions to add entries to pf's tables) I tested it using a telnet client connecting to one of the arbitrary ports I set up. So I've been trying to figure out a better way to do this. There has to be, maybe something with tcpdump. I'm looking into patching ncat to have a flag where the -v option doesn't output packet content, and only outputs packet metadata. Probably also clean up what it outputs to produce a 'honeypot' mode or something friendly to chaining to a firewall control program. I'm truly amazed that you just realized you enabled people to run code on your machine with a privileged user, and instead of dropping the gun, you're like "maybe if I hold it with two hands, I won't shoot myself in the foot again". People say "don't roll your own crypto" but it seems it applies to honeypot software too. I must say this thread has turned into a pretty apt example of the Dunning-Kruger effect...
Re: Blocking "shodan.io" - What are my options?
On 01/08/19 16:07, Misc User wrote:
On 1/8/2019 3:16 PM, Aaron Mason wrote:
On Sat, Jan 5, 2019 at 5:46 AM Misc User
wrote:
On 1/3/2019 11:20 PM, Radek wrote:
A little ncat, sed, pfctl, and a dash of cron are able to do
the job just fine. cron is just there to start the ncat processes at
boot and run an hourly script to do a pfctl -T expire
86400 to
keep the table clean of old attackers.
Sounds good. Could you share your script here?
I don't have access to my systems right now, but the script is pretty
much a couple of one-liners in crontab, somethings similar to:
ncat -l -k 23 -vv | sed s/// | xargs -R 1 -I % pfctl -t
honeypot
-T add %
I'll have to look up the exact command when I get get home tonight,
especially the sed I used. Running on my local system, the ncat
command
echoes out lines like:
Ncat: Connection from 172.16.11.152.
Ncat: Connection from 172.16.11.152:57562.
If I get the time today, I'll work on re-creating the regex, if not,
I'll share the one I've been using on my systems.
Hi
Any news on this? I've tried building my own and while I can get a
list of IP addresses, nothing gets sent through to xargs. They appear
if I leave off the xargs bit:
git# nc -vnkl 21 2>&1 | sed -E 's/^Connection from
([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}) [0-9]*
received!$/\1/'
111.222.33.44
^C
git#
But if I include the pipe to xargs, nothing happens, I still get
nothing happening if I change it to a while loop, using read to pull
in the IP address.
This works, though, though it assumes that the output for nc(1) will
stay the same forever - it's also IPv6 ready unlike my example above:
nc -vnkl 21 2>&1 | while read dummy dummy ipaddr dummy dummy; do pfctl
-t honeypot -T add $ipaddr; done
Doing some work on it the other day, I noticed it opens a pretty big
command injection hole if pfctl doesn't kill the connection before the
connecting source gets a chance to send data. An attacker could
connect to the port and send the string "Ncat: Connection from
172.16.11.152.\ && " and whatever it uses for
will be done by a privileged account (At least one with permissions to
add entries to pf's tables)
I tested it using a telnet client connecting to one of the arbitrary
ports I set up. So I've been trying to figure out a better way to do
this. There has to be, maybe something with tcpdump.
I'm looking into patching ncat to have a flag where the -v option
doesn't output packet content, and only outputs packet metadata.
Probably also clean up what it outputs to produce a 'honeypot' mode or
something friendly to chaining to a firewall control program.
-CA
.
Yikes. Everything you are (erroneously) trying to do here can be done
without leaving your pf.conf.
Remember, KISS.
Re: Blocking "shodan.io" - What are my options?
On Tue, 8 Jan 2019 16:07:43 -0800, Misc User wrote: > Doing some work on it the other day, I noticed it opens a pretty big > command injection hole if pfctl doesn't kill the connection before > the connecting source gets a chance to send data. An attacker could > connect to the port and send the string "Ncat: Connection from > 172.16.11.152.\ && " and whatever it uses for > will be done by a privileged account (At least one with permissions > to add entries to pf's tables) > > I tested it using a telnet client connecting to one of the arbitrary > ports I set up. So I've been trying to figure out a better way to do > this. There has to be, maybe something with tcpdump. > > I'm looking into patching ncat to have a flag where the -v option > doesn't output packet content, and only outputs packet metadata. > Probably also clean up what it outputs to produce a 'honeypot' mode > or something friendly to chaining to a firewall control program. I'm truly amazed that you just realized you enabled people to run code on your machine with a privileged user, and instead of dropping the gun, you're like "maybe if I hold it with two hands, I won't shoot myself in the foot again". People say "don't roll your own crypto" but it seems it applies to honeypot software too.
Re: Blocking "shodan.io" - What are my options?
On 1/8/2019 3:16 PM, Aaron Mason wrote:
On Sat, Jan 5, 2019 at 5:46 AM Misc User wrote:
On 1/3/2019 11:20 PM, Radek wrote:
A little ncat, sed, pfctl, and a dash of cron are able to do
the job just fine. cron is just there to start the ncat processes at
boot and run an hourly script to do a pfctl -T expire 86400 to
keep the table clean of old attackers.
Sounds good. Could you share your script here?
I don't have access to my systems right now, but the script is pretty
much a couple of one-liners in crontab, somethings similar to:
ncat -l -k 23 -vv | sed s/// | xargs -R 1 -I % pfctl -t honeypot
-T add %
I'll have to look up the exact command when I get get home tonight,
especially the sed I used. Running on my local system, the ncat command
echoes out lines like:
Ncat: Connection from 172.16.11.152.
Ncat: Connection from 172.16.11.152:57562.
If I get the time today, I'll work on re-creating the regex, if not,
I'll share the one I've been using on my systems.
Hi
Any news on this? I've tried building my own and while I can get a
list of IP addresses, nothing gets sent through to xargs. They appear
if I leave off the xargs bit:
git# nc -vnkl 21 2>&1 | sed -E 's/^Connection from
([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}) [0-9]*
received!$/\1/'
111.222.33.44
^C
git#
But if I include the pipe to xargs, nothing happens, I still get
nothing happening if I change it to a while loop, using read to pull
in the IP address.
This works, though, though it assumes that the output for nc(1) will
stay the same forever - it's also IPv6 ready unlike my example above:
nc -vnkl 21 2>&1 | while read dummy dummy ipaddr dummy dummy; do pfctl
-t honeypot -T add $ipaddr; done
Doing some work on it the other day, I noticed it opens a pretty big
command injection hole if pfctl doesn't kill the connection before the
connecting source gets a chance to send data. An attacker could connect
to the port and send the string "Ncat: Connection from 172.16.11.152.\
&& " and whatever it uses for will be done by a
privileged account (At least one with permissions to add entries to pf's
tables)
I tested it using a telnet client connecting to one of the arbitrary
ports I set up. So I've been trying to figure out a better way to do
this. There has to be, maybe something with tcpdump.
I'm looking into patching ncat to have a flag where the -v option
doesn't output packet content, and only outputs packet metadata.
Probably also clean up what it outputs to produce a 'honeypot' mode or
something friendly to chaining to a firewall control program.
-CA
.
Re: Blocking "shodan.io" - What are my options?
On Sat, Jan 5, 2019 at 5:46 AM Misc User wrote:
>
> On 1/3/2019 11:20 PM, Radek wrote:
> >> A little ncat, sed, pfctl, and a dash of cron are able to do
> >> the job just fine. cron is just there to start the ncat processes at
> >> boot and run an hourly script to do a pfctl -T expire 86400 to
> >> keep the table clean of old attackers.
> > Sounds good. Could you share your script here?
> >
>
> I don't have access to my systems right now, but the script is pretty
> much a couple of one-liners in crontab, somethings similar to:
>
> ncat -l -k 23 -vv | sed s/// | xargs -R 1 -I % pfctl -t honeypot
> -T add %
>
> I'll have to look up the exact command when I get get home tonight,
> especially the sed I used. Running on my local system, the ncat command
> echoes out lines like:
>
> Ncat: Connection from 172.16.11.152.
> Ncat: Connection from 172.16.11.152:57562.
>
> If I get the time today, I'll work on re-creating the regex, if not,
> I'll share the one I've been using on my systems.
>
Hi
Any news on this? I've tried building my own and while I can get a
list of IP addresses, nothing gets sent through to xargs. They appear
if I leave off the xargs bit:
git# nc -vnkl 21 2>&1 | sed -E 's/^Connection from
([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}) [0-9]*
received!$/\1/'
111.222.33.44
^C
git#
But if I include the pipe to xargs, nothing happens, I still get
nothing happening if I change it to a while loop, using read to pull
in the IP address.
This works, though, though it assumes that the output for nc(1) will
stay the same forever - it's also IPv6 ready unlike my example above:
nc -vnkl 21 2>&1 | while read dummy dummy ipaddr dummy dummy; do pfctl
-t honeypot -T add $ipaddr; done
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: Blocking "shodan.io" - What are my options?
On Jan 4, 2019 12:44 PM, Misc User wrote: > > On 1/3/2019 11:20 PM, Radek wrote: > >> A little ncat, sed, pfctl, and a dash of cron are able to do > >> the job just fine. cron is just there to start the ncat processes at > >> boot and run an hourly script to do a pfctl -T expire 86400 to > >> keep the table clean of old attackers. > > Sounds good. Could you share your script here? > > > > I don't have access to my systems right now, but the script is pretty > much a couple of one-liners in crontab, somethings similar to: > > ncat -l -k 23 -vv | sed s/// | xargs -R 1 -I % pfctl -t honeypot > -T add % > > I'll have to look up the exact command when I get get home tonight, > especially the sed I used. Running on my local system, the ncat command > echoes out lines like: > > Ncat: Connection from 172.16.11.152. > Ncat: Connection from 172.16.11.152:57562. > > If I get the time today, I'll work on re-creating the regex, if not, > I'll share the one I've been using on my systems. > > I'm curious what the security/performance cons to something like: nc -kl 22 > /dev/null & You wouldn't get the benefits of a pf table but it would still be fun knowing they are wasting their time. Edgar
Re: Blocking "shodan.io" - What are my options?
On 1/3/2019 11:20 PM, Radek wrote: A little ncat, sed, pfctl, and a dash of cron are able to do the job just fine. cron is just there to start the ncat processes at boot and run an hourly script to do a pfctl -T expire 86400 to keep the table clean of old attackers. Sounds good. Could you share your script here? I don't have access to my systems right now, but the script is pretty much a couple of one-liners in crontab, somethings similar to: ncat -l -k 23 -vv | sed s/// | xargs -R 1 -I % pfctl -t honeypot -T add % I'll have to look up the exact command when I get get home tonight, especially the sed I used. Running on my local system, the ncat command echoes out lines like: Ncat: Connection from 172.16.11.152. Ncat: Connection from 172.16.11.152:57562. If I get the time today, I'll work on re-creating the regex, if not, I'll share the one I've been using on my systems.
Re: Blocking "shodan.io" - What are my options?
> A little ncat, sed, pfctl, and a dash of cron are able to do > the job just fine. cron is just there to start the ncat processes at > boot and run an hourly script to do a pfctl -T expire 86400 to > keep the table clean of old attackers. Sounds good. Could you share your script here? On Thu, 3 Jan 2019 15:20:44 -0800 Misc User wrote: > On 1/3/2019 3:06 PM, Jordan Geoghegan wrote: > > Hello, > > > > I wrote a small script called 'pf-badhost' to block shodan and other > > annoyances via pf firewall. Check out www.geoghegan.ca/pf-badhost.html > > to see the script. > > > > pf-badhost also blocks ssh bruteforcers and other annoyances by loading > > a list of regularly updated badhost lists from trusted sources. If you > > only want to block shodan specifically, just comment out the few lines > > that download the other blocklists, and you should be good to go. I've > > had a number of people give good feedback on it, and they've reported it > > blocking the scanners and baddies quite effectively; BSDNow also did a > > piece about it, so it seems to work alright. > > > > > > Cheers, > > > > Jordan > > > > > > On 01/02/19 22:15, Antonino Sidoti wrote: > >> Hi, > >> > >> I wish to block all attempts by "shodan.io". Basically I run an > >> OpenBSD (6.4) mail server using OpenSMTPD and notice quite bit of > >> traffic all stemming from "shodan.io". I have PF configured so I was > >> wondering how to block such a domain from making any attempts to > >> connect to my server. There is little information about Public IP > >> addresses being used by "shodan.io" scanner, so making an IP list for > >> PF may be futile. > >> > >> Could someone suggest a possible option? I was thinking along the > >> lines of "relayd" or "squid proxy". My server is hosted at Vultr and > >> has a single WAN interface with Public IP. There is no internal LAN > >> interface. > >> > >> For those who do not know about "shodan.io", please do a search and > >> you will discover what it does. > >> > >> Regards > >> > >> Nino > >> > > > > > I've always been a fan of just setting up a simple script to open a > couple ports with ncat, then when a client connects to the port, it gets > shoved into pf table that has a `drop' rule attached to it. No messing > about with blocklists or proxies or anything else. > > ncat listens on various low-number ports that nothing is using on my > servers. A little ncat, sed, pfctl, and a dash of cron are able to do > the job just fine. cron is just there to start the ncat processes at > boot and run an hourly script to do a pfctl -T expire 86400 to > keep the table clean of old attackers. > > Shodan isn't the only scanner out there, so there is no point in just > blocking it. And I figure if someone is trying to connect to unused > ports on my system, they probably aren't up to any good. If you aren't > aware that my machine isn't legitimately listening on 22 or 23, or 443, > I don't want to talk to you. > > I usually just run on port 22 and move sshd to a different port, that > seems to stop >95% of attackers. > > -- radek
Re: Blocking "shodan.io" - What are my options?
Hi Jordan, Sincere thanks for sharing your script. Also thanks to others for their input and comments. Regards Nino > On 4 Jan 2019, at 10:19 am, Jordan Geoghegan wrote: > > Sorry for the double post, I got the link to the script wrong... woops. > > The actual link is: > > www.geoghegan.ca/pfbadhost.html > > > On 01/03/19 15:06, Jordan Geoghegan wrote: >> Hello, >> >> I wrote a small script called 'pf-badhost' to block shodan and other >> annoyances via pf firewall. Check out www.geoghegan.ca/pf-badhost.html to >> see the script. >> >> pf-badhost also blocks ssh bruteforcers and other annoyances by loading a >> list of regularly updated badhost lists from trusted sources. If you only >> want to block shodan specifically, just comment out the few lines that >> download the other blocklists, and you should be good to go. I've had a >> number of people give good feedback on it, and they've reported it blocking >> the scanners and baddies quite effectively; BSDNow also did a piece about >> it, so it seems to work alright. >> >> >> Cheers, >> >> Jordan >> >> >> On 01/02/19 22:15, Antonino Sidoti wrote: >>> Hi, >>> >>> I wish to block all attempts by “shodan.io”. Basically I run an OpenBSD >>> (6.4) mail server using OpenSMTPD and notice quite bit of traffic all >>> stemming from “shodan.io". I have PF configured so I was wondering how to >>> block such a domain from making any attempts to connect to my server. There >>> is little information about Public IP addresses being used by "shodan.io" >>> scanner, so making an IP list for PF may be futile. >>> >>> Could someone suggest a possible option? I was thinking along the lines of >>> “relayd” or "squid proxy”. My server is hosted at Vultr and has a single >>> WAN interface with Public IP. There is no internal LAN interface. >>> >>> For those who do not know about “shodan.io”, please do a search and you >>> will discover what it does. >>> >>> Regards >>> >>> Nino >>> >> >
Re: Blocking "shodan.io" - What are my options?
On 1/3/2019 3:06 PM, Jordan Geoghegan wrote: Hello, I wrote a small script called 'pf-badhost' to block shodan and other annoyances via pf firewall. Check out www.geoghegan.ca/pf-badhost.html to see the script. pf-badhost also blocks ssh bruteforcers and other annoyances by loading a list of regularly updated badhost lists from trusted sources. If you only want to block shodan specifically, just comment out the few lines that download the other blocklists, and you should be good to go. I've had a number of people give good feedback on it, and they've reported it blocking the scanners and baddies quite effectively; BSDNow also did a piece about it, so it seems to work alright. Cheers, Jordan On 01/02/19 22:15, Antonino Sidoti wrote: Hi, I wish to block all attempts by “shodan.io”. Basically I run an OpenBSD (6.4) mail server using OpenSMTPD and notice quite bit of traffic all stemming from “shodan.io". I have PF configured so I was wondering how to block such a domain from making any attempts to connect to my server. There is little information about Public IP addresses being used by "shodan.io" scanner, so making an IP list for PF may be futile. Could someone suggest a possible option? I was thinking along the lines of “relayd” or "squid proxy”. My server is hosted at Vultr and has a single WAN interface with Public IP. There is no internal LAN interface. For those who do not know about “shodan.io”, please do a search and you will discover what it does. Regards Nino I've always been a fan of just setting up a simple script to open a couple ports with ncat, then when a client connects to the port, it gets shoved into pf table that has a `drop' rule attached to it. No messing about with blocklists or proxies or anything else. ncat listens on various low-number ports that nothing is using on my servers. A little ncat, sed, pfctl, and a dash of cron are able to do the job just fine. cron is just there to start the ncat processes at boot and run an hourly script to do a pfctl -T expire 86400 to keep the table clean of old attackers. Shodan isn't the only scanner out there, so there is no point in just blocking it. And I figure if someone is trying to connect to unused ports on my system, they probably aren't up to any good. If you aren't aware that my machine isn't legitimately listening on 22 or 23, or 443, I don't want to talk to you. I usually just run on port 22 and move sshd to a different port, that seems to stop >95% of attackers.
Re: Blocking "shodan.io" - What are my options?
Sorry for the double post, I got the link to the script wrong... woops. The actual link is: www.geoghegan.ca/pfbadhost.html On 01/03/19 15:06, Jordan Geoghegan wrote: Hello, I wrote a small script called 'pf-badhost' to block shodan and other annoyances via pf firewall. Check out www.geoghegan.ca/pf-badhost.html to see the script. pf-badhost also blocks ssh bruteforcers and other annoyances by loading a list of regularly updated badhost lists from trusted sources. If you only want to block shodan specifically, just comment out the few lines that download the other blocklists, and you should be good to go. I've had a number of people give good feedback on it, and they've reported it blocking the scanners and baddies quite effectively; BSDNow also did a piece about it, so it seems to work alright. Cheers, Jordan On 01/02/19 22:15, Antonino Sidoti wrote: Hi, I wish to block all attempts by “shodan.io”. Basically I run an OpenBSD (6.4) mail server using OpenSMTPD and notice quite bit of traffic all stemming from “shodan.io". I have PF configured so I was wondering how to block such a domain from making any attempts to connect to my server. There is little information about Public IP addresses being used by "shodan.io" scanner, so making an IP list for PF may be futile. Could someone suggest a possible option? I was thinking along the lines of “relayd” or "squid proxy”. My server is hosted at Vultr and has a single WAN interface with Public IP. There is no internal LAN interface. For those who do not know about “shodan.io”, please do a search and you will discover what it does. Regards Nino
Re: Blocking "shodan.io" - What are my options?
Hello, I wrote a small script called 'pf-badhost' to block shodan and other annoyances via pf firewall. Check out www.geoghegan.ca/pf-badhost.html to see the script. pf-badhost also blocks ssh bruteforcers and other annoyances by loading a list of regularly updated badhost lists from trusted sources. If you only want to block shodan specifically, just comment out the few lines that download the other blocklists, and you should be good to go. I've had a number of people give good feedback on it, and they've reported it blocking the scanners and baddies quite effectively; BSDNow also did a piece about it, so it seems to work alright. Cheers, Jordan On 01/02/19 22:15, Antonino Sidoti wrote: Hi, I wish to block all attempts by “shodan.io”. Basically I run an OpenBSD (6.4) mail server using OpenSMTPD and notice quite bit of traffic all stemming from “shodan.io". I have PF configured so I was wondering how to block such a domain from making any attempts to connect to my server. There is little information about Public IP addresses being used by "shodan.io" scanner, so making an IP list for PF may be futile. Could someone suggest a possible option? I was thinking along the lines of “relayd” or "squid proxy”. My server is hosted at Vultr and has a single WAN interface with Public IP. There is no internal LAN interface. For those who do not know about “shodan.io”, please do a search and you will discover what it does. Regards Nino
Re: Blocking "shodan.io" - What are my options?
Hello Nino, well, there is a list of known Shodan scanners available: https://wiki.ipfire.org/configuration/firewall/blockshodan However, it seems to be outdated - I observed "dojo.census.shodan.io" (IPv4: 80.82.77.139), too. Since scanners usually try to bypass blocking attempts or rate limits, I doubt maintaining an IP list makes sense. Querying RBLs or lists of known networks hosting malware (i.e. Spamhaus DROP) probably requires less manual effort. Thanks, and best regards, Peter Müller > Hi, > > I wish to block all attempts by “shodan.io”. Basically I run an OpenBSD (6.4) > mail server using OpenSMTPD and notice quite bit of traffic all stemming from > “shodan.io". I have PF configured so I was wondering how to block such a > domain from making any attempts to connect to my server. There is little > information about Public IP addresses being used by "shodan.io" scanner, so > making an IP list for PF may be futile. > > Could someone suggest a possible option? I was thinking along the lines of > “relayd” or "squid proxy”. My server is hosted at Vultr and has a single WAN > interface with Public IP. There is no internal LAN interface. > > For those who do not know about “shodan.io”, please do a search and you will > discover what it does. > > Regards > > Nino > -- Microsoft DNS service terminates abnormally when it recieves a response to a DNS query that was never made. Fix Information: Run your DNS service on a different platform. -- bugtraq
