Hi, I have a shorewall installation (master), and 6 shorewall-lite installations (clients). I want to manage black/whitelists centralized on the master, which should then be pushed to the clients like any other changes. For example, when there is a change in the sys admin management and I''ll add/remove a static admin IP, which is used in a rule like SSH(ACCEPT) net:+allowed_ssh $FW the "allowed_ssh" ipset on all shorewall-lite need to be updated. Can I do that with shorewall? Or would I have to write my own solution? Thanks. -- Regards, Igor ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
On 03/11/2013 08:27 AM, Igor Sverkos wrote:> Hi, > > I have a shorewall installation (master), and 6 shorewall-lite > installations (clients). > > I want to manage black/whitelists centralized on the master, which > should then be pushed to the clients like any other changes. > > For example, when there is a change in the sys admin management and I''ll > add/remove a static admin IP, which is used in a rule like > > SSH(ACCEPT) net:+allowed_ssh $FW > > the "allowed_ssh" ipset on all shorewall-lite need to be updated. > > Can I do that with shorewall? > > Or would I have to write my own solution?You would need to write your own solution. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
I just thought I''d offer as a suggestion here, I think this can be done
nice and tidy as a one line job I''m presuming from your example that
ssh
is available and is therefore a viable option. I''ve written it out
over
multiple lines here for the sake of reading clarity and preferring to
lay it out clearly than let word wrap handle it and no doubt it wrap at
a really not too helpful point.
SETNAME="allowed_ssh" SSHUSER="ipset"
SSHHOST="remote.server" \
SSHKEY="/path/to/private_ssh_key" && \
echo -e "`ipset save ${SETNAME} | sed
"s/${SETNAME}/&tmp/g"`\n" \
"swap ${SETNAME} ${SETNAME}tmp\ndestroy ${SETNAME}tmp" | \
ssh -l ${SSHUSER} ${SSHHOST} -i ${SSHKEY} ipset restore
Quick overview in case it''s unclear how I''ve written it out:
1. Run ipset save pipe output to sed.
2. Sed swaps all references to our ${SETNAME} to ${SETNAME}tmp
3. Append commands to swap ${SETNAME}tmp with ${SETNAME} to bring the
updated ipset online.
4. Append command to destroy our temporary ipset (Now consisting of the
superseded ipset contents).
5. Pipe to ssh to transfer our save file to ${SSHHOST} authenticate as
${SSHUSER} using private key stored in the file ${SSHKEY}
6. Execute ipset restore on our remote machine accepting ipset data from
stdin
I just wrote this quickly and was thinking of a transfer of a reasonably
sized ipset considering the speed of the LAN/internet connection, if you
have a very large set or the link speed is less than optimal you will
probably want to consider adding a pipe through "gzip -c9 -" prior to
piping to ssh then change your remote command to something like ''gunzip
- | ipset restore'' so you will be piping only compressed data over the
network, it should reduce bandwidth/time consumption considerably as
ipset save is just plain text which should gzip to a high compression
ratio especially with all the repetition most likely.
My one other concern here would be not overly wishing to have root on
the server being so open to direct remote login, it is not really
necessary to have full root to perform the update task. Were I setting
this up in a production environment myself I would personally probably
just set up ipset restricted access with an access group and assign the
required capabilities using file capabilities, setcap
''cap_net_admin=ep''
/usr/sbin/ipset should be sufficient.
On 11/03/13 15:34, Tom Eastep wrote:> On 03/11/2013 08:27 AM, Igor Sverkos wrote:
>> Hi,
>>
>> I have a shorewall installation (master), and 6 shorewall-lite
>> installations (clients).
>>
>> I want to manage black/whitelists centralized on the master, which
>> should then be pushed to the clients like any other changes.
>>
>> For example, when there is a change in the sys admin management and
I''ll
>> add/remove a static admin IP, which is used in a rule like
>>
>> SSH(ACCEPT) net:+allowed_ssh $FW
>>
>> the "allowed_ssh" ipset on all shorewall-lite need to be
updated.
>>
>> Can I do that with shorewall?
>>
>> Or would I have to write my own solution?
> You would need to write your own solution.
>
> -Tom
>
>
>
------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice"
in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
>
>
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in
the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
Igor Sverkos
2013-Mar-12 09:47 UTC
Re: Can shorewall push ipsets to shorewall-lite clients?
Hi, Matt Joyce wrote:> I just thought I''d offer as a suggestion here, I think this can be done > nice and tidy as a one line job I''m presuming from your example that ssh > is available and is therefore a viable option. [...]Thank you. I am thinking of something similar. Actual I am facing the problem, that I don''t want to dump every ipset in one file (so I would need a way to dump only the sets I want; this is not a problem with ipset, but need to be implemented in my solution) and I need documentation at least on the master, so using ipset dumps is not quite an option (I prefer recreation). Let me clarify the last point: When you need to whitelist or blacklist a new IP/net/system you can just run the "ipset add $setname $ip/net/system" command. On shutdown/stop, you would just dump all the ipsets (ipset save > myipsets.dat) so that you can read this file on startup/start (ipset restore < myipsets.dat). But: 1) Do you remember *why* IP/net/system is part of your whitelist/blacklist? 2) How can you be sure that your ipset only contain trusted data? Isn''t it possible that someone manipulate the data (hack, ex-colleague in his final days...) That''s why I prefer recreation: I am thinking about a simple bash script which starts with> ipset -exist create allowed_ssh4 hash:ip family inet hashsize 64 > > # sys administration building 03/e4/pc427 > ipset add allowed_ssh4 192.168.24.117Well, you could also omit the inline comments, because I am going to store the file in a VCS, so you have commit logs. This will address #1 and #2. We know exactly the state of our ipsets and why, when and who changed something. Well, the script I am working on will do something more, e.g. providing a "update" method using ipset''s swap command, but I think you will get the point. When I have solve this problem, I have the infrastructure to automatically update the ipsets on any clients. I am actual not sure if a cronjob should update ipsets automatically or if we prefer pushing the updates (this could be issuing a ssh command to the client to run the updater). When we would store the actual "data" (the "ipset add ..." commands) separate from the logic, we could also easily create individual ipsets per client. -- Regards, Igor ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
Igor, just wondering how long have you been on the list if you have messages going back a couple of weeks you should find a discussion topic specifically about bogon filtering however I included in that the bash script I created to handle the updating and as I mentioned at the time it could be adapted to other things, I am thinking some small modifications to it and it may suit your needs, your mentioning the desire for comments in the file the script as written supports ip networks in CIDR form so you may want to alter that to using hash:ip instead, if all your admin team use exactly one ip address so you arn''t adding /32 to every line, but perhaps CIDR support will have it''s uses for you if some staff could appear from a subnet of addresses. It supports comments in the source files in the form of hash comments both whole of line and end of line variants. I also strongly would recommend if you still have the discussion reading the points about the recreation performance, when you do the method I use in the latest version will make more sense, compared to a basic read loop doing ipset adds the latest method is faster by a significant magnitude on the large set in question it is the difference between around 3-5 minutes throughout that time making system responsiveness poor and more like 3-5 seconds and only ever managing to get to about 60% of one core with no noticeable shift in system responsiveness. It is explained more in the original posts but simply it uses a one line command substitution arrangement to convert the input file on the fly into ipset save''s own format and then pipes it to ipset restore building a new setnametmp ipset, swapping it with the old setname then destroying the tmp (now obsolete) the same pattern of updating as my example yesturday actually, this method being used as it guarantees that there will not be a window where some entries are missing, furthermore as the set is only swapped in after it is built the currently working live ipset remains live and working should the rebuild fail for any reason ipset bails with an error if any of the restore operation fails. I personally feel in your use case also that an effective noop is a preferable failure mode should there ever be a problem relative to the alternative of a partially filled or totally empty set which would result in locking out some or all of the previously approved administrators, likely to be fail-deadly depending on the physical locations of the systems and the availability of quickly being able to secure local console access with the affected system, Not doing anything to the existing set until we have a good set to work with sounds like the better fail-safe for you here. Take a look if you have the messages from that discussion still, messages will be dated around the 23rd/24th of February, if you don''t have them drop me a quick mail off list and I can forward you copies. Hmm probably is an archive somewhere actually but not sure I can easily forward copies though I just marked them to be easy to find if you do need them anyway. Also, just to mention the script was initially designed to pull updates from exactly the sort of master file you are describing over HTTP, I am aware you did say push so that may or may not be useful to you but you could possibly use it to grab the master file and auto update, it uses curl to issue the HTTP GET request with IfModifiedSince so it only pulls the list if there has been an actual change as such I seem to recall you said something like 5 clients? so you could most likely check with the master quite frequently with minimal overhead, no change it''s just the outgoing few bytes of request and the 304 reply which will be the size of the HTTP headers for the resource plus the TCP header without sitting and trying to add it up I suspect we are looking at a number on the order of a kB or two per request with the TCP open handshake, request, reply and the TCP close. Pushing could also work with this script though, a friend of mine used a slightly modified version and a few lines of php script to handle a push via a HTTPS POST. Think he used the suexec module to run the job as a non-privilaged user in the correct group to execute ipset configured with file capabilities, while not a big one seemed he was still happier not adding the web server itself to that group, personally in this case thinking that might be worrying a little too much not sure if apache2 has caps support yet but if/when it does that is likely to be I think that is the one a process elects to maintain when dropping privs to retain the ability to change bindings on <1024 ports Another way of doing a push would be to configure the script the same as you would for a pull but omit adding the cron job, then execute the command via ssh instead, or combine them say an hourly cronjob but knowing you can always push changes if you are in a hurry. On 12/03/13 09:47, Igor Sverkos wrote:> Hi, > > Matt Joyce wrote: >> I just thought I''d offer as a suggestion here, I think this can be done >> nice and tidy as a one line job I''m presuming from your example that ssh >> is available and is therefore a viable option. [...] > Thank you. > > I am thinking of something similar. Actual I am facing the problem, that > I don''t want to dump every ipset in one file (so I would need a way to > dump only the sets I want; this is not a problem with ipset, but need to > be implemented in my solution) and I need documentation at least on the > master, so using ipset dumps is not quite an option (I prefer recreation). > > Let me clarify the last point: > When you need to whitelist or blacklist a new IP/net/system you can just > run the "ipset add $setname $ip/net/system" command. > > On shutdown/stop, you would just dump all the ipsets (ipset save > > myipsets.dat) so that you can read this file on startup/start (ipset > restore < myipsets.dat). > > But: > 1) Do you remember *why* IP/net/system is part of your whitelist/blacklist? > > 2) How can you be sure that your ipset only contain trusted data? Isn''t > it possible that someone manipulate the data (hack, ex-colleague in his > final days...) > > That''s why I prefer recreation: > I am thinking about a simple bash script which starts with > >> ipset -exist create allowed_ssh4 hash:ip family inet hashsize 64 >> >> # sys administration building 03/e4/pc427 >> ipset add allowed_ssh4 192.168.24.117 > Well, you could also omit the inline comments, because I am going to > store the file in a VCS, so you have commit logs. > > This will address #1 and #2. We know exactly the state of our ipsets and > why, when and who changed something. > > Well, the script I am working on will do something more, e.g. providing > a "update" method using ipset''s swap command, but I think you will get > the point. > > When I have solve this problem, I have the infrastructure to > automatically update the ipsets on any clients. > I am actual not sure if a cronjob should update ipsets automatically or > if we prefer pushing the updates (this could be issuing a ssh command to > the client to run the updater). > When we would store the actual "data" (the "ipset add ..." commands) > separate from the logic, we could also easily create individual ipsets > per client. > >------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev