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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/shorewall-users


Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to